ESP32-C6 esphosted firmware not loaded for Firebeetle 2 ESP32-P4 AI board?
Rogan.Dawes 2026-01-26 21:10:15 6221 Views8 Replies Hi,
I have bought a DFR1172 (FireBeetle 2 ESP32-P4 AI Vision Board), with ESP32-C6 wifi coprocessor. However, it turns out that there is no firmware loaded on the C6 as received from the factory, and therefore the ESP32-P4 cannot talk to it. Additionally, while the SDIO pins are connected to the P4, and this should allow for firmware upgrades, this obviously only applies when there is already firmware on the board to start with!
Worse, while the schematic indicates that there are GPIO9, RST, RX and TX pins available for reprogramming, these are only available as pads on the underside of the board, using what appears to be 2mm spacing. Even more unfortunately, there are no labels for the pads, and no obvious way to figure out the pinout, other than continuity for Gnd and 3v3, and using a UART to find TX from the C6 when it boots. That still leaves RX, GPIO9 and RST, and the small problem of making a pogo pin jig to do the initial programming of the esphosted firmware.
Please can someone confirm the pinout? And perhaps consider programming an initial version of the ESPHosted firmware at the factory to save people this hassle in the future?
@Rogan.Dawes - it's not blank, it's mis-flashed (and here's the pinout)
Same error here on a DFR1172: "sdmmc_io_send_op_cond ... returned 0x107", then
"sdmmc_card_init failed". I dumped the C6's 4 MB flash before touching anything,
and it is NOT empty. It holds DFRobot's own C6_v14_eco2_0022.bin byte-for-byte
(SHA-256 verified) - just written at the wrong address: offset 0x10000 instead
of 0x0. Because of that, the partition table's "factory" slot points at a second
bootloader whose RAM overlaps the running bootloader, so it is rejected as "not
bootable" and the C6 just reboots. From the P4 side it looks exactly like "no
firmware", but the bytes are all there, only 64 KB too high.
Pinout for the four underside pads, left to right: IO9/BOOT, C6 RX, C6 TX, GND.
There are separate RST and 3V3 pads. What worked for me:
- Wire TX, RX and GND only. Power the board from its own USB-C. Do NOT feed the
programmer's 5V into the board (see my note to DFRobot below - it is dangerous
on this board).
- Park the P4 in its ROM bootloader first so it stops driving the C6 reset line:
esptool --chip esp32p4 --port <P4> --before default-reset --after no-reset flash-id
- Enter download mode: hold IO9/BOOT low, pulse RST, release. Then write DFRobot's
merged image at 0x0 (their Flash Download Tool uses 0x0 - that is the correct
base). On a recent arduino-esp32 host, follow up with the matching esp-hosted
slave build so host and slave versions line up.
Back up the existing flash first so you have a restore point.
---
@DFRobot - this looks like a factory-provisioning defect, please confirm
You have said the C6 comes pre-programmed with esp-hosted from the factory. On my
unit it IS programmed, but at the wrong flash offset (0x10000 instead of 0x0),
byte-identical to your published C6_v14_eco2_0022.bin. That is not a version or
config problem - the image simply cannot boot from where it was written. With at
least two of us in this thread hitting the identical 0x107 on the same board:
1. Is the intended factory layout the merged image at 0x0? Please confirm the
correct offset AND a checksum, so owners can verify their unit.
2. Is this a known bad batch or QA escape? If so, which lots, and will affected
units be reflashed or replaced - rather than leaving customers to build a
pogo-pin jig on unlabeled 2 mm pads?
3. Safety: your wiki doc 21646 wiring diagram routes the programmer's 5V to a pad
silkscreened "NC". Following it made my board heat up noticeably near the
DSI/CSI connectors. I removed power immediately and it survived, but please
correct that diagram - Espressif's own guidance is "do not connect VDD".
Happy to share the flash dump, offsets and hashes if that helps.
Mattias.Brandt Clarification on the pads: DFRobot's own doc 21646 is inconsistent here. Its
Hardware Connection figure and its "Introduction to Test Points" figure put GND
and ESP32C6_IO9/BOOT in swapped positions, and the pads are unlabeled on the
board. What actually worked for me was three wires only:
GND, ESP32C6_RX, ESP32C6_TX (no 5V, no IO9/BOOT)
RX/TX are the unambiguous middle pads, and a read/flash doesn't need the BOOT pad
(the C6 enters download without it). Best to confirm GND by continuity to a known
ground rather than trust either figure for the two outer pads.
Correcting myself - and doc 21646 https://wiki.dfrobot.com/dfr1172/docs/21646 is why I got it wrong
Retracting one line from my clarification above. I said a read/flash doesn't need the BOOT pad because the C6 enters download without it. That's wrong. My earlier post was right: hold IO9/BOOT low, pulse RST, release.
The confusion comes from doc 21646. Its Hardware Connection figure routes the programmer's GND onto the leftmost pad, and that pad is not GND - it is the C6's IO9/BOOT. So you silently strap BOOT low. While flashing, that looks like it works. But leave the wire on and the C6 never boots from flash at all, it just sits in download mode, which from the P4 side is indistinguishable from a dead or blank chip. I suspect that's a big part of why this board keeps getting reported as unprogrammed.
The giveaway was the boot mode byte. I was seeing boot:0x0, which means both strapping pins were low. GPIO9 has an internal pull-up, so something was pulling it down - my ground wire, sitting exactly where the diagram said to put it.
Measured pinout, all jumpers removed, continuity against known grounds. Left to right the four pads are IO9/BOOT, then C6 RX, then C6 TX, then GND. The Test Points figure is the correct one, the Hardware Connection figure is not. If you need to find them: the GND pad is the one nearest the 48/49/50 header, and the only one of the four with two more pads stacked below it.
Handy for anyone checking their own board - the USB-serial adapter and the board already share ground through your PC, so you only need one contact, your adapter's RX on the C6 TX pad. No jig needed.
With BOOT released the fault is obvious. I captured 118 consecutive boot cycles, every one of them SPI_FAST_FLASH_BOOT, and every one failing the same way: segment 0 at 0x40875720 overlaps bootloader stack, factory app partition is not bootable, no bootable app partitions, reset, repeat. Not one ESP-Hosted or SDIO slave banner in 118 attempts. The app never runs, so there is no slave to answer CMD5. That is the 0x107 everyone here is hitting.
So erhahaha is right that the board ships programmed. The bytes are DFRobot's own C6_v14_eco2_0022.bin, all 1178352 of them, SHA-256 starting d8625fd1. They're just written at 0x10000 instead of 0x0, which has the same practical effect as shipping it blank. The silicon itself is fine - it boots, reads flash, and correctly rejects a bad image.
Three asks. First, please fix the Hardware Connection figure - it grounds IO9/BOOT while calling that wire GND, and it contradicts the Test Points figure in the same document. Second, please fix the 5V routing in that figure too; it sends 5V to a pad silkscreened NC, and following it heated my board near the DSI/CSI connectors. Espressif's guidance for this is do not connect VDD. Third, please put the flash offset in the text rather than only in a screenshot - it's 0x0 - and it's worth checking whether a whole batch went out programmed at 0x10000.
Happy to share the dump, partition tables, hashes and the full boot log. I haven't reflashed yet, since that boot log is the only thing separating misprogrammed from defective and reflashing destroys it.
It seems that by default, the FireBeetle 2 ESP32-P4 AI Vision Board does not expose the ESP32-C6 Wi-Fi coprocessor firmware interface, so the ESP-Hosted firmware didn’t appear to be running out of the box.
see this
https://wiki.dfrobot.com/FireBeetle_2_ESP32-P4_AI_Vision_Board_SKU_R1172
the Wi-Fi coprocessor has to load ESP-Hosted firmware image into the flash region so after that the host MCU can use it.
are you using the correct ESP-Hosted binary image for your board revision and flash tool (ESP-IDF and esptool) recommended by DFRobot? The wiki has links and instructions under the “Program ESP32-C6 Wi-Fi Coprocessor” section.
are you sure that the board enters the correct bootloader mode for the Wi-Fi coprocessor flash pins?
Oliver.Taylor Thank you for your feedback and suggestions. The ESP32-C6 comes pre-programmed with the esp-hosted firmware from the factory. In response to your suggestions, we have added the ESP32-C6 firmware programming tutorial to the Wiki: https://wiki.dfrobot.com/SKU_DFR1172_FireBeetle_2_Board_ESP32_P4#9.%20ESP32-C6%20Firmware%20update
erhahaha Could you confirm which version of esp-hosted is flashed on the C6, if not a versioned release then which commit SHA ref?
+1, feels pretty poor to just have the schematic with random net names scattered throughout and test points not in the connector / footprint shape.
Maybe next time indicate which is test point 1 on the silkscreen labels (you could have shifted the logo and board name up a bit / elsewhere).
Updating the board function image on the wiki page to label the test points would be a good stop-gap solution:
My log is showing this, using an arduino-esp32 (v3.3.6) sketch known to work with the Waveshare-P4-WIFI6 (same co-processor / esp-hosted setup):
```
19:24:51:914 -> E (2331) sdio_wrapper: sdio_card_fn_init failed
19:24:52:043 -> E (2461) sdmmc_io: sdmmc_init_io: sdmmc_io_send_op_cond (1) returned 0x107
19:24:52:044 -> E (2461) sdio_wrapper: sdmmc_card_init failed
19:24:52:284 -> E (2701) sdio_wrapper: sdio_card_fn_init failed
19:24:52:425 -> E (2842) sdmmc_io: sdmmc_io_read_byte: sdmmc_io_rw_direct (read 0x3) returned 0x107
19:24:52:426 -> E (2842) sdio_wrapper: sdio_card_fn_init failed
19:24:52:665 -> E (3083) sdio_wrapper: sdio_card_fn_init failed
19:24:52:795 -> E (3213) sdmmc_io: sdmmc_init_io: sdmmc_io_send_op_cond (1) returned 0x107
19:24:52:796 -> E (3213) sdio_wrapper: sdmmc_card_init failed
19:24:52:925 -> E (3343) sdmmc_io: sdmmc_init_io: sdmmc_io_send_op_cond (1) returned 0x107
19:24:52:926 -> E (3343) sdio_wrapper: sdmmc_card_init failed
19:24:53:165 -> E (3583) sdio_wrapper: sdio_card_fn_init failed
19:24:53:307 -> E (3724) sdmmc_io: sdmmc_io_read_byte: sdmmc_io_rw_direct (read 0x3) returned 0x107
19:24:53:307 -> E (3724) sdio_wrapper: sdio_card_fn_init failed
19:24:53:547 -> E (3965) sdio_wrapper: sdio_card_fn_init failed
19:24:53:678 -> E (4095) sdmmc_io: sdmmc_init_io: sdmmc_io_send_op_cond (1) returned 0x107
19:24:53:678 -> E (4095) sdio_wrapper: sdmmc_card_init failed
19:24:53:807 -> E (4225) sdmmc_io: sdmmc_init_io: sdmmc_io_send_op_cond (1) returned 0x107
19:24:53:808 -> E (4225) sdio_wrapper: sdmmc_card_init failed
19:24:54:047 -> E (4465) sdio_wrapper: sdio_card_fn_init failed
19:24:54:178 -> E (4595) sdmmc_io: sdmmc_io_read_byte: sdmmc_io_rw_direct (read 0x3) returned 0x107
19:24:54:178 -> E (4596) sdio_wrapper: sdio_card_fn_init failed
19:24:54:309 -> E (4726) sdmmc_io: sdmmc_init_io: sdmmc_io_send_op_cond (1) returned 0x107
19:24:54:310 -> E (4726) sdio_wrapper: sdmmc_card_init failed
19:24:54:409 -> E (4826) H_SDIO_DRV: card init failed
19:24:54:410 -> E (4826) transport: ensure_slave_bus_ready failed
19:24:54:413 -> xffffffff (ESP_FAIL) at 0x400a0632
19:24:54:420 -> file: "./managed_components/espressif__esp_hosted/host/api/src/esp_hosted_api.c" line 179
19:24:54:423 -> func: esp_hosted_reconfigure
19:24:54:426 -> expression: transport_drv_reconfigure()
19:24:54:430 -> E (4844) H_API: ESP-Hosted link not yet up
19:24:54:439 -> [ 4866][E][esp32-hal-hosted.c:83] hostedHasUpdate(): Could not get slave firmware version: ESP_FAIL
19:24:54:451 -> [ 4886][I][esp32-hal-hosted.c:88] hostedHasUpdate(): Host firmware version: 2.9.6
19:24:54:458 -> [ 4894][I][esp32-hal-hosted.c:89] hostedHasUpdate(): Slave firmware version: 0.0.0
19:24:54:465 -> [ 4901][W][esp32-hal-hosted.c:98] hostedHasUpdate(): Version on Host is NEWER than version on co-processor
19:24:54:478 -> [ 4911][W][esp32-hal-hosted.c:99] hostedHasUpdate(): Update URL: https://espressif.github.io/arduino-esp32/hosted/esp32c6-v2.9.6.bin
19:24:56:148 -> E (6565) sdio_wrapper: sdio_card_fn_init failed
19:24:56:278 -> E (6695) sdmmc_io: sdmmc_init_io: sdmmc_io_send_op_cond (1) returned 0x107
19:24:56:278 -> E (6695) sdio_wrapper: sdmmc_card_init failed
19:24:56:407 -> E (6825) sdmmc_io: sdmmc_init_io: sdmmc_io_send_op_cond (1) returned 0x107
19:24:56:408 -> E (6825) sdio_wrapper: sdmmc_card_init failed
19:24:56:648 -> E (7065) sdio_wrapper: sdio_card_fn_init failed
19:24:56:790 -> E (7206) sdmmc_io: sdmmc_io_read_byte: sdmmc_io_rw_direct (read 0x3) returned 0x107
19:24:56:791 -> E (7206) sdio_wrapper: sdio_card_fn_init failed
19:24:57:030 -> E (7447) sdio_wrapper: sdio_card_fn_init failed
19:24:57:160 -> E (7577) sdmmc_io: sdmmc_init_io: sdmmc_io_send_op_cond (1) returned 0x107
19:24:57:161 -> E (7577) sdio_wrapper: sdmmc_card_init failed
19:24:57:291 -> E (7707) sdmmc_io: sdmmc_init_io: sdmmc_io_send_op_cond (1) returned 0x107
19:24:57:292 -> E (7707) sdio_wrapper: sdmmc_card_init failed
19:24:57:530 -> E (7947) sdio_wrapper: sdio_card_fn_init failed
19:24:57:672 -> E (8088) sdmmc_io: sdmmc_io_read_byte: sdmmc_io_rw_direct (read 0x3) returned 0x107
19:24:57:672 -> E (8088) sdio_wrapper: sdio_card_fn_init failed
19:24:57:912 -> E (8329) sdio_wrapper: sdio_card_fn_init failed
19:24:58:042 -> E (8459) sdmmc_io: sdmmc_init_io: sdmmc_io_send_op_cond (1) returned 0x107
19:24:58:043 -> E (8459) sdio_wrapper: sdmmc_card_init failed
19:24:58:172 -> E (8589) sdmmc_io: sdmmc_init_io: sdmmc_io_send_op_cond (1) returned 0x107
19:24:58:172 -> E (8589) sdio_wrapper: sdmmc_card_init failed
19:24:58:412 -> E (8829) sdio_wrapper: sdio_card_fn_init failed
19:24:58:542 -> E (8959) sdmmc_io: sdmmc_io_read_byte: sdmmc_io_rw_direct (read 0x2) returned 0x107
19:24:58:542 -> E (8960) sdio_wrapper: sdio_card_fn_init failed
19:24:58:643 -> E (9060) H_SDIO_DRV: card init failed
19:24:58:644 -> E (9060) transport: ensure_slave_bus_ready failed
19:24:58:646 -> ESP_ERROR_CHECK_WITHOUT_ABORT failed: esp_err_t 0xffffffff (ESP_FAIL) at 0x400a0632
19:24:58:654 -> file: "./managed_components/espressif__esp_hosted/host/api/src/esp_hosted_api.c" line 179
19:24:58:657 -> func: esp_hosted_reconfigure
19:24:58:660 -> expression: transport_drv_reconfigure()
19:24:58:664 -> E (9078) H_API: ESP-Hosted link not yet up
19:24:58:672 -> [ 9100][E][WiFiGeneric.cpp:284] wifiLowLevelInit(): esp_wifi_init 0xffffffff: ESP_FAIL
19:24:58:683 -> E (9101) H_API: ESP-Hosted link not yet up
19:24:58:684 -> [ 9119][E][STA.cpp:530] disconnect(): STA disconnect failed! 0xffffffff: ESP_FAIL
19:24:58:795 -> [ 9230][I][esp32-hal-hosted.c:275] hostedInitWiFi(): Initializing ESP-Hosted for WiFi
19:25:00:462 -> E (10880) sdio_wrapper: sdio_card_fn_init failed
19:25:00:593 -> E (11010) sdmmc_io: sdmmc_init_io: sdmmc_io_send_op_cond (1) returned 0x107
19:25:00:594 -> E (11010) sdio_wrapper: sdmmc_card_init failed
19:25:00:724 -> E (11140) sdmmc_io: sdmmc_init_io: sdmmc_io_send_op_cond (1) returned 0x107
19:25:00:725 -> E (11140) sdio_wrapper: sdmmc_card_init failed
19:25:00:963 -> E (11380) sdio_wrapper: sdio_card_fn_init failed
19:25:01:104 -> E (11521) sdmmc_io: sdmmc_io_read_byte: sdmmc_io_rw_direct (read 0x3) returned 0x107
19:25:01:104 -> E (11521) sdio_wrapper: sdio_card_fn_init failed
19:25:01:345 -> E (11762) sdio_wrapper: sdio_card_fn_init failed
19:25:01:475 -> E (11892) sdmmc_io: sdmmc_init_io: sdmmc_io_send_op_cond (1) returned 0x107
19:25:01:475 -> E (11892) sdio_wrapper: sdmmc_card_init failed
19:25:01:605 -> E (12022) sdmmc_io: sdmmc_init_io: sdmmc_io_send_op_cond (1) returned 0x107
19:25:01:605 -> E (12022) sdio_wrapper: sdmmc_card_init failed
19:25:01:845 -> E (12262) sdio_wrapper: sdio_card_fn_init failed
19:25:01:975 -> E (12392) sdmmc_io: sdmmc_io_read_byte: sdmmc_io_rw_direct (read 0x2) returned 0x107
19:25:01:975 -> E (12393) sdio_wrapper: sdio_card_fn_init failed
19:25:02:106 -> E (12523) sdmmc_io: sdmmc_init_io: sdmmc_io_send_op_cond (1) returned 0x107
19:25:02:106 -> E (12523) sdio_wrapper: sdmmc_card_init failed
19:25:02:236 -> E (12653) sdmmc_io: sdmmc_init_io: sdmmc_io_send_op_cond (1) returned 0x107
19:25:02:236 -> E (12653) sdio_wrapper: sdmmc_card_init failed
19:25:02:476 -> E (12893) sdio_wrapper: sdio_card_fn_init failed
19:25:02:606 -> E (13023) sdmmc_io: sdmmc_init_io: sdmmc_io_send_op_cond (1) returned 0x107
19:25:02:606 -> E (13023) sdio_wrapper: sdmmc_card_init failed
19:25:02:736 -> E (13153) sdmmc_io: sdmmc_init_io: sdmmc_io_send_op_cond (1) returned 0x107
19:25:02:748 -> E (13153) sdio_wrapper: sdmmc_card_init failed
19:25:02:836 -> E (13253) H_SDIO_DRV: card init failed
19:25:02:836 -> E (13253) transport: ensure_slave_bus_ready failed
19:25:02:839 -> ESP_ERROR_CHECK_WITHOUT_ABORT failed: esp_err_t 0xffffffff (ESP_FAIL) at 0x400a0632
19:25:02:847 -> file: "./managed_components/espressif__esp_hosted/host/api/src/esp_hosted_api.c" line 179
19:25:02:850 -> func: esp_hosted_reconfigure
19:25:02:854 -> expression: transport_drv_reconfigure()
19:25:02:857 -> E (13271) H_API: ESP-Hosted link not yet up
19:25:02:865 -> [ 13294][E][WiFiGeneric.cpp:284] wifiLowLevelInit(): esp_wifi_init 0xffffffff: ESP_FAIL
19:25:02:877 -> E (13294) H_API: ESP-Hosted link not yet up
```
tyethgundry Thank you for your feedback and suggestions. The ESP32-C6 comes pre-programmed with the esp-hosted firmware from the factory. In response to your suggestions, we have added the ESP32-C6 firmware programming tutorial to the Wiki: https://wiki.dfrobot.com/SKU_DFR1172_FireBeetle_2_Board_ESP32_P4#9.%20ESP32-C6%20Firmware%20update
