ESP32-S3-WROOM-1 On Custom PCB

[darkgiuseppe]

Hello. I have been using the ESP32-S3-DEVKITC fora bit now and it works great on either USB port (serial or native). I went ahead and decided to move to a custom PCB proto. Though the flash monitor process does not appear to be the same. Usually I am able to see the log messages right away after flashing but instead I get a different kind of output. When I press ctrl + ] to leave, my ESP32-S3 doesn't behave as it should (like to run the program). Am I missing something in the flash process now that I have moved to my own PCB? I have my schematic attached as well for reference.

Code: Select all

PS C:\BBG_Firmware\Antagonist_V2> idf.py flash monitor
Executing action: flash
Serial port COM4
Connecting.......................
COM4 failed to connect: Failed to connect to Espressif device: No serial data received.
For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html
Serial port COM3
Connecting...
COM3 failed to connect: Write timeout
Serial port COM17
COM17 failed to connect: could not open port 'COM17': OSError(22, 'The semaphore timeout period has expired.', None, 121)
Serial port COM16
Connecting...
COM16 failed to connect: Write timeout
Serial port COM10
Connecting...
Detecting chip type... ESP32-S3
Running ninja in directory c:\bbg_firmware\antagonist_v2\build
Executing "ninja flash"...
[1/5] cmd.exe /C "cd /D C:\BBG_Firmware\Antagonist_V2\build\esp-idf\esptool_py && c:\esp\tools\Espressif\python_env\i...are/Antagonist_V2/build/partition_table/partition-table.bin C:/BBG_Firmware/Antagonist_V2/build/antagonist_esp32.bin"antagonist_esp32.bin binary size 0x6af40 bytes. Smallest app partition is 0x100000 bytes. 0x950c0 bytes (58%) free.
[2/5] Performing build step for 'bootloader'
[1/1] cmd.exe /C "cd /D C:\BBG_Firmware\Antagonist_V2\build\bootloader\esp-idf\esptool_py && c:\esp\tools\Espressif\python_env\idf4.4_py3.8_env\Scripts\python.exe C:/esp/esp-idf/components/partition_table/check_sizes.py --offset 0x8000 bootloader 0x0 C:/BBG_Firmware/Antagonist_V2/build/bootloader/bootloader.bin"
Bootloader binary size 0x51a0 bytes. 0x2e60 bytes (36%) free.
[2/3] cmd.exe /C "cd /D C:\esp\esp-idf\components\esptool_py && C:\esp\tools\Espressif\tools\cmake\3.20.3\bin\cmake.e...ORKING_DIRECTORY="C:/BBG_Firmware/Antagonist_V2/build" -P C:/esp/esp-idf/components/esptool_py/run_serial_tool.cmake"esptool.py esp32s3 -p COM10 -b 460800 --before=default_reset --after=hard_reset write_flash --flash_mode dio --flash_freq 80m --flash_size 2MB 0x0 bootloader/bootloader.bin 0x10000 antagonist_esp32.bin 0x8000 partition_table/partition-table.bin
esptool.py v3.3-dev
Serial port COM10
Connecting...
Chip is ESP32-S3
Features: WiFi, BLE
Crystal is 40MHz
MAC: 7c:df:a1:e3:76:3c
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Flash will be erased from 0x00000000 to 0x00005fff...
Flash will be erased from 0x00010000 to 0x0007afff...
Flash will be erased from 0x00008000 to 0x00008fff...
Compressed 20896 bytes to 13036...
Writing at 0x00000000... (100 %)
Wrote 20896 bytes (13036 compressed) at 0x00000000 in 0.4 seconds (effective 379.9 kbit/s)...
Hash of data verified.
Compressed 438080 bytes to 260916...
Writing at 0x00010000... (6 %)
Writing at 0x0001b227... (12 %)
Writing at 0x0002369a... (18 %)
Writing at 0x00029329... (25 %)
Writing at 0x0002f2d3... (31 %)
Writing at 0x0003504d... (37 %)
Writing at 0x0003a957... (43 %)
Writing at 0x00040050... (50 %)
Writing at 0x00046328... (56 %)
Writing at 0x0004c18a... (62 %)
Writing at 0x000525c3... (68 %)
Writing at 0x00057dd1... (75 %)
Writing at 0x00060565... (81 %)
Writing at 0x00068cf2... (87 %)
Writing at 0x0006f53e... (93 %)
Writing at 0x00074f4e... (100 %)
Wrote 438080 bytes (260916 compressed) at 0x00010000 in 4.8 seconds (effective 736.4 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 103...
Writing at 0x00008000... (100 %)
Wrote 3072 bytes (103 compressed) at 0x00008000 in 0.1 seconds (effective 370.0 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...
Executing action: monitor
Serial port COM4
COM4 failed to connect: could not open port 'COM4': PermissionError(13, 'Access is denied.', None, 5)
Serial port COM3
COM3 failed to connect: could not open port 'COM3': PermissionError(13, 'Access is denied.', None, 5)
Serial port COM17
COM17 failed to connect: could not open port 'COM17': OSError(22, 'The semaphore timeout period has expired.', None, 121)
Serial port COM16
COM16 failed to connect: could not open port 'COM16': PermissionError(13, 'Access is denied.', None, 5)
Serial port COM10
Connecting...
Detecting chip type... ESP32-S3
Running idf_monitor in directory c:\bbg_firmware\antagonist_v2
Executing "c:\esp\tools\Espressif\python_env\idf4.4_py3.8_env\Scripts\python.exe c:\esp\esp-idf\tools/idf_monitor.py -p COM10 -b 115200 --toolchain-prefix xtensa-esp32s3-elf- --target esp32s3 c:\bbg_firmware\antagonist_v2\build\antagonist_esp32.elf -m 'c:\esp\tools\Espressif\python_env\idf4.4_py3.8_env\Scripts\python.exe' 'c:\esp\esp-idf\tools\idf.py'"...
--- WARNING: GDB cannot open serial ports accessed as COMx
--- Using \\.\COM10 instead...
--- idf_monitor on \\.\COM10 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x15 (USB_UART_CHIP_RESET),boot:0x0 (DOWNLOAD(USB/UART0))
Saved PC:0x400490cc
waiting for download

Done

[ESP_Sprite]

First of all, you don't need or want R14; the ESP32S3 already has that resistor built in. Secondly, did you reset the chip with GPIO0 low? If so, the USB peripheral can't get you out of that state; you'll need to reset the chip with GPIO0 high.

[darkgiuseppe]

First of all, you don't need or want R14; the ESP32S3 already has that resistor built in. Secondly, did you reset the chip with GPIO0 low? If so, the USB peripheral can't get you out of that state; you'll need to reset the chip with GPIO0 high.

I should have labeled R14 as "NOT POPULATED". That was placed there in case I ad just to adjust the pullup value for some reason. It is unpopulated on my board.

I reconstructed Figure 7 (page 25) on the module's datasheet. I left pullup to pulldown options for myself via solderable jumpers. My intention was to keep them unsoldered and see how to it went with just using SW2 on my board (pushbutton to ground).

To answer your question, yes it appears I did reset with GPIO0 low! There was a solder jumper that was accidently soldered after I reflowed it. I am going to fix it and try again tonight.

But to make sure I understand the flashing process, I should not hold the GPIO0 pin low? And then when I get to this part...

Code: Select all

rst:0x15 (USB_UART_CHIP_RESET),boot:0x0 (DOWNLOAD(USB/UART0))
Saved PC:0x400490cc
waiting for download

... since it was strapped as high it will act like the devkit? Section 3.3 on the datasheet indicates that if GPIO0 is not connected, it straps its value as a "1" due to the pullup resistor. Is my interpretation correct?

Anyway, like I said, I will try again tonight.

Thank you for replying to my post!

[ESP_Sprite]

In normal situations, the USB-serial-JTAG adapter should be able to take you from a running program back into download mode and back to a running program all on its own. There's a few situations where it cannot (for instance, if your software accidentally reconfigures the pins used for USB) and in those cases you may need to force download mode using GPIO0.

And yes, if you leave GPIO0 floating, you should get the devkit behaviour.

[darkgiuseppe]

In normal situations, the USB-serial-JTAG adapter should be able to take you from a running program back into download mode and back to a running program all on its own. There's a few situations where it cannot (for instance, if your software accidentally reconfigures the pins used for USB) and in those cases you may need to force download mode using GPIO0.

And yes, if you leave GPIO0 floating, you should get the devkit behaviour.

Okay great! I have left GPIO0 floating and it worked great on the first try. However, it does still get stuck on the "waiting for download". But with a quick flick of the reset button, the main app starts great. But when I try to flash again, it doesn't wanna take. After some fiddling, I actually need to quickly hold both reset and boot0, let go of reset, issue flash-monitor command, and then it will take. I see the value of that auto program circuit now in the devkitC. I noticed that it interfaces with the USB-UART bridge. Is there a similar auto-program circuit for when one uses the USB-serial-JTAG adapter port? Or is it the same? And if its the same, not sure where RTS and DTR go. Been a while since digital electronics class but the auto program circuits looks like an SR latch?

[ESP_Sprite]

You should not need a DTR/RTS/whatever circuit with the internal USB-JTAG-serial adapter. However, I think C8 in this case is the culprit: on bootup the cap is empty and will pull down GPIO0 to ground, meaning the chip will start in download mode. Remove that cap and you'll probably have normal behaviour. In case you still want the functionality the cap offers, instead connect it between GPIO0 and +3.3V.

[darkgiuseppe]

You should not need a DTR/RTS/whatever circuit with the internal USB-JTAG-serial adapter. However, I think C8 in this case is the culprit: on bootup the cap is empty and will pull down GPIO0 to ground, meaning the chip will start in download mode. Remove that cap and you'll probably have normal behaviour. In case you still want the functionality the cap offers, instead connect it between GPIO0 and +3.3V.

I did try that but it is the same behavior. Not sure why GPIO0 would be pulled to ground if there is an internal pullup for GPIO0. Nevertheless, I have a working custom PCB with the ESP32-S3 now and a working method (albeit wacky) to flash new code on the chip. Will just push me to get the BLE OTA working soon.

Thanks again for your replies! Hopefully things are getting better on your end as far as COVID lock downs go.

[rpiloverbd]

Along with what everyone has suggested above, I'd like to make a suggestion. For your customized ESP32 based projects, you can consider flex PCB. Flexible boards can be bent into any shape. Flexible circuits are made up of a thin insulating polymer film glued to a substrate with a pattern of conductive traces. Here you can get some idea regarding the types and advantages of Flex PCB:https://pcbtracks.com/introduction-to-f ... uit-board/

[ESP_Sprite]

Along with what everyone has suggested above, I'd like to make a suggestion. For your customized ESP32 based projects, you can consider flex PCB.

That is quite offtopic and also not really a good suggestion, as flex PCBs have all sorts of issues like needing reinforcement under larger components (like an ESP32) to stop flexing to cause loads on the solder joints, and flex-rigid PCBs still are pretty expensive.

[Ukaton]

I also developed a custom PCB with an ESP32-S3 module and manufactured it through JLCPCB and I'm getting the same error message of

"A fatal error occurred: Failed to connect to ESP32-S3: Wrong boot mode detected (0xb)! The chip needs to be in download mode."

The only thing I didn't take into consideration is that I didn't add a BOOT button connected to GPIO0 (it's currently not connected) and only have a RESET button connected to the EN pin on the ESP32. What are some things I can do to workaround this issue?