This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SPI Read Error

We are interfacing to a SPI Flash MX25R8035F. When attempting to read 1 page of 256 bytes from the chip we break the read command up into 4 SPI Commands.

1) Read the Status Register to verify that a write isn't in progress (write 1 byte, read 1 byte)
2) Write the read command & address (4 bytes)
3) Read out the 1st 255 bytes of data
4) Read out the last byte of data

I verified through logging that that is data length are being sent into spim_xfer

The reads only work every other time. When the read fails, the SPI clock stops running after transmitting the Read Status Command. It doesn't continue to clock in the data.

After the failed read of the status command, the next read of the Flash will succeed.

I have received the same behavior running SDK 3.0.0 and 4.0.2 Is there known issues with reading 1 byte over the SPI interface that leaves the bus in a bad state?

Shown below is scope trace of bad read (only 8 clock cycles) image description

Show below is a scope trace of a good read (16 clock cycles) image description

  • Its the first step that fails right? There is the Errata [58] SPIM: An additional byte is clocked out when RXD.MAXCNT = 1, see this section of the Errata document for more information. However, then you should see two bytes being clocked out everytime, not just every other time.

  • Bjorn, I'll take a closer look at the Errata and the scope traces, but believe I'm seeing the opposite problem that the errata describes. I set TXD.MAXCNT = 0 and RXD.MAXCNT = 1, this completes the read cycles, to clocking out an additional byte shouldn't affect anything. All that happens is I get an additional data byte. Then on the next SPI Transfer I set I set TXD.MAXCNT = 1 and RXD.MAXCNT = 1, and only 1 byte is clocked.

  • Yes, I agree that the issue you're seeing is the opposite, i.e. the second byte is not clocked out. Are you using the SPIM HAL or the SPIM driver(nrf_drv_spi.c with SPIn_USE_EASY_DMA =1 in sdk_config.h)? Would it be possible for you to post the code snippet that causes the issue?

  • Bjorn, I has send code that fails with our SPI flash to you directly. Did you receive it? Any update on this issue?

Related