Iotiny LED Blinking Issue

Thanks - good details. Based on what you’ve described (fast continuous blue blink, no aqua startup color, no startup sound, reset button unresponsive, same power supply works with another IoTiny) this strongly indicates a boot/firmware or hardware fault on that IoTiny (corrupted application firmware, stuck in a boot/halting state, or MCU/regulator failure). Below are safe, prioritized diagnostics and recovery steps you can try. Please run them and paste the Connection Diagnostic log here so I can help interpret the results.

Quick links

• IoTiny product & docs: https://synthiam.com/Support/Hardware/EZ-B-IoTiny
• ARC EZB firmwares / hardware overview (firmware updates): https://synthiam.com/Support/Hardware/Hardware-Overview
• Connection Diagnostic skill (how to run & copy log): https://synthiam.com/Support/Skills/Communication/Connection-Diagnostic?id=16164

Diagnostic checklist (step-by-step)

1. Basic sanity checks (you already did some)

• Confirm the working IoTiny and the failing IoTiny are powered from the exact same connections (same jack/polarity and wiring).
• Smell/heat check: does the failing IoTiny feel warm/hot after powering on or do you smell burnt electronics? (If yes, stop and report - indicates hardware damage.)

2. Factory reset attempt (documented recovery step)

• With the IoTiny powered, press the reset button to return to defaults (the manual says pressing reset while powered returns to defaults).
• Try holding the button ~5-10 seconds and then release. Wait 10-15 seconds for any activity.
• After reset, look for the initial "aqua" LED or listen for the startup sound. If nothing changes, continue.

3. Try to reach the IoTiny web config (AP mode)

• When IoTiny is powered it normally starts in AP (Access Point) mode (even after factory reset).
• From a phone or PC WiFi list, scan for an SSID resembling EZ-B / IoTiny (EZ-B-xxxx or IoTiny-xxxx). If you find it, connect.
• Open a browser and go to: http://192.168.1.1
• If the web page appears, you can reconfigure or reflash firmware via the web UI (follow prompts). If the web UI is reachable but the LED/sound are still odd, save any diagnostic output and tell me what the web UI shows.

4. Ping 192.168.1.1 with ARC Connection Diagnostic

• Open your ARC project and the Connection Diagnostic robot skill window (Project Add robot skill General Connection Diagnostic if needed).
• With the problem IoTiny powered, in the Connection Diagnostic skill press "Ping EZ-B" (the skill pings 192.168.1.1).
• Click the skill’s Copy Log button and paste the log here. That log is extremely helpful. If the ping fails, that’s an important clue.

5. WiFi scan on your PC/phone if no SSID or web page

• Use a WiFi scanner on your PC (or the WifiInfo tool referenced on the WiFi Troubleshooting page) and see if the IoTiny’s SSID shows. If there is no AP SSID and no ping response, the unit likely isn’t booting far enough to bring up WiFi.

6. Try ARC Connect attempt

• In ARC open the Connection EZ-B Connect dialog and attempt discovery while the IoTiny is powered. Note any error messages in ARC status window and paste them here (Connection Diagnostic Copy Log will capture the same info).

7. Firmware reflash options

• If you can reach the IoTiny web config at 192.168.1.1 or ARC detects it, check for a firmware update option in the web UI or the ARC firmware page. Use the IoTiny documentation/firmware files linked from the IoTiny product page above.
• If the unit is not reachable (no ping, no AP), you cannot reflash over WiFi. Some IoTiny recovery methods require a physical tool or service (internal serial/programmer) - the product docs/firmware pages linked above are the only safe, supported sources for flashing instructions.

What the different outcomes mean

• Ping/AP reachable but no sound/odd LED: firmware app may be corrupted but bootloader and networking still work. You should be able to reflash via the web UI or ARC. Grab the web UI/diagnostic output and I’ll walk you through the update steps.
• No ping, no AP, reset does nothing: device may be stuck before WiFi initialization (bootloader missing or hardware failure). If you’re comfortable opening hardware, an in-circuit reflash via a hardware programmer might be possible - but that’s advanced and not covered here unless you want to attempt it.
• LED pattern + no web/ping but another IoTiny works on same supply: likely internal fault (flash corruption or MCU/regulator failure).

Please run these steps and report:

1. Result of the factory reset attempt (did anything change?).
2. Does the IoTiny AP SSID appear in your WiFi list? If yes, did http://192.168.1.1 load?
3. Connection Diagnostic: press Ping EZ-B and Copy Log - paste the log here.
4. Any smells, visible damage, or heat? Did the IoTiny ever work previously and when did this start?
5. Did you ever attempt a firmware update previously?

Next steps after you post the log

• If AP/ping is reachable I’ll provide exact firmware update steps (how to upload the firmware via web UI or ARC).
• If unreachable, I’ll show how to gather deeper diagnostics (telnet/port checks if applicable) and advise whether a hardware reflash is feasible or if the unit shows signs of hardware failure.

Notes and resources

• IoTiny manual & troubleshooting: https://synthiam.com/Support/Hardware/EZ-B-IoTiny
• ARC firmware overview & downloads: https://synthiam.com/Support/Hardware/Hardware-Overview
• Use Connection Diagnostic skill and its Copy Log (Project open the skill window use Ping and Copy Log buttons).

If you paste the Connection Diagnostic log here I’ll read it and give the most accurate next action (firmware reflash steps if possible, or hardware failure indications). Would you like step-by-step firmware update instructions if the web UI becomes available?

Result of the factory reset attempt (did anything change?).  nothing has changed i tried the reset while powered it ON. Does the IoTiny AP SSID appear in your WiFi list? If yes, did http://192.168.1.1 load?   no, we dont see it in the wifi list Connection Diagnostic: press Ping EZ-B and Copy Log - paste the log here. nothing Any smells, visible damage, or heat? Did the IoTiny ever work previously and when did this start? no damage or burned. Did you ever attempt a firmware update previously? no

i dont hear the start chime , nothing in wifi list, just blinking fast blue.  I did several tests with this IoTiny a few weeks ago - AP mode, client mode, servos, camera, etc.

Maybe I made a mistake and didn’t realize it right away.

Thanks - this rules out power and confirms the unit is not responding on WiFi or to reset. Given your answers (no AP SSID, no startup chime, fast continuous blue blink, reset had no effect, no smell/visible damage, unit worked a few weeks ago) the most likely causes are:

• corrupted or failed application firmware (device never reaches WiFi/AP or audio init), or
• a bootloader / early-boot failure, or
• hardware fault (MCU, flash, voltage regulator, etc.).

Below are safe, prioritized next steps (easy moderate advanced). Tell me which ones you want to try and I’ll give stepbystep instructions for that option.

1. Repeat a forced factory/reset sequence (easy)

• Power-off the IoTiny.
• Press and hold the reset button.
• While still holding Reset, power the IoTiny on. Keep holding Reset for 10-15 seconds after power-up, then release.
• Wait 20-30 seconds and watch for any LED change or startup chime.
  Why: some devices only enter recovery/AP or a default state if Reset is held while powering on. You tried Reset while powered, but please try this powercycle + hold sequence.

2. Check whether the device joined your local router (quick network checks)

• If the IoTiny was previously configured as a WiFi client it may be trying to join your router instead of creating an AP. Check your router’s DHCP/connected devices list for any new/unfamiliar IP (scan with Fing on a phone or Advanced IP Scanner / Angry IP Scanner on PC).
• Run a network scan on your subnet (e.g., 192.168.1.0/24) to find unknown devices. If you find an IP that could be the IoTiny, try http://<that-ip>; in a browser and/or ping it.
  Why: If IoTiny is in client mode and got a new IP, it won’t show as an AP (so it won’t appear in the phone AP list).

Useful links:

• IoTiny product docs & web config reminders: https://synthiam.com/Support/Hardware/EZ-B-IoTiny
• WiFi troubleshooting (tools, tests): https://synthiam.com/Support/troubleshooting/Troubleshoot-WiFi-Connections

3. Use a WiFi scanner on your PC (easy)

• Download/run a WiFi scanning tool (or the WifiInfo.exe referenced on the WiFi Troubleshooting page) to detect nearby SSIDs and channel info. Ensure the IoTiny SSID isn’t hidden.
  Why: If the AP SSID is being broadcast on a different channel or hidden, a basic phone scan may miss it.

4. Look for boot messages on serial/TX (moderate / requires opening or UART access)

• Many controllers print boot/diagnostic messages on a serial TX pin at power-up. If you’re comfortable opening the unit or locating the UART pads, you can connect a USBTTL adapter (3.3V) and monitor with PuTTY / RealTerm at common baud rates (try 115200 and 9600).
• Connections: GND to GND, IoTiny TX -> USBTTL RX (and optionally IoTiny RX -> USBTTL TX if you’re going to send commands). Monitor while powering up to capture any boot output.
  Why: If you can see serial boot logs, we can tell whether the bootloader runs, whether it dies early, or if it tries to start networking.

Warning: only connect to exposed pads/pins if you are comfortable with electronics. If you open the board, take ESD precautions and only use a 3.3V TTL adapter.

5. Attempt to force AP / recovery via button combos (moderate)

• Some devices use different button press patterns to force AP or factory reset (quick press vs long press, double-press, etc.). Try:
  • Quick press of Reset several times after power on.
  • Hold Reset for >30 seconds with power applied.
• Watch for any change in LED color/pattern or sound. If anything changes, try connecting to 192.168.1.1 right away.

6. Advanced: in-circuit reflash (advanced / hardware programmer required)

• If the bootloader is corrupted or the device never gets far enough to start WiFi, the only recovery may be re-flashing the MCU via SWD/JTAG or an in-circuit programmer (ST-Link / J-Link) or using a serial bootloader if one exists. The IoTiny uses an ARM CortexM series MCU, so SWD programming is typical.
• This requires:
  • the exact firmware image (official firmware/bootloader from the vendor), and
  • locating the SWD or UART programming pads on the PCB, and
  • an SWD programmer (STLink / JLink) and OpenOCD or vendor flashing tools.
    Why: If the application and/or bootloader is corrupted, reflashing is usually the way to recover - but it’s advanced and needs vendor firmware and hardware tools. I can give a high-level checklist and what to look for, but I can’t supply vendor firmware files - use only official firmware from the IoTiny/EZRobot pages linked above.

What I can walk you through (pick one):

• Exact button hold/power cycle steps to try again.
• How to scan your router’s DHCP/ARP list and use network scanning tools (Fing, Advanced IP Scanner) stepbystep.
• Stepbystep instructions for connecting a USBTTL adapter to look for boot messages (with exact serial settings to try).
• Highlevel guidance for SWD reflash: what tools you’ll need and how to get the firmware (if you want to attempt it).

A couple of targeted questions so I can tailor the next steps:

1. Do you want me to walk you through the router/DHCP scan and network scanning steps? (If yes, tell me your PC subnet, e.g., 192.168.1.x)
2. Are you comfortable opening the IoTiny or connecting a USBTTL adapter to probe serial TX? (Yes/No)
3. Do you have access to an SWD programmer (STLink / JLink) or would you consider buying one if reflashing becomes necessary?
4. Did the IoTiny ever show the AP SSID after your last successful tests, or did it stop working right after a change you made (WiFi settings, firmware update, etc.)?

If you prefer, start with #1 (forced reset while powering on) and #2 (router scan). If those don’t turn anything up, I’ll give stepbystep serial monitor instructions so you can capture boot output - that will tell us if the MCU/bootloader is running and what to try next.

i am working with the backup iotiny, so no emergency. but you can give me the Stepbystep instructions for connecting a USBTTL adapter to look for boot messages (with exact serial settings to try). i will try it later

Good - below are clear, stepbystep instructions to connect a USBTTL adapter and capture boot messages from the IoTiny. I’ll cover safety, wiring, serial settings, how to capture the log, and what to paste back here so I can interpret the output.

Required tools

• USBTTL adapter that can be set to 3.3V (FTDI, CP2102, CH340, etc.). DO NOT use 5V mode.
• Jumper wires (female/male as needed).
• Your normal IoTiny power supply (recommended) and the IoTiny.
• PC (Windows/Linux/Mac) with a serial terminal app (PuTTY, Tera Term, RealTerm on Windows; screen/minicom on Linux/Mac).
• Optional: small screwdriver, multimeter, ESD precautions.

Safety & important notes

• Ensure the USBTTL adapter is set to 3.3V. 5V levels can permanently damage the IoTiny.
• Prefer powering the IoTiny from its normal power source (battery or adapter). Only use the adapter’s 3.3V output to power the IoTiny if you know it can supply adequate current.
• Connect grounds: IoTiny GND must be common with USBTTL GND.
• If you must open the IoTiny’s enclosure, use ESD protection and be careful not to short pads.
• I cannot view pictures - if you post photos of board markings, include the exact text printed on the board; I’ll rely on your description.

Step 1 - Identify UART pads / header

• Look for labeled pads or a small 3pin header on the IoTiny board marked TX, RX, GND, or UART. If you don’t see labels, tell me any silkscreen text on the board and I’ll help locate them.
• If the IoTiny has a header: typical pin order is GND / TX / RX or similar. Confirm by reading the silkscreen.

Step 2 - Prepare the USBTTL adapter

• Select 3.3V logic on the adapter.
• Install drivers for the adapter on your PC (FTDI/CP2102/CH340 drivers as required).
• Note the COM port assigned (Windows Device Manager) or /dev/ttyUSBx (Linux) /dev/cu.* (Mac).

Step 3 - Wiring (power off everything before connecting)

• Connect adapter GND IoTiny GND.
• Connect adapter RX IoTiny TX (this is the only wire needed to capture boot logs).
• Optionally connect adapter TX IoTiny RX if you plan to send commands (not required for just reading logs).
• If you decide to power IoTiny from the adapter’s 3.3V pin, only do so if adapter can supply enough current. Recommended: keep the IoTiny on its usual power supply and just share ground.

Step 4 - Serial terminal settings Use these settings and try multiple baud rates if needed:

• Baud: try 115200 first, then 9600, 57600, and 230400 if nothing appears.
• Data bits: 8
• Parity: None
• Stop bits: 1
• Flow control: None
• Local echo: off (optional)
• Line endings: not needed for boot output (don’t send anything yet)

How to open with PuTTY (Windows)

• Session Serial
• Serial line: COMx (your adapter)
• Speed: 115200
• Click Open. If you get a blank screen, it’s okay - proceed to step 5.

How to open with screen (Linux/Mac)

• sudo screen /dev/ttyUSB0 115200

Step 5 - Capture boot messages

• With the terminal open and logging enabled (RealTerm/PuTTY can log to a file), power ON the IoTiny.
• If the terminal was open, you should see boot messages immediately after power up. If nothing appears, power cycle while watching the terminal.
• If the output is garbled, try changing the baud rate.
• If you still see nothing at any baud rate, swap RX/TX connections (but that will normally only be necessary if you mis-identified TX/RX).
• If you see readable boot text, save the terminal output (or copy/paste) and post it here.

Step 6 - What to capture and paste here

• The full boot sequence text (first lines after power-on).
• Note the baud rate that produced readable output.
• Any error lines, "panic", "assert", "failed", or repeated stack traces.
• If you see only a short message or nothing at all, paste exactly what you saw (even single lines or garbage).

Troubleshooting tips

• Garbage characters wrong baud or wrong voltage level. Re-check adapter 3.3V selection.
• No characters at any baud either you’re not connected to the correct pad, the MCU isn’t reaching UART output, or the board is dead early in boot.
• If the board prints something like "bootloader" or "waiting for firmware" that’s useful - paste it.
• If the UART header is unlabelled, tell me any silkscreen text or count/position of pads and I’ll help identify TX pin.

Useful links

• IoTiny product & docs: https://synthiam.com/Support/Hardware/EZ-B-IoTiny
• Serial Terminal skill (if you want to review PC terminal usage inside ARC): https://synthiam.com/Support/Skills/Communication/Serial-Terminal?id=16071

Follow-up questions

1. Which OS will you use (Windows, Linux, Mac)? I can give exact commands for your OS.
2. What USBTTL adapter do you have (model or chipset - FTDI/CH340/CP2102)? Is it selectable to 3.3V?
3. Can you describe any markings near the small pads/headers on the IoTiny board (text like TX, RX, UART, GND, or printed dots)?

When you run this, paste the serial output here (or the saved log file contents). Once I see the boot messages I’ll tell you whether the bootloader runs, whether firmware is failing, or if it’s likely a hardware fault - and then give the next recovery steps.

The led is connected to the small pic microcontroller. The pic is controlled by the main cpu arm micro. In default state the led is flashing fast on power up. The state of the blue led changes when the arm micro boots up and instructs it to change state.

it’s unlikely there is a firmware damage. It is more likely there is damage to the main arm micro. This could have been done by shorting, applying too much current to a gpio, drawing too much current from gpio, etc.

Thanks - that Synthiam_Support note is helpful and lines up with the symptoms you described.

Short summary of what that message means

• The small PIC microcontroller drives the LED and will flash fast by default on powerup.
• The PIC only changes the LED state when the ARM MCU has booted and tells it to change.
• If you only ever see the default fast blue blink and never the aqua/startup chime or any WiFi activity, the PIC is doing its job but the ARM CPU likely never gets far enough to tell the PIC to change state.
• That points more toward the ARM MCU (or its power/regulator or associated I/O) failing, not necessarily a firmware-only corruption.

What that implies

• If the ARM CPU is dead or its Vdd/regulator/reset line is abnormal, the board will not initialize WiFi, not run the audio startup, and will not respond to resets or firmware reflash over WiFi.
• Repair usually becomes a boardlevel job (power rail/regulator component replacement or MCU reflash/replacement) if you confirm the ARM MCU is not running.

Recommended next steps (safe more advanced)

1. Confirm PIC vs. ARM behavior you’re seeing

   • Observe LED on power up: you should see the fast default blink for a few seconds regardless of ARM state. If that happens, the PIC is alive.
   • If the LED never changes from that default after a longer wait, that indicates the ARM never finished booting.

2. Capture serial boot output (if you haven’t yet)

   • Follow the USBTTL steps we covered earlier to monitor the ARM UART TX during power-up.
   • If you see no boot text at typical baud rates (115200, 9600) while PIC default LED is present, that’s strong evidence the ARM is not running.
   • Paste the full serial output (or confirm "no output at all") - that log is the most direct diagnostic.

3. Power-rail and regulator checks (multimeter)

   • With the unit powered, measure the regulated 3.3 V (Vcc) on the board. Typical locations: the MCU Vdd pins or any 3.3V test point - report exact voltage.
   • Check the MCU Vdd pin(s). If Vdd is absent or far off (<= ~3.0 V or >>3.6 V) the MCU won’t boot.
   • Check for shorts between Vcc and GND (multimeter continuity). A near-short suggests a damaged component.
   • Look for excessive heat on the board or any visibly damaged components. If any part is hot or charred, stop and report.

4. If serial shows bootloader or error messages

   • If you do see text (panics, asserts, bootloader waiting), paste it here and I’ll give exact steps to reflash or recover via serial/web UI if possible.

5. If serial is silent and 3.3V is correct - check RESET/WATCHDOG lines

   • Measure the reset pin voltage on the ARM MCU (if you can identify pin) - it should be released (high) when not being pressed. If reset is held low the MCU won’t run.
   • If you’re comfortable identifying board silkscreen labels, tell me the markings near the MCU or near a 4pin header - I can help locate reset/SWD pads.

6. Advanced: SWD / in-circuit programming (only if you have the tools)

   • If you have an SWD programmer (STLink / JLink) and are comfortable, you can attempt to connect SWCLK, SWDIO, GND, and 3.3V to the board’s SWD pads and query the MCU.
   • If the MCU is alive on SWD you can read device ID, dump flash, or reflash bootloader/firmware using OpenOCD or vendor tools.
   • This is boardlevel repair territory. I can provide the exact SWD pin names and a safe checklist if you have the STLink and want to try.

7. Repair / replacement options

   • If ARM MCU is unresponsive and power/regulator is good, the likely options are board repair (replace regulator or MCU) or replace the IoTiny.
   • If you have a backup unit (you said you do), continue using that while you decide whether to repair the defective unit.

What I can walk you through next

• Stepbystep USBTTL serial capture (again) if you want to confirm no UART output.
• Exact multimeter checks and typical measurement points (I’ll need photos descriptions or board text because I cannot view images).
• SWD probing and how to use STLink / OpenOCD (if you have the hardware).
• Interpreting any serial boot logs you capture.

A few quick questions so I can tailor the instructions

1. Do you have a USBTTL adapter and multimeter available?
2. Did you already try the USBTTL serial capture? If yes, what exactly did you see (paste log or say "no output at 115200/9600")?
3. Are you comfortable opening the IoTiny and probing board pads?
4. Do you have an SWD programmer (STLink or JLink) or would you be willing to get one if I provide SWD steps?

If you tell me which of the above checks you want to do now (serial, voltages, SWD), I’ll give exact stepbystep instructions for that action. Also, if you can type any silkscreen text printed near the MCU, connectors, or 3pin header, paste it here - that helps me point to exact pads to check.

If the LED never changes from that default after a longer wait, that indicates the ARM never finished booting. Thats the case, it keeps blinking fast, never changes state.