esp32s2 bare board boot problems

PianoArcDave
Posts: 6
Joined: Mon Jul 18, 2022 2:31 pm

esp32s2 bare board boot problems

Postby PianoArcDave » Mon Jul 25, 2022 12:34 am

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.
Attachments
BadFlashAndBoot.txt
(4.99 KiB) Downloaded 232 times
BadFlashAndBoot_130_mSec_image.JPG
BadFlashAndBoot_130_mSec_image.JPG (18.14 KiB) Viewed 2972 times
ULP_reset_at_74_mSec.JPG
ULP_reset_at_74_mSec.JPG (55.43 KiB) Viewed 2972 times

ESP_Sprite
Posts: 9757
Joined: Thu Nov 26, 2015 4:08 am

Re: esp32s2 bare board boot problems

Postby ESP_Sprite » Mon Jul 25, 2022 4:20 am

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?

PianoArcDave
Posts: 6
Joined: Mon Jul 18, 2022 2:31 pm

Re: esp32s2 bare board boot problems

Postby PianoArcDave » Mon Jul 25, 2022 3:30 pm

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

PianoArcDave
Posts: 6
Joined: Mon Jul 18, 2022 2:31 pm

Re: esp32s2 bare board boot problems

Postby PianoArcDave » Mon Jul 25, 2022 11:58 pm

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

ESP_Sprite
Posts: 9757
Joined: Thu Nov 26, 2015 4:08 am

Re: esp32s2 bare board boot problems

Postby ESP_Sprite » Tue Jul 26, 2022 3:02 am

Feel free to email me the schematic and I'll see if there's anything obviously wrong: jeroen at espressif period com

PianoArcDave
Posts: 6
Joined: Mon Jul 18, 2022 2:31 pm

Re: esp32s2 bare board boot problems

Postby PianoArcDave » Thu Jul 28, 2022 6:24 pm

Hi,
the other day emailed a copy of my schematic to jeroen@espressif.com. Did yo receive it?
Dave

ESP_Sprite
Posts: 9757
Joined: Thu Nov 26, 2015 4:08 am

Re: esp32s2 bare board boot problems

Postby ESP_Sprite » Fri Jul 29, 2022 2:09 am

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.

Who is online

Users browsing this forum: MicroController and 64 guests