ESP32C3 custom PCB USB/JTAG boot issue
ESP32C3 custom PCB USB/JTAG boot issue
Hi,
I am working on a project using the ESP32C3 as main MCU.
We designed a custom PCB that uses the integrated USB/JTAG to flash/debug in order to free UART0.
The board is powered by battery and we use the USB to also charge this battery.
Now here is the problem :
When the board is only powered by the battery (or PSU) the device does not seem to boot.
We flashed a "blink" program and nothing happens.
But now when we plug in a USB cable connected to a computer, the devices boot up and the LED starts blinking. Then the program keep running even if the USB is unplugged.
- we tried to use a "power only" USB and the device does not boot
- when USB D+ is shorted to ground, the device boot
- we tried to add a pull down to D+ but it does not help
- we added the missing capacitor on CHIP_EN but it does not help
- strapping pin are correctly configured
We cannot start a debug session because as soon as we plug the USB the device is working as expected.
So it "looks like" the device is not booting but we cannot be sure.
You will find attached the schematics of the board for MCU and USB/charger components.
If you have any idea about what could be the problem here or what we could try to identify it, feel free to share it with us.
Regards
I am working on a project using the ESP32C3 as main MCU.
We designed a custom PCB that uses the integrated USB/JTAG to flash/debug in order to free UART0.
The board is powered by battery and we use the USB to also charge this battery.
Now here is the problem :
When the board is only powered by the battery (or PSU) the device does not seem to boot.
We flashed a "blink" program and nothing happens.
But now when we plug in a USB cable connected to a computer, the devices boot up and the LED starts blinking. Then the program keep running even if the USB is unplugged.
- we tried to use a "power only" USB and the device does not boot
- when USB D+ is shorted to ground, the device boot
- we tried to add a pull down to D+ but it does not help
- we added the missing capacitor on CHIP_EN but it does not help
- strapping pin are correctly configured
We cannot start a debug session because as soon as we plug the USB the device is working as expected.
So it "looks like" the device is not booting but we cannot be sure.
You will find attached the schematics of the board for MCU and USB/charger components.
If you have any idea about what could be the problem here or what we could try to identify it, feel free to share it with us.
Regards
- Attachments
-
- esp32c3_usb_jtag_schematic.pdf
- (2.6 MiB) Downloaded 435 times
-
- Posts: 9711
- Joined: Thu Nov 26, 2015 4:08 am
Re: ESP32C3 custom PCB USB/JTAG boot issue
Could you check if the chip outputs something on U0TXD in that situation?
Re: ESP32C3 custom PCB USB/JTAG boot issue
Hi and thanks for your reply,
I connected a logic analyzer on the UART0TX test point and you will find the result attached.
It looks like the esp32c3 is booting but then after 10 seconds it gets reset by the watchdog :
I also captured the boot with the USB pluged in and the logs are exactly the same, except that it does not get reset after 10 seconds.
Thanks for your help
I connected a logic analyzer on the UART0TX test point and you will find the result attached.
It looks like the esp32c3 is booting but then after 10 seconds it gets reset by the watchdog :
Code: Select all
ESP-ROM:esp32c3-api1-20210207
Build:Feb 7 2021
rst:0x1 (POWERON)COMMAboot:0x9 (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIOCOMMA clock div:1
load:0x3fcd6100COMMAlen:0x172c
load:0x403ce000COMMAlen:0x924
load:0x403d0000COMMAlen:0x2d60
entry 0x403ce000
\x1B[0;32mI (30) boot: ESP-IDF v4.4-dev-3235-g3e370c4296 2nd stage bootloader\x1B[0m
\x1B[0;32mI (30) boot: compile time 18:55:51\x1B[0m
\x1B[0;32mI (30) boot: chip revision: 3\x1B[0m
\x1B[0;32mI (33) boot.esp32c3: SPI Speed : 80MHz\x1B[0m
\x1B[0;32mI (38) boot.esp32c3: SPI Mode : DIO\x1B[0m
\x1B[0;32mI (43) boot.esp32c3: SPI Flash Size : 4MB\x1B[0m
\x1B[0;32mI (48) boot: Enabling RNG early entropy source...\x1B[0m
\x1B[0;32mI (53) boot: Partition Table:\x1B[0m
\x1B[0;32mI (57) boot: ## Label Usage Type ST Offset Length\x1B[0m
\x1B[0;32mI (64) boot: 0 nvs WiFi data 01 02 00009000 00006000\x1B[0m
\x1B[0;32mI (71) boot: 1 phy_init RF data 01 01 0000f000 00001000\x1B[0m
\x1B[0;32mI (79) boot: 2 factory factory app 00 00 00010000 00100000\x1B[0m
\x1B[0;32mI (86) boot: End of partition table\x1B[0m
\x1B[0;32mI (91) esp_image: segment 0: paddr=00010020 vaddr=3c090020 size=1bfa8h (114600) map\x1B[0m
\x1B[0;32mI (117) esp_image: segment 1: paddr=0002bfd0 vaddr=3fc8d000 size=02314h ( 8980) load\x1B[0m
\x1B[0;32mI (119) esp_image: segment 2: paddr=0002e2ec vaddr=40380000 size=01d2ch ( 7468) load\x1B[0m
\x1B[0;32mI (124) esp_image: segment 3: paddr=00030020 vaddr=42000020 size=86764h (550756) map\x1B[0m
\x1B[0;32mI (217) esp_image: segment 4: paddr=000b678c vaddr=40381d2c size=0b148h ( 45384) load\x1B[0m
\x1B[0;32mI (226) esp_image: segment 5: paddr=000c18dc vaddr=50000000 size=00010h ( 16) load\x1B[0m
\x1B[0;32mI (230) boot: Loaded app from partition at offset 0x10000\x1B[0m
\x1B[0;32mI (230) boot: Disabling RNG early entropy source...\x1B[0m
\x1B[0;32mI (235) cpu_start: Pro cpu up.\x1B[0m
\x1B[0;32mI (302) cpu_start: Pro cpu start user code\x1B[0m
\x1B[0;32mI (302) cpu_start: cpu freq: 160000000\x1B[0m
\x1B[0;32mI (302) cpu_start: Application information:\x1B[0m
\x1B[0;32mI (305) cpu_start: Project name: ble_ibeacon_demo\x1B[0m
\x1B[0;32mI (311) cpu_start: App version: 1\x1B[0m
\x1B[0;32mI (315) cpu_start: Compile time: Aug 18 2022 18:55:40\x1B[0m
\x1B[0;32mI (321) cpu_start: ELF file SHA256: c22ce36133b970b1...\x1B[0m
\x1B[0;32mI (327) cpu_start: ESP-IDF: v4.4-dev-3235-g3e370c4296\x1B[0m
\x1B[0;32mI (334) heap_init: Initializing. RAM available for dynamic allocation:\x1B[0m
\x1B[0;32mI (341) heap_init: At 3FC93690 len 0002C970 (178 KiB): DRAM\x1B[0m
\x1B[0;32mI (347) heap_init: At 3FCC0000 len 0001F060 (124 KiB): STACK/DRAM\x1B[0m
\x1B[0;32mI (354) heap_init: At 50000010 len 00001FF0 (7 KiB): RTCRAM\x1B[0m
10 seconds elapsed
ESP-ROM:esp32c3-api1-20210207
Build:Feb 7 2021
rst:0x10 (RTCWDT_RTC_RST)COMMAboot:0x9 (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIOCOMMA clock div:1
load:0x3fcd6100COMMAlen:0x172c
load:0x403ce000COMMAlen:0x924
load:0x403d0000COMMAlen:0x2d60
entry 0x403ce000
\x1B[0;32mI (31) boot: ESP-IDF v4.4-dev-3235-g3e370c4296 2nd stage bootloader\x1B[0m
\x1B[0;32mI (31) boot: compile time 18:55:51\x1B[0m
\x1B[0;32mI (31) boot: chip revision: 3\x1B[0m
\x1B[0;32mI (34) boot.esp32c3: SPI Speed : 80MHz\x1B[0m
\x1B[0;32mI (39) boot.esp32c3: SPI Mode : DIO\x1B[0m
\x1B[0;32mI (44) boot.esp32c3: SPI Flash Size : 4MB\x1B[0m
\x1B[0;32mI (48) boot: Enabling RNG early entropy source...\x1B[0m
\x1B[0;32mI (54) boot: Partition Table:\x1B[0m
\x1B[0;32mI (57) boot: ## Label Usage Type ST Offset Length\x1B[0m
\x1B[0;32mI (65) boot: 0 nvs WiFi data 01 02 00009000 00006000\x1B[0m
\x1B[0;32mI (72) boot: 1 phy_init RF data 01 01 0000f000 00001000\x1B[0m
\x1B[0;32mI (80) boot: 2 factory factory app 00 00 00010000 00100000\x1B[0m
\x1B[0;32mI (87) boot: End of partition table\x1B[0m
\x1B[0;32mI (91) esp_image: segment 0: paddr=00010020 vaddr=3c090020 size=1bfa8h (114600) map\x1B[0m
\x1B[0;32mI (118) esp_image: segment 1: paddr=0002bfd0 vaddr=3fc8d000 size=02314h ( 8980) load\x1B[0m
\x1B[0;32mI (120) esp_image: segment 2: paddr=0002e2ec vaddr=40380000 size=01d2ch ( 7468) load\x1B[0m
\x1B[0;32mI (125) esp_image: segment 3: paddr=00030020 vaddr=42000020 size=86764h (550756) map\x1B[0m
\x1B[0;32mI (218) esp_image: segment 4: paddr=000b678c vaddr=40381d2c size=0b148h ( 45384) load\x1B[0m
\x1B[0;32mI (227) esp_image: segment 5: paddr=000c18dc vaddr=50000000 size=00010h ( 16) load\x1B[0m
\x1B[0;32mI (231) boot: Loaded app from partition at offset 0x10000\x1B[0m
\x1B[0;32mI (231) boot: Disabling RNG early entropy source...\x1B[0m
\x1B[0;32mI (236) cpu_start: Pro cpu up.\x1B[0m
\x1B[0;32mI (303) cpu_start: Pro cpu start user code\x1B[0m
\x1B[0;32mI (303) cpu_start: cpu freq: 160000000\x1B[0m
\x1B[0;32mI (303) cpu_start: Application information:\x1B[0m
\x1B[0;32mI (306) cpu_start: Project name: ble_ibeacon_demo\x1B[0m
\x1B[0;32mI (311) cpu_start: App version: 1\x1B[0m
\x1B[0;32mI (316) cpu_start: Compile time: Aug 18 2022 18:55:40\x1B[0m
\x1B[0;32mI (322) cpu_start: ELF file SHA256: c22ce36133b970b1...\x1B[0m
\x1B[0;32mI (328) cpu_start: ESP-IDF: v4.4-dev-3235-g3e370c4296\x1B[0m
\x1B[0;32mI (334) heap_init: Initializing. RAM available for dynamic allocation:\x1B[0m
\x1B[0;32mI (341) heap_init: At 3FC93690 len 0002C970 (178 KiB): DRAM\x1B[0m
\x1B[0;32mI (348) heap_init: At 3FCC0000 len 0001F060 (124 KiB): STACK/DRAM\x1B[0m
\x1B[0;32mI (354) heap_init: At 50000010 len 00001FF0 (7 KiB): RTCRAM\x1B[0m
Thanks for your help
- Attachments
-
- ibeacon_noUSB.txt
- (5.51 KiB) Downloaded 230 times
-
- Posts: 9711
- Joined: Thu Nov 26, 2015 4:08 am
Re: ESP32C3 custom PCB USB/JTAG boot issue
That is very odd. What is your primary/secondary console selection in menuconfig? In general, any chance of you sharing the project you have there (if possible, whittled down to the minimum that shows this issue)?
-
- Posts: 4
- Joined: Mon Aug 15, 2022 6:55 am
Re: ESP32C3 custom PCB USB/JTAG boot issue
I have also run into same problem once but the board was not esp32. In my case program also starts to run when I connect the usb and does not run without it. But after lot of debugging I found out that I am using
check if you doing something like this.
Code: Select all
while(!Serial)
Re: ESP32C3 custom PCB USB/JTAG boot issue
Yes that is a really strange behavior.
Primary output is USB/JTAG and secondary is none.
I tried with an iBeacon example and I have the same beahavior.
Here is a Google Drive link to download the project : https://drive.google.com/file/d/1pR6g3Z ... p=drivesdk
What I plan to test :
- change log to UART0 to see if I can get more informations about the cause of the watchdog reset
- flash the same project on an esp32c3 devkit to see if we have the same problem on it
I am on vacations this week so I will try these next week.
In the meantime I will come here regularly to check if you have any question or suggestion.
Once again thank you for your help
Primary output is USB/JTAG and secondary is none.
I tried with an iBeacon example and I have the same beahavior.
Here is a Google Drive link to download the project : https://drive.google.com/file/d/1pR6g3Z ... p=drivesdk
What I plan to test :
- change log to UART0 to see if I can get more informations about the cause of the watchdog reset
- flash the same project on an esp32c3 devkit to see if we have the same problem on it
I am on vacations this week so I will try these next week.
In the meantime I will come here regularly to check if you have any question or suggestion.
Once again thank you for your help
Re: ESP32C3 custom PCB USB/JTAG boot issue
One point please be noted, not saying it is the cause of the problem, but it will lead to other problems, that is, resistor at XTAL_P should be populated with 24 nH initially.
Re: ESP32C3 custom PCB USB/JTAG boot issue
Just checking...
You are using some of the strapping pins. GPIO 2,8,9. Have you made sure they are in the proper state when booting.
You are using some of the strapping pins. GPIO 2,8,9. Have you made sure they are in the proper state when booting.
Re: ESP32C3 custom PCB USB/JTAG boot issue
Hi,
I'm working with Zoptune on this project. I've tested the iBeacon firmware provided by Zoptune, with ESP32-C3-32S dev kit from NodeMCU.
I'm using the following commands :
The firmware starts correctly, I can see advertising packets with my smartphone.
Then, I change the console output :
The firmware does not start, you can find the debug output attached.
For strapping pins :
I've set GPIO9 to a high level at boot. GPIO8 and GPIO2 are in an unknown state. I'll give another try with GPIO2 at high level (but I think I did this test).
I'm working with Zoptune on this project. I've tested the iBeacon firmware provided by Zoptune, with ESP32-C3-32S dev kit from NodeMCU.
I'm using the following commands :
Code: Select all
idf.py fullclean
idf.py set-target esp32c3
idf.py menuconfig
Component config > ESP System settings > Channel for console output > UART0
idf.py build flash monitor
The firmware starts correctly, I can see advertising packets with my smartphone.
Then, I change the console output :
Code: Select all
idf.py fullclean
idf.py set-target esp32c3
idf.py menuconfig
Component config > ESP System settings > Channel for console output >
idf.py build flash monitor
The firmware does not start, you can find the debug output attached.
For strapping pins :
I've set GPIO9 to a high level at boot. GPIO8 and GPIO2 are in an unknown state. I'll give another try with GPIO2 at high level (but I think I did this test).
- Attachments
-
- log.txt
- (9.71 KiB) Downloaded 234 times
Re: ESP32C3 custom PCB USB/JTAG boot issue
Hi,
I tested the base "ble_ibeacon" example project found under "examples/bluetooth/bluedroid/ble/ble_ibeacon" without any modifications on an ESP-C3-32S-Kit from AiThinker and I have the same behavior so you can use it instead of the one I uploaded to try to reproduce the issue.
When using UART0 as console output, everything works fine and I can see the advertised iBeacon. Same when console output is set to "None".
When using USB/JTAG as console output, the RTC watchdog reset is fired every ~10 seconds which correspond to the 9000 ms bootloader RTC watchdog configured by default under "Bootloader config -> Timeout for RTC watchdog".
Disabling the bootloader RTC watchdog does not help, because the program is stuck somewhere.
Has anyone tried or successfully reproduced this issue ?
Regards
I tested the base "ble_ibeacon" example project found under "examples/bluetooth/bluedroid/ble/ble_ibeacon" without any modifications on an ESP-C3-32S-Kit from AiThinker and I have the same behavior so you can use it instead of the one I uploaded to try to reproduce the issue.
When using UART0 as console output, everything works fine and I can see the advertised iBeacon. Same when console output is set to "None".
When using USB/JTAG as console output, the RTC watchdog reset is fired every ~10 seconds which correspond to the 9000 ms bootloader RTC watchdog configured by default under "Bootloader config -> Timeout for RTC watchdog".
Disabling the bootloader RTC watchdog does not help, because the program is stuck somewhere.
Has anyone tried or successfully reproduced this issue ?
Regards
Who is online
Users browsing this forum: Majestic-12 [Bot] and 26 guests