Weird SPI read behaviour

Development Boards Artemis
13

I have not seen read issues because I have only used SPI so far as a write-only mechanism to update LCD displays. But the SPI unit seems to work fine for gazillions of writes in a row.

From your description, it is not clear that your instability issue is related to the original MOSI issue. But just in case, it might be an interesting experiment to ‘manually’ drive MOSI to ‘1’ during your SPI read operations. By that, I mean putting a wrapper around your SPI read call so that it:

  • - Reassigns the MOSI pad function setting from the IOM/MOSI function back to a GPIO function

  • - Drives the GPIO pad corresponding to MOSI to '1'
  • - Performs the IOM SPI read operation where MOSI is now known to be '1' for the whole duration
  • - Reassigns the MOSI pad function back to the IOM

    • This should work as long as your SPI read does not call the SPI pin configuration mechanism on each read or write call.

    Other things I would check would be the electrical environment of your SPI signals. Are there any long wires, or do your SPI signals running beside other noisy PCB traces? If you are trying to run the SPI interface really fast, a false clock event can have completely devastating results. If you run the SPI clock slower, do things get better? Of course, one would think that after a false clock, the SPI unit could be recovered by reinitializing the IOM.

    One last thing: once the system is in this weird state, can you power cycle just the IOM in question by turning it off via the DEVPWREN register, then on again, and then reinitialize it?