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:
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
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.
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 ?
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
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