SPI library failing to load on ESP32-WROOM-32E chip

#1

Hi all,

I’ve run in to a problem when using a custom board I’ve created where I don’t see the problem with the mass produced esp32-dev boards, while effectively running the same build.

Basically I’m not even sure what the problem is, after setting the debug level to 3 this is all I’m getting:

[Feb 23 20:49:41.047] mgos_sys_config.c:368   MAC: c4:dd:57:8d:27:f0
[Feb 23 20:49:41.047] mgos_sys_config.c:376   WDT: 30 seconds
[Feb 23 20:49:41.047] mgos_core.c:104         Setting TZ to 'XXXXXXXXXXXXXXXX'
[Feb 23 20:49:41.047] mgos_deps_init.c:172    Init adc 1.0.0...
[Feb 23 20:49:41.047] mgos_deps_init.c:172    Init spi 1.0...
[Feb 23 20:49:41.047] ets Jul 29 2019 12:21:46
[Feb 23 20:49:41.047] 
[Feb 23 20:49:41.047] rst:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)

Basically the device just goes in to a boot loop always dying at the same point mgos_deps_init.c:172 Init spi 1.0...

I can run the basic esp32 project and it all works as expected on the board. I can flash and run Arduino code and it runs fine, but the project I’ve been working on for a while seems to be causing issues.
When I flash the FW to the non-custom devices the next message I see on the terminal after

[Feb 23 21:01:44.486] esp32_spi_master.c:94   SPI3 init ok (MISO: 19, MOSI: 23, SCLK: 18; CS0/1/2: 5/27/-1; native? yes)

Any thoughts on how I can debug/troubleshoot would be much appreciated.
Thanks.

#2

It’s going slow, but I’ve removed as much functionality as I could from my project and and slowly adding back till I find the error. It’s at least running now which is good (but painful)

If anyone has a suggestion on how I could potentially speed this up I’d really appreciate it.

#3

I suggest you change your subject so something more closely describing your problem.
You have a board that uses an ESP32 processor, I guess, a chip, not a module…
You connected an SPI flash to the processor… and …
Looks like some firmwaret runs on your board, but other refuses to boot…
Stupid questions, but I have to ask them:
Is your flash large enough ?
Does your code use some functionality on those “mass produced esp32-dev” boards that you perhaps do not have on yours ?

#4

Thanks for the suggestions @scaprile.

In breaking down the program I’ve identified that it’s the SPI library load that breaks.
I can basically load everything other than the SPI lib, and when I do I see the behaviour I mentioned above.

I’m in the process of building another dev board with minimum components to see if the hardware could potentially be causing the issue

#5

So strange, my newly built dev boards seems to be working as expected. The SPI library step is not failing and the board is booting as expected…

I’d like to understand what might have caused this, is there any chance a short somewhere on the SPI pins could have lead to this error?

#6

Well, if you connect an oscilloscope and observe the signals, you’ll see if the SPI is working OK or some excess capacitance due to incorrect track routing or incorrect circuit design, or excess inductance due to incorrect track width and routing, or if assembly issues are shorting or excessively loading your signals or causing them to be out of specs for the intended chips. Google for signal integrity