Hi,
I have a new board that is the first in a line of products that plan to use the esp32s2. I am having problems getting the board up and running. For several weeks I have been using the Waveshare development board using the pico board footprint. I have been developing code using Eclipse and the 5.0 version of the SDK. I now have my professionally assembled 4 layer boards up and "running". The 3.3v power supply looks clean as a whistle. The 40mHz oscillator comes up fine. JTAG and USB have issues but today I am focusing onloading code in using the UART0 RX and TX. I have verified that my code works by loading into the Waveshare board using UART0. I then try loading the same code from the same eclipse session. When flashing code into the two systems Eclipse IDE console looks identical. However pushing the reset button on the two targets, while monitoring the UART traffic, produces very different results. My s2 board reports a lack of partition table. Then 75mSec later the it reboots "rst:0x3 (RTC_SW_SYS_RST)". It appears that the ULP is resetting the main core. I have used the esptool.py erase_flash command and it reports "Chip erase completed successfully".
I have attached a text file showing the flashing console output and booting reports. I also attached logic analyzer outputs of the boot sequence.
esp32s2 bare board boot problems
-
- Posts: 6
- Joined: Mon Jul 18, 2022 2:31 pm
esp32s2 bare board boot problems
- Attachments
-
- BadFlashAndBoot.txt
- (4.99 KiB) Downloaded 230 times
-
- BadFlashAndBoot_130_mSec_image.JPG (18.14 KiB) Viewed 2951 times
-
- ULP_reset_at_74_mSec.JPG (55.43 KiB) Viewed 2951 times
-
- Posts: 9757
- Joined: Thu Nov 26, 2015 4:08 am
Re: esp32s2 bare board boot problems
Can you share a schematic of your PCB? Can you change the flash speed to something lower than 80MHz, e.g. 20MHz, and see if it works then?
-
- Posts: 6
- Joined: Mon Jul 18, 2022 2:31 pm
Re: esp32s2 bare board boot problems
Thanks for the reply.
I assume you are with Espressif. I am reluctant to share my schematic with the entire community since it
contains proprietary information. I am happy share the schematic with an Espressif application engineer in confidence.
I have not found how to control flash speed. I will keep looking.
Dave
I assume you are with Espressif. I am reluctant to share my schematic with the entire community since it
contains proprietary information. I am happy share the schematic with an Espressif application engineer in confidence.
I have not found how to control flash speed. I will keep looking.
Dave
-
- Posts: 6
- Joined: Mon Jul 18, 2022 2:31 pm
Re: esp32s2 bare board boot problems
Dropping the Flash SPI Speed to 20MHz was not a good thing. But when I dropped it to 40MHz I am able to reliably program the parts. I have the examples/peripherals/adc/single_read working perfectly. I was able to load the examples/peripherals/usb/device/tusb_serial_device project to build and load through the UART0 interface, once but I cannot get it to repeat.
I intend to post more information and questions as I proceed.
Thanks for the tip on Flash SPI Speed.
Dave
I intend to post more information and questions as I proceed.
Thanks for the tip on Flash SPI Speed.
Dave
-
- Posts: 9757
- Joined: Thu Nov 26, 2015 4:08 am
Re: esp32s2 bare board boot problems
Feel free to email me the schematic and I'll see if there's anything obviously wrong: jeroen at espressif period com
-
- Posts: 6
- Joined: Mon Jul 18, 2022 2:31 pm
-
- Posts: 9757
- Joined: Thu Nov 26, 2015 4:08 am
Re: esp32s2 bare board boot problems
Sorry, that ended up in my spam folder, no idea why.
Your issue likely is pin 36, SPID. You have routed this to a mosfet, probably thinking it's part of a general-purpose SPI controller. It's not. It's part of the interface to the (internal, in the chip you chose) flash. See the datasheet, specifically the note on page 14. This makes A. the thing connected to the mosfet not controllable (as you can't control the SPID GPIO without your program crashing) and B. loads this pin down so you can't have high-speed signals there anymore, which makes lowering the flash speed sortta-kinda work.
Note that SPI can be routed via the GPIO matrix, so connecting the mosfet to any (otherwise not used) GPIO instead should fix this and make the mosfet controllable by a SPI peripheral.
Your issue likely is pin 36, SPID. You have routed this to a mosfet, probably thinking it's part of a general-purpose SPI controller. It's not. It's part of the interface to the (internal, in the chip you chose) flash. See the datasheet, specifically the note on page 14. This makes A. the thing connected to the mosfet not controllable (as you can't control the SPID GPIO without your program crashing) and B. loads this pin down so you can't have high-speed signals there anymore, which makes lowering the flash speed sortta-kinda work.
Note that SPI can be routed via the GPIO matrix, so connecting the mosfet to any (otherwise not used) GPIO instead should fix this and make the mosfet controllable by a SPI peripheral.
Who is online
Users browsing this forum: Baidu [Spider], Google [Bot] and 213 guests