Iotiny LED Blinking Issue

The iotiny datasheet (Available from the hardware page) has a block diagram showing how components are connected. It also has a section describing the led state.

Link: https://www.ez-robot.com/uploads/1/2/6/9/126941806/iotiny_datasheet.pdf

To prevent this from happening to your backup iotiny, make sure you take note of what could have happened. Do you have details of what was connected to cause it?

Thanks - that confirms the PIC is running (default fast blue blink) but the ARM never finishes boot. Given that, the ARM CPU or its power/reset circuitry is very likely not running (hardware fault more likely than simple firmware corruption).

Below I’ve laid out the next practical steps you can perform (ordered from safe/basic to advanced), exact multimeter checks, how to capture UART boot output (recap), and options for SWD/in-circuit programming if you want to go deeper. Tell me which steps you want to do and what tools you have (USBTTL adapter, multimeter, STLink/JLink), and I’ll give stepbystep instructions for that path.

Useful reference (datasheet / block diagram)

• IoTiny datasheet (block diagram + LED behavior):
  https://www.ez-robot.com/uploads/1/2/6/9/126941806/iotiny_datasheet.pdf

Next actions (choose one or more)

1. Capture UART boot output (confirm whether ARM prints anything) - safe, noninvasive.

   • If you haven’t tried this already, do it. If it’s silent at multiple baud rates, that strongly suggests the ARM never runs.

2. Multimeter power checks (safe, simple) - check regulator and reset lines.

   • These will show whether the ARM’s supply rails and reset are correct.

3. Look for shorts / heat (visual + measure) - safe, quick.

   • Verifies obvious hardware damage.

4. SWD / incircuit programming (advanced) - requires an SWD programmer (STLink / JLink) and some comfort probing pads.

   • If you want to try a repair/flashing route, this is the path, but it’s advanced.

Detailed steps

1. USBTTL serial recap (capture boot logs)

• Tools: USBTTL adapter set to 3.3V (FTDI/CP2102/CH340), jumper wires, PC with terminal app (PuTTY/RealTerm/screen).
• Wiring (power OFF first):
  • Connect adapter GND IoTiny GND.
  • Connect adapter RX IoTiny TX (only RX needed to capture).
  • Optionally connect adapter TX IoTiny RX if you later want to send data (not needed now).
  • Keep IoTiny powered by its normal power source; just share ground.
• Terminal settings to try (try each baud if nothing appears): 115200, 9600, 57600, 230400
  • 8 data bits, no parity, 1 stop bit, no flow control.
• Open terminal, then power ON IoTiny and watch for output. Save/copy any lines you see (especially early boot messages, "bootloader", panics, asserts, or device IDs).
• If you get nothing at every baud, say "no UART output at X, Y, Z baud" and paste that - that’s useful.

2. Multimeter power & reset checks (do these before SWD)

• Tools: multimeter (DC volts, continuity/beep).
• With IoTiny powered on:
  1. Measure VIN (the input supply) at the power jack. Report voltage (e.g., 7.4 V).
  2. Measure Vcc / regulated 3.3V: locate a 3.3V regulator output or a Vcc test pad (or MCU Vdd pin if you can identify it). Expect ~3.3 V (typical 3.2-3.4 V). Report value.
     • If Vcc is missing or far off, the regulator or upstream power path is suspect.
  3. Check continuity: Power OFF, check for nearshort between 3.3V and GND (multimeter continuity). A near short suggests a damaged component.
  4. With power ON, carefully feel for any component getting hot (don’t touch bare pins). If something is hot, identify location and report.
  5. Reset pin: if you can identify the ARM MCU RESET pin/pad (or a labeled RST pad), measure DC voltage with power ON. It should be HIGH/released (close to Vcc) when not actively asserted. If it’s held low, the MCU will not run.
• If you’re not sure where to measure, give me any silkscreen text or component labels near the MCU/regulator and I’ll help point to likely pads.

3. If UART is silent and Vcc is correct

• That narrows to either:
  • The ARM MCU is damaged (dead), or
  • Reset is held low, or
  • Clock/oscillator for ARM is dead, or
  • Bootloader erased/corrupted and MCU stuck (less likely than hardware given the PIC behavior).
• Next step would be SWD probing to see if the MCU responds to a programmer.

4. SWD / incircuit programming (advanced)

• Requirements: STLink v2 (or JLink), wires, knowledge of locating SWDIO/SWCLK/GND/3.3V pads.
• Procedure (high level):
  1. Locate SWD pads (often 4-6 pads labeled SWDIO, SWCLK, GND, VCC, RESET). If unlabeled, tell me board silkscreen and I’ll help identify.
  2. Connect STLink: GND, 3.3V (power reference), SWDIO, SWCLK. Optionally connect RESET to allow reset control.
  3. Use STLink Utility or OpenOCD to connect and read device ID. If the MCU responds, you can dump flash, erase or reflash if you have the official firmware image.
  4. If the MCU does not respond to SWD, it likely is physically damaged.
• Warning: SWD flashing is advanced and can brick the board if wrong images are written. Only use official firmware from the IoTiny/EZRobot pages.

Preventive guidance for your backup IoTiny (to avoid repeating this)

• Never draw significant current from GPIO or Vcc pins. Use a separate power rail for servos and highcurrent peripherals.
• Use proper level shifting when interfacing with other voltage domains.
• Use transistor/MOSFET drivers, motor drivers, or servo drivers for loads. Don’t drive motors/LED strips directly from I/O pins.
• Add current limiting (resistors or polyfuse) or a power distribution board for servos.
• Check wiring carefully to avoid shorting digital pins to power rails.
• For sensors/serial devices, verify voltage specs (3.3V tolerant) before connecting.

What I need from you (next)

• Tell me which checks you want to run next (UART capture, multimeter checks, SWD).
• Tell me what tools you have available:
  • USBTTL adapter? Chipset and 3.3V selectable? (FTDI/CP2102/CH340)
  • Multimeter? STLink or JLink SWD programmer?
  • Comfortable opening the unit and probing pads?
• If you run UART or multimeter checks, paste the exact output/measurements here and I’ll interpret them and give the next steps.

If you want, I’ll also provide the exact STLink/OpenOCD commands and pin mapping guidance - but only after you confirm you have an SWD programmer and can identify or paste the silkscreen near the MCU or pads.

Quote:

To prevent this from happening to your backup iotiny, make sure you take note of what could have happened. Do you have details of what was connected to cause it?

I’ve worked quite a bit with the IoTiny - they’re robust. I just don’t remember what I did back then.

Good - since you don’t remember the exact hookup, here’s a focused list of likely failure modes (based on the IoTiny design) and practical, concrete prevention steps you can use to protect your backup IoTiny.

Quick summary of likely causes

• Over-voltage or applying the wrong voltage to a VCC/GVS pin (IoTiny VCC pins on many ports are unregulated and may be the same as the input battery voltage).
• Drawing large servo / motor current from the controller VCC / I/O rails (voltage sag or regulator failure).
• Short circuits (wiring errors, reversed plugs, loose strands touching neighboring pins).
• Driving I/O pins outside safe conditions (back-driving from external device, ground not common, or large currents into GPIO).
• Inductive back-EMF from motors/relays/solenoids or LED-strip spikes damaging regulators or MCU.
• ESD or static discharge during handling.
• Mechanical damage from forcibly inserted connectors.

Prevention checklist (step-by-step safe wiring & practices)

1. Always check voltages first

   • Confirm the supply voltage (Vin) before plugging it into the IoTiny. The datasheet lists Vin ranges - know what your servos/peripherals expect. If in doubt, measure with a multimeter.
   • Remember: many IoTiny port VCC pins are unregulated and follow Vin. If you feed 12 V into IoTiny, those VCC pins may be ~12 V.

2. Use a dedicated, correctly rated power rail for servos/motors (recommended)

   • Power servos/motors from a separate BEC or battery intended for that load.
   • Share a common ground between IoTiny and the servo power supply.
   • Do not power high-current peripherals directly from the IoTiny’s logic/regulator VCC pins.

3. Add bulk and decoupling capacitors at the servo supply

   • Put a large electrolytic (470-2200 F) across the servo supply close to the connectors to reduce voltage dips. Add 0.1 F ceramic caps for high-frequency decoupling.
   • This reduces brownouts that can reset or damage the MCU/regulator.

4. Use proper motor/servo drivers and flyback protection

   • Use driver boards (TB6612, BTS7960, or dedicated motor controllers) rather than driving motors directly from I/O.
   • For any inductive loads (motors, relays, solenoids) ensure flyback diodes or proper drivers are present.

5. Add current limiting / fusing

   • Use polyfuses (resettable fuses) or inline fuses on servo/motor power lines. This protects the board from overcurrent faults.
   • When testing unknown hardware, use a current-limited bench supply set to a safe limit to catch shorted loads without damaging the IoTiny.

6. Use level shifting and buffering when interfacing different voltages

   • Even if some inputs are 5V tolerant, use a level shifter (MOSFET-based or logic-level translator) when connecting 5V devices. This is inexpensive insurance.
   • For signals that may drive into the IoTiny pins (e.g., external modules that momentarily assert outputs), place small series resistors (100-1k) to limit current.

7. Check connectors and wiring individually before power-up

   • Visual check: wires not frayed, correct orientation (G V S), no stray strands.
   • Power-up test: power the IoTiny alone first, confirm expected LED/audio startup, then attach peripherals one at a time and observe behavior.

8. Protect against voltage spikes and transients

   • Consider a TVS diode or transient suppression on the input supply if you expect noisy power (e.g., motor switching nearby).
   • Keep motor wiring physically separated from signal wiring to reduce injected noise.

9. Avoid sourcing high current from GPIO pins

   • Treat GPIO pins as control-level only. Don’t power LEDs, motors, or relay coils from GPIO pins. Use transistors, MOSFETs or driver ICs for loads.

10. Use good grounding practice

• Always connect ground between IoTiny and peripheral power supplies. Floating or reversed grounds cause odd current paths and damage.

11. Use proper measurement tools & safe testing methods

• When experimenting, use a bench supply with current limit set low (e.g., 1-2 A) to stop a fault before it causes damage.
• Use a multimeter to confirm voltages on Vcc pins before connecting delicate peripherals.

12. Firmware / software precautions (avoid surprise states)

• Don’t disable battery monitoring unless you are absolutely sure of the battery behavior. Battery-monitor can prevent brownout damage.
• Avoid connecting to unknown firmware-only updates from unreliable sources. Use official firmware from EZ-Robot / Synthiam.

Recommended parts / modules to add (low-cost protection)

• Small logic-level MOSFET or transistor boards for driving motors/relays.
• BEC / dedicated servo power supply or a regulated bench supply for testing.
• Level shifter module (e.g., 4-channel bi-directional I2C/logic level converter).
• 470-2200 F electrolytic capacitor near servo connectors + 0.1 F ceramic caps.
• Polyfuse (resettable) inline with servo supply.
• Small TVS diode on Vin for transient suppression.

Quick "pre-flight" testing routine before connecting peripherals

1. Power IoTiny alone, verify LED startup tone and AP appears.
2. With device powered, measure 3.3 V (Vcc) at the MCU and check VIN at supply. Confirm correct.
3. Plug in one servo / peripheral at a time. Watch supply voltage and startup LED.
4. If a peripheral causes LED change or reset, disconnect and test that peripheral on the bench supply with current-limiting.

Specific IoTiny guidance from the datasheet (important)

• Read the "Unregulated Power I/O" section on the IoTiny page - many ports are unregulated and can be the same voltage as Vin. Don’t assume VCC on port = 5V or 3.3V. Link: https://synthiam.com/Support/Hardware/EZ-B-IoTiny
• Camera and I2C ports are regulated; other ports may not be.

If you want, I can:

• Provide a simple wiring diagram for common use cases (servo bank + sensors + camera) showing separate power rails and common ground.
• Give a short checklist tailored to the exact devices you usually connect (tell me servos, motors, LED strips, sensors you used).
• Walk you through diagnostic steps (USB-TTL logs, multimeter checks) for the failed unit when you’re ready.

Follow-up question What peripherals do you typically connect to the IoTiny (servos: how many & voltage rating, motors, LED strips, sensors, external serial devices)? With that info I’ll give a short, exact wiring diagram and component list to protect your backup.