Bug in Spi_Write - read buffers accumulate data

Not so much a question as a bug report: after some fun debugging with an oscilloscope, we came across the following bug. (It’s such unintuitive behaviour, I think it deserves bug status.)

Scenario: interacting with an SPI flash chip via the Toradex libraries. The sequence for programming is as follows:

  1. Read device ID, using Spi_ReadWrite
  2. Write enable, using Spi_Write
  3. Program page data, using Spi_Write
  4. Read back the page data, using Spi_ReadWrite.

Spi_ReadWrite is used for commands that involve reading back data, because they all involve writing a command code to the SPI flash first.

Steps 1-3 were working nicely, but at step 4, the data being returned by the library always had a few junk bytes at the beginning of the array. The data being returned by the SPI flash, on the physical SPI bus, was correct.

After replacing the Spi_Write calls in steps 2 and 3 with Spi_ReadWrite, the data returned in step 4 no longer had junk bytes at the beginning. All of which suggests that:

When calling Spi_Write, data is stored in the library’s read buffers. Given the function’s name, this is entirely counter-intuitive, and a really frustrating reason to lose half a day debugging. (I’m guessing that in the library source code, Spi_Write just calls Spi_ReadWrite and doesn’t clear the read buffer afterwards.)

Stuff like this would be so much easier to find if the libraries were open-sourced - is there a good reason not for doing this?

Cheers,

Garry

We will try to reproduce the issue and will update our roadmap accordingly.
It seems that the library does not flush RX FIFO when a write operation is completed.
At the moment probably the only workaround is to use readwrite with a dummy buffer.

Dear @Monomix,

Thank you for reporting the issue. We have created a ticket to discuss and work on this issue. Meanwhile, I guess you got workaround and it is not stopping your development. Let you know our updates on this issue soon or in our roadmap.