{"id":3891,"date":"2018-04-27T14:16:38","date_gmt":"2018-04-27T21:16:38","guid":{"rendered":"https:\/\/visualgdb.com\/w\/?p=3891"},"modified":"2018-04-27T14:16:38","modified_gmt":"2018-04-27T21:16:38","slug":"troubleshooting-esp8266-flash-connection-issues","status":"publish","type":"post","link":"https:\/\/visualgdb.com\/tutorials\/esp8266\/spiflash\/","title":{"rendered":"Troubleshooting ESP8266 FLASH connection issues"},"content":{"rendered":"

This tutorial\u00a0demonstrates how to\u00a0understand\u00a0the interaction between the ESP8266 chip and the on-board SPI FLASH. We will create a basic “Blinking LED” application stored in the SPI FLASH and will then use\u00a0the Cypress\u00a0SuperSpeed Explorer kit with\u00a0Analyzer2Go<\/a>\u00a0to capture a high-speed trace of\u00a0the SPI FLASH signals, will explain how different commands in different modes are sent and how to diagnose\u00a0FLASH-related problems by checking the responses to\u00a0the\u00a0key\u00a0commands.<\/p>\n

    \n
  1. Start Visual Studio and open the VisualGDB Embedded Project Wizard:
    \n<\/a>     \"01-prjname\"<\/a><\/li>\n
  2. Proceed with\u00a0the default choice of creating a new project:
    \n    \"02-emb\"<\/a><\/li>\n
  3. <\/li>\n
  4. Select the ESP8266 toolchain and\u00a0proceed with the default ESP8266 device settings:\"03-device\"<\/a><\/li>\n
  5. Pick the default LEDBlink (IoT) sample and press “next”:\"04-sample\"<\/li>\n
  6. Connect your JTAG probe\u00a0via USB and pick in on the Debug Method page:
    \n<\/a>     \"05-debug\"<\/a><\/li>\n
  7. Finally press “Finish” to create the project and build it by pressing Ctrl-Shift-B:\"06-build\"Then press F5 to program the FLASH memory and begin debugging\u00a0your firmware. The rest of the tutorial will show how various FLASH-related signals look like\u00a0when the ESP8266 chip is accessing the FLASH memory in different modes. If your program does not\u00a0run properly,\u00a0compare the commands and responses captured from your board with the ones shown\u00a0in this tutorial in order to pinpoint the cause.<\/li>\n
  8. In order to see the interaction between the ESP8266 chip and the SPI FLASH, you will need to\u00a0capture the following signals:
    \n\n\n\n\n\n\n\n\n\n\n
    Signal<\/td>\nName<\/td>\nPin on the\u00a0Olimex\u00a0MOD-WIFI-ESP8266-DEV<\/a> board<\/td>\n<\/tr>\n
    Clock<\/td>\nSD_CLK<\/td>\n5<\/td>\n<\/tr>\n
    Chip select<\/td>\nSD_CMD<\/td>\n8<\/td>\n<\/tr>\n
    QSPI data pin #0 \/ SPI MOSI<\/td>\nSD_DATA_0<\/td>\n9<\/td>\n<\/tr>\n
    QSPI data pin #1 \/ SPI MISO<\/td>\nSD_DATA1<\/td>\n7<\/td>\n<\/tr>\n
    QSPI data pin #2<\/td>\nSD_DATA2<\/td>\n6<\/td>\n<\/tr>\n
    QSPI data pin #3<\/td>\nSD_DATA3<\/td>\n10<\/td>\n<\/tr>\n
    UART\/LED output<\/td>\nGPIO5<\/td>\n11<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    Connect them to the logic analyzer board (don’t forget\u00a0to connect GND), then start Analyzer2Go and select the SuperSpeed Explorer Kit board:\"03-explorer\"<\/a>Warning! As the SPI FLASH uses\u00a0relatively high frequencies, ensure that the wires connecting your logic analyzer to the ESP8266 board are as short as possible to\u00a0avoid cross-talk.<\/strong><\/li>\n

  9. Press OK and\u00a0enable\u00a0capturing of the signals.\u00a0If the firmware is running successfully, you will see short bursts of activity. During active FLASH commands the SD_CMD (nCS) pin will go low, the SD_CLK pin will start transmitting clock and the IO0-IO3 pins will be used to transfer the data:\"07-led\"<\/a><\/li>\n
  10. Now we will record the entire startup sequence of the ESP8266 chip and will analyze\u00a0different phases of it.\u00a0Connect the\u00a0Reset pin on your board to\u00a0GND and\u00a0press the “Record” button in Analyzer2Go. Then release the reset pin. You will see a large burst of FLASH activity followed by shorter bursts (as the LEDBlink program is very basic, most\u00a0of the code\u00a0will get quickly cached internally and the SPI\u00a0FLASH\u00a0interaction will be minimal):\"08-record\"<\/a><\/li>\n
  11. Stop recording and zoom into the first burst of SPI activity:\"09-zoom\"<\/a><\/li>\n
  12. If you zoom to the first data burst, you will see that the first\u00a0SPI FLASH commands sent by the ESP8266 are using a lower 13 MHz clock, even if a higher clock rate was configured in the project properties. As the ESP8266 chip doesn’t know the FLASH type\/speed at this point yet, it uses the most basic setting:
    \n    \"10-mhz\"<\/a><\/li>\n
  13. Switch to the Protocol Analyzers tab and add the SPI analyzer. See how the first command consists of the 0xAB command byte followed by 4 zeroes and the reply from the SPI FLASH module is 0x14:\"11-release\"<\/a><\/li>\n
  14. You can\u00a0find the command bytes for all commands in the QSPI FLASH datasheet<\/a>. The 0xAB command\u00a0releases the device from the power down mode and the device responds with\u00a0its ID byte (0x14):\"12-datasheet\"<\/a>Note that this command is sent using the\u00a0regular SPI protocol that uses just 1 pin per direction.\u00a0Most of the subsequent commands are the ESP8266 querying the status register of the FLASH module to see when it becomes ready.<\/li>\n
  15. If you zoom out of the\u00a0first data burst, you will see that the QSPI pins (IO2-IO3) stay inactive during the first group of commands and\u00a0become active later. Zoom in to that part of the capture:\"13-ios\"<\/a><\/li>\n
  16. The first\u00a0command that utilizes all 4 QSPI pins is 0xEB (read data over QSPI):
    \n    \"14-read\"<\/a><\/li>\n
  17. To interpret it, add a QSPI\u00a0protocol analyzer to the Protocol Analyzers pane.\u00a0Note that the\u00a0command byte (0xEB) is transferred via the regular SPI protocol (and hence the QSPI data makes no sense for it), while the rest of the command uses the QSPI pins (hence the regular SPI data makes no sense):\"15-addr\"<\/a><\/li>\n
  18. In this example the ESP8266 reads data at address 0x00000010 and the QSPI FLASH returns the following bytes: 01 00 00 00 FF FF FF FF 01 01 01 01 01 00:\"16-data\"<\/a><\/li>\n
  19. Compare the bytes returned by the QSPI FLASH with the actual FLASH contents (either the .bin<\/strong> file of your project, or the\u00a0FLASH snapshot\u00a0created via the ESP8266 bootloader):
    \n    \"17-refdata\"<\/a><\/li>\n
  20. You can use the “Show all output as text”\u00a0checkbox to display all capture QSPI data in a separate pane in Analyzer2Go and search for specific patterns (e.g. read addresses):\"18-fastread\"<\/a>If the data received from\u00a0the SPI FLASH doesn’t match the expected values, check that none of the SPI pins is stuck at a fixed value (0 or 1). If this is the case, double-check the connection between the ESP8266\u00a0and the SPI FLASH.<\/li>\n
  21. Now we will show how the FLASH reading commands change if you switch from QSPI to DSPI. Open VisualGDB Project Properties and switch QIO to DIO:
    \n    \"19-dio\"<\/a><\/li>\n
  22. Start\u00a0recording with Analyzer2Go and\u00a0run the\u00a0firmware again. See how instead of 0xEB command, ESP8266 is now using the 0xBB command (read data via DSPI) and how the IO2 and IO3 pins are now unused:
    \n    \"20-diodata\"<\/a><\/li>\n
  23. Using DSPI instead of QSPI reduces the amount of used pins, but increases the time required to read each data chunk. You can see this by comparing the burst times in Analyzer2Go:\"21-dioslower\"<\/a>You can also\u00a0try experimenting with different cache settings and see how this affects the SPI FLASH reading patterns, so you can\u00a0choose the right trade-off between performance and extra memory.<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"

    This tutorial\u00a0demonstrates how to\u00a0understand\u00a0the interaction between the ESP8266 chip and the on-board SPI FLASH. We will create a basic “Blinking<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[142],"tags":[161,100,162],"_links":{"self":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts\/3891"}],"collection":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/comments?post=3891"}],"version-history":[{"count":1,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts\/3891\/revisions"}],"predecessor-version":[{"id":3914,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts\/3891\/revisions\/3914"}],"wp:attachment":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/media?parent=3891"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/categories?post=3891"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/tags?post=3891"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}