What Happens if an Interrupt Occurs while Sending the Read Command Sequence to SPI Flash? - KBA203731

Version 4

    Version: *A


    Translation - Japanese: 読み出しコマンドシーケンスをSPI Flashへ発行中に割り込みが発生すると、どうなりますか? - KBA203731 - Community Translated (JA)



    What happens if an interrupt occurs while sending the READ command sequence to the SPI FLASH?



    The answer depends upon how SPI signals are managed when the interrupt happens.


    For reference, here is the read signaling for the Quad-IO read copied from the S27FL127S datasheet:

    Case 1: Chip enable, CS#, is released


    If the interrupt causes the host to stop driving the CS# signal low, the pull-up on CS# will take the CS# signal high. This changes the flash state from Active Power Mode to Standby Power Mode, at which point the read transaction is terminated and the Flash loses any context regarding prior steps of the read command sequence. The recovery after servicing the interrupt is to restart the read command.


    Case 2: All SPI signals are maintained at stable digital states


    This means CS# is low, IOs are stable, and clock is stable (no longer clocking), and HOLD# (if available) is not active. In this case, the flash remains in Active Power Mode waiting for clocking to resume. The recovery after servicing the interrupt is to resume clocking; or to release CS# and restart the read command.


    Case 3: The SPI memory controller automatically continues managing the read


    Many SPI controllers will keep processing the read transaction. In this case, the read command is not interrupted, and no recovery is required.


    For Cases #1 and #2, the best recovery after interrupted read is to release CS# and restart the read command. For software-controlled reading, it may make sense to disable interrupts during the flash reading activity, releasing to the interrupt once the read logic reaches a convenient stopping point.