This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
TM4C team,
A customer is trying to access the SPI flash and having problems completing an erase. The SPI flash is 26F032B.
They tried operating in Mode 0, and weren't able to read or write.
They tried Mode 3, and they're able to read successfully. But they can't complete a sector or chip erase.
Do we have any example software for reading and writing this type of SPI flash?
Do you have any suggestions about what could be going wrong with the erase functions?
Thanks,
Darren
HI Darren,
TivaWare provides utilities to interface with SPI flash. Go to section 19 in C:\ti\TivaWare_C_Series-2.2.0.295\docs\SW-TM4C-UTILS-UG-2.2.0.295.pdf for details. There is a small example in section 19.3.
26F032B requires you meet the timings as shown below for either sector or block erase. The CE# must be low throughout the transaction. TM4C123 cannot hold CS# low between bytes. Therefore, I assume customer uses GPIO to control the CE#. If not, I suspect that is the reason for erase not working. Have the customer capture the signals in logic analyzer against the required timing is the best way to debug the issue. Also check if the flash is in any way write-protected.
Please be aware that due to holidays, response will be delayed. Thanks.
Charles,
I do have a logic analyzer on the system and what is missing is for the CE# to go back high between different transactions.
For example, before I do the Block Erase, I send the Write Enable command then the Block is immediately sent after that. When I execute commands like this the CE# is low during the all of the transactions. Since commands like read and write are non-blocking knowing when to set CE# high again would be next to impossible using GPIO.
I have attempted to use a short delay between commands and that helped to get CE# high, but again this is still a problem for the reads and writes.
Do you have any suggestions?
Paul
Hi Paul,
I'm sorry that I'm currently out of office and will come back to answer questions on 1/4/2022.
> Since commands like read and write are non-blocking knowing when to set CE# high again would be next to impossible using GPIO.
I think you're looking for the function SSIBusy():
Busy=0 means that the (Tx) FIFO has emptied. If the FIFO contained the last fragment of your SPI transaction, you can de-assert CE#.
[Edit: I forgot to include the question I was responding to. As Charles suggested above, using a GPIO is preferable to trying to get Fss to do what you want.]