Understanding HSPI Firmware V00H

What I wasn’t understanding last week is the definition of HSPI_CS.  It is the same as CS0 in the HSPI module.  So when I turn on overlap mode, of course, it maps to SPI_CS0.  That leaves me with setting the HSPI to use CS1(GPIO1/U0TXD) or CS2(GPIO0).  Since I use U0TXD for reprogramming the module, CS1 is unavailable.

I cut the trace going to U2 CS0 and added a jumper wire to GPIO0.  I then changed the code to use CS2 to enable the RAM.  This included setting the HSPI to use CS2 and setting GPIO0 MUX to be SPICS2.  And I got what looks like a successful write to the SPI RAM.

Successful SPI Write

The byte command (2) followed by 24bit address (0) followed by the data.  The first four bytes of data are “lleH”.  This is backwards to what I was planning, I can change it by setting a bit or changing the bytes I put into the registers. As long as I read them back the same way, it really doesn’t matter as long as I read and write aligned to 4 byte words.  The data is one byte short, I had a typo sending only 11 bytes of data.

Note: When data is aligned to 4 bytes, it means you need to read or write only on increments of 4 bytes.  So you would only Write or Read to/from addresses that in hexadecimal end in 0, 4, 8, or C. Since this chip is a 32 bit processor, this is required often.

I then decided to implement the hard coded read command.  I copied the write code, changed the command from 2 to to 3, set the HSPI to read back  and zeroed out the working registers so that I can see if they have been filled with the data I stored in the RAM. Then I commented out the writeRam() call in user_init and added readRam() in it’s place. Doing this without powering down, I should get the data back without having to write it again. I forgot to switch the length to the receive length register; I fixed this then I got back all zeros for the data.

Unsuccessful SPI read

I see the command (3) followed by the address (0) followed by 12 Bytes of data(0). So I have more debugging to do.  My first guess is the WP or HOLD lines of the chip are not doing what I need them to do.

I have gotten a better understanding of the SPI hardware on the ESP8266.  It looks to me that I can get the same control by just using the main SPI channel to control my RAM chip.  This needs testing.  I will need to save any registers I change and restore them when I am done accessing the RAM.  This will also have to be done from code that runs from internal RAM.

I have put the current state of the code on GitHub.  Use the link under the search box on the right side of this page.

Have you used chips with similar SPI configuration?  I like that I can have any bit length of data on the SPI bus, this will be useful for JTAG data. Have you worked directly with JTAG data?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.