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:
- Read device ID, using
Spi_ReadWrite - Write enable, using
Spi_Write - Program page data, using
Spi_Write - 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