Summary
Several users report that connecting an AMYboard to a Tulip CC using the Tulip's grove / STEMMA I2C header and the AMYboard's back "tulip" I2C host port sends the Tulip into a power boot loop (it resets repeatedly at/before the REPL).
This is the documented, supported hookup — from docs/amyboard/README.md: "you can directly connect your AMYboard to it via the GROVE port and the back I2C HOST connector. Tulip will power and communicate with the AMYboard!"
Leading hypothesis: the Tulip's power source can't feed both boards
When the AMYboard is connected this way and isn't separately powered, it pulls its power from the 3.3 V on the Tulip grove port. Our own docs give the numbers:
Adding ~350 mA @ 3.3 V (≈ +230–350 mA @ 5 V once you account for the regulator and losses) on top of Tulip's ~575 mA @ 5 V pushes the total toward — or past — what a marginal 5 V source can actually deliver. If the supply / cable / hub can't keep up, the 5 V rail sags, Tulip's 3.3 V regulator drops out, and the ESP32‑S3 brownout detector resets the chip. It then tries to boot, pulls the same current, browns out again → boot loop. Inrush is highest at boot, which fits a boot-loop symptom (rather than a mid-session crash).
This lines up with the usual real-world culprits:
- weak / old USB chargers (the ~0.5 A "computer USB port" class)
- charge-only or thin high-resistance USB-C cables
- powering Tulip from an unpowered hub
- a low battery
Light investigation — what I confirmed in the repo
- The supported path is grove ↔ AMYboard back "tulip" host port; the AMYboard front-panel I2C is for accessories, the back port is host / power-in (faq.md:110).
- AMYboard power inputs and the ~350 mA grove draw are as quoted above (measured ~2.94 V at the 4th board in a chain, per the same FAQ entry).
- I found no explicit ESP32 brownout-detector configuration in the Tulip firmware (
tulip/esp32s3), so it runs at the ESP-IDF default (brownout detector enabled) — consistent with a brownout-triggered reset loop.
- I found no current limiting / soft-start on the grove 3.3 V rail, and no power warning in the quick-start docs about the extra draw when attaching an AMYboard.
Note: the +5 V-side current estimate and the regulator topology are inferred, not bench-measured — worth confirming on hardware.
How an affected user can confirm it's power
- Watch the Tulip serial/boot log for
Brownout detector was triggered (or repeated resets).
- Power the AMYboard separately over its own USB-C — it takes the highest voltage present, so 5 V USB-C will feed it instead of pulling 3.3 V from the Tulip. If the loop stops, it's power.
- Try a known-good ≥1–2 A 5 V supply and a quality data USB-C cable, plugged straight in (no hub).
Possible resolutions
- Docs: add a power note to the AMYboard ↔ Tulip "Quick start - Tulip" section and Tulip troubleshooting — connecting an AMYboard adds ~350 mA, so use a ≥1–2 A supply or power the AMYboard on its own USB-C.
- Bench check: measure the 5 V / 3.3 V rails at boot with an AMYboard attached on a 1 A vs 2 A supply; confirm brownout vs. regulator dropout vs. inrush.
- If a firmware change can help (e.g. deferring high-current init, ramping display brightness at boot), treat as a firmware bug.
Asks for reporters
If you hit this, please share: Tulip hardware rev, what's powering it (charger/cable/hub/battery + rated amps), whether the AMYboard had its own power, and any boot-log output.
Filed from a maintainer investigation; numbers cited are from the repo docs unless marked inferred.
Summary
Several users report that connecting an AMYboard to a Tulip CC using the Tulip's grove / STEMMA I2C header and the AMYboard's back "tulip" I2C host port sends the Tulip into a power boot loop (it resets repeatedly at/before the REPL).
This is the documented, supported hookup — from docs/amyboard/README.md: "you can directly connect your AMYboard to it via the GROVE port and the back I2C HOST connector. Tulip will power and communicate with the AMYboard!"
Leading hypothesis: the Tulip's power source can't feed both boards
When the AMYboard is connected this way and isn't separately powered, it pulls its power from the 3.3 V on the Tulip grove port. Our own docs give the numbers:
Adding ~350 mA @ 3.3 V (≈ +230–350 mA @ 5 V once you account for the regulator and losses) on top of Tulip's ~575 mA @ 5 V pushes the total toward — or past — what a marginal 5 V source can actually deliver. If the supply / cable / hub can't keep up, the 5 V rail sags, Tulip's 3.3 V regulator drops out, and the ESP32‑S3 brownout detector resets the chip. It then tries to boot, pulls the same current, browns out again → boot loop. Inrush is highest at boot, which fits a boot-loop symptom (rather than a mid-session crash).
This lines up with the usual real-world culprits:
Light investigation — what I confirmed in the repo
tulip/esp32s3), so it runs at the ESP-IDF default (brownout detector enabled) — consistent with a brownout-triggered reset loop.How an affected user can confirm it's power
Brownout detector was triggered(or repeated resets).Possible resolutions
Asks for reporters
If you hit this, please share: Tulip hardware rev, what's powering it (charger/cable/hub/battery + rated amps), whether the AMYboard had its own power, and any boot-log output.
Filed from a maintainer investigation; numbers cited are from the repo docs unless marked inferred.