I started out this week by hooking the SPI RAM to the logic analyzer. Then I hooked up the USB cable and it was stuck in a reboot cycle. I set the flash speed back to 20. Still stuck in reboot cycle. I disconnected the logic analyzer still in reboot loop. I commented out the initSpiRam function in the startup code still stuck in reboot loop. This leads me to believe I have a power supply problem.
If it’s a power problem, adding large (100 μF) and small (0.01 μF) capacitors around the ESP-12E would solve the problem. The 100 μF capacitor will act as an energy reservoir. The small capacitor will act as a noise filter. I piggy backed both a 100 μF and a 0.01 μF capacitor on top of C4 the decoupling capacitor for the ESP-12E module. This didn’t solve the problem. Next I suspected the SPI RAM was the problem.
I probed CS0 along with the SPI RAM CS line and they were in perfect phase. This means that Q6 is not inverting the signal. This results with U2 on the SPI bus while the flash is being accessed. That would definitely get it stuck in a reboot loop. After feeling stumped for a while, I replaced Q6. It booted normally again. I uncommented the initSpiRam function and it started rebooting again. I tried with and without initSpiRam being called and it would consistently reboot when initSpiRam was called.
With initSpiRam uncommented, I went into the function and started commenting out lines to see what was causing the reboot. It appears that ENABLE_SPI_DEV_CS() is causing the reboots. I moved it to after spi_master_init to see if that would work. spi_master_init(HSPI) by itself works. Next I tried adding overlap mode. It appears that overlap has to be after master init. The SPI driver files and headers don’t have any way to read back data while in SPI master mode.
I decided to do a very simple test. I would do a SPI Master Write without overlap mode turned on. One write of one byte immediately after boot so it would be easy to catch on the logic analyzer. The HSPI pins are:
GPIO14: CLK Pin 5
GPIO12: MISO Pin 6
GPIO13: MOSI Pin 7
GPIO15: !CS Pin 16
Chip select is the same pin I am already using, the rest are unconnected. I put a jumper across Q6 to always disable U2 by pulling CS (pin 1) high. I also soldered test points to each pin so I could easily attach the logic analyzer. With the jumper across Q6 I couldn’t even program the board! This doesn’t make sense, I’ll have to come back to that. I think I have some mis-wiring. I removed U2 from the board, and this allowed me to reprogram the PCB.
It now boots but doesn’t give me a menu. It appears to hang on the spi_mast_byte_write() call.
This is not a big deal, I haven’t set the SPI port.
All that time spent fighting this problem, and it turned out to be a solder bridge between R27 and a PCB trace from FLASH CS0. I cleaned up this bridge and it started working reliably.
Finally I tested the basic HSPI write function. It didn’t work. but code is running without freezing or rebooting. So I added a call to spi_master_init() still not working, no data on lines. Looking in spi.c, I saw that spi_master_init() doesn’t assign pins to the HSPI port. I added the lines below to user_init(). HSPI_PIN is defined as 2.
PIN_FUNC_SELECT(PERIPHS_IO_MUX_MTMS_U,HSPI_PIN); // GPIO14
PIN_FUNC_SELECT(PERIPHS_IO_MUX_MTDI_U,HSPI_PIN); // GPIO12
And I saw a byte on the logic analyzer. Yeah! progress.
The data speed is at 20MHz. I tried two writes in a row and got a chip select active for each write, and inactive in between. I need to figure out how to change this behavior, the SPI RAM commands always follow the falling(going active) edge of chip select. To write data to the RAM, I have to send more than one byte while chip select is active.
How do you do troubleshooting? Have you gotten HSPI Working on the ESP-12E? Does anyone know if there are different pinouts for the ESP-12E? Something I saw suggested to me that I still have the SPI RAM connected wrong again.