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?



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.