CW308T-ESP32 on a Husky (via CW313) — target silent on UART, and CW313 LED3 only lights dimly

Setup

  • ChipWhisperer-Husky, ESP32 target seated in the CW313 socket

  • Windows 11, ChipWhisperer 5.7.0, esptool 5.3.0

  • Using the prebuilt firmware/esp32 SimpleSerial images:

bootloader.bin @ 0x1000, partitions_singleapp.bin @ 0x8000, simpleserial.bin @ 0x10000

First thing I noticed (possible clue)

When I plug the ESP32 target in, CW313 LED3 lights up, but only dimly — a clearly “dimmed”, under-brightness glow, not the full brightness I’d expect. I don’t know whether that’s a power, clock, or strapping symptom, so flagging it up front.

What I tried

  • Provide the ESP32’s clock from the CW: scope.clock.clkgen_freq = 26e6, scope.io.hs2 = 'clkgen' → clkgen reports locked.

  • Keep tio1 = serial_rx, tio2 = serial_tx (Husky bridges the target UART through these).

  • Drive reset via scope.io.nrst, and run esptool over the Husky’s USB-CDC serial at 38400 baud (the firmware’s nominal 59000 scales to ~38400 at a 26 MHz clock).

Result


esptool v5.3.0

Serial port COM9

Connecting.............................

A fatal error occurred: Failed to connect to ESP32: No serial data received.

I then bypassed esptool and read the raw serial directly on a normal boot at 115200 / 74880 / 38400 / 57600 / 96000 bytes at every baud. The chip is completely silent.

For reference, a CW312T-K82F in the same Husky/CW313 socket works perfectly (clock on HS2, reset, and the CDC serial all fine), so the socket itself is good.

Questions

  1. The dim CW313 LED3 — what is LED3 meant to indicate, and is a dim/under-bright LED a sign of a power problem (target not getting full 3.3 V) or a clock/strap issue?

  2. Known-good flashing procedure — what’s the correct way to flash the CW308T-ESP32 from a Husky through the CW313? Specifically: clock source/frequency, required jumpers, serial routing, and how serial download mode is actually asserted. On the CW308T-ESP32 rev-02 schematic, PDIC maps to the SPI-flash level-shifter OE, not to GPIO0 — so how does GPIO0/IO0 get pulled low for ROM-bootloader entry? Is a physical strap/jumper on GPIO0 required?

  3. Serial port — is the Husky’s CDC serial usable for esptool here, or do I need a separate USB-UART adapter on the TXD/RXD nets?

  4. Jumpers — are there mandatory jumper settings on the ESP32 target and/or CW313 for clock and power that I might have missed (mine are at their defaults)?

Thanks for any pointers!

The LED is probably high-z and the LED is being powered through a pullup

According to chipwhisperer-jupyter/Setup_Scripts/Setup_CW308_ESP32.ipynb at main · newaetech/chipwhisperer-jupyter · GitHub, the correct clock frequency for this target is 7.37MHz, not 26MHz, so that’s likely the issue.

how is GPIO0 download-mode strap asserted from a Husky? esp_prog.py’s pdic=0 doesn’t seem to reach GPIO0

Setup: ChipWhisperer-Husky + CW308 (CW313), CW308T-ESP32 rev-02, Windows, ChipWhisperer 5.7.0 / esptool 5.3.0. Clock supplied on HS2.

I’m trying to flash via the Husky CDC serial. I followed the official esp_prog.py recipe (scope.io.pdic = 0, clkgen on HS2, reset pulse, esptool --before default-reset), and esptool always fails with:

A fatal error occurred: Failed to connect to ESP32: No serial data received.

The chip is clearly alive — at 7.37 MHz it powers up and floods the UART (I see RX overflow on the CW), so power/clock/serial routing are fine. It just never enters the ROM serial bootloader, i.e. GPIO0 isn’t being held low at reset.

Looking at the rev-02 schematic, PDIC maps to the SPI-flash level-shifter (TXB0104) OE, not to GPIO0 — so scope.io.pdic = 0 toggles the flash buffer, not the boot strap. That seems to explain why esp_prog.py can’t assert download mode on this revision.

Questions:

  1. On rev-02, how is GPIO0 supposed to be pulled low for ROM-bootloader entry from a Husky — is there a CW line I’m missing, or is a physical GPIO0→GND strap required?
  2. If a manual strap is needed, where does ESP32 GPIO0 break out (which CW308 header pin)?
  3. Is the CW CDC serial the intended esptool transport here, or should I use an external USB-UART on TXD/RXD with auto-reset?

Thanks!