Skip to content

Add SafeBoot recovery handling for Spansion/Cypress OSPI NOR flash de…#35

Open
cristisalcie wants to merge 1 commit into
TexasInstruments:nextfrom
cristisalcie:safeboot_implementation
Open

Add SafeBoot recovery handling for Spansion/Cypress OSPI NOR flash de…#35
cristisalcie wants to merge 1 commit into
TexasInstruments:nextfrom
cristisalcie:safeboot_implementation

Conversation

@cristisalcie
Copy link
Copy Markdown

Summary

Add SafeBoot recovery handling for Spansion/Cypress OSPI NOR flash devices when interrupted non-volatile register writes leave the flash in a corrupted state.

Problem

If a hardware reset occurs while a non-volatile register write operation is still in progress, the flash device may enter a corrupted or SafeBoot state.

This can happen, for example, when:

  • a CFR register write is issued
  • the internal non-volatile write operation has not completed yet
  • a hardware reset or power interruption occurs before the device becomes ready

In this state:

  • SPI JEDEC ID reads may fail
  • status register contents may become invalid
  • normal flash initialization may fail

Solution

Add SafeBoot detection and recovery handling during Flash_norOspiOpen().

The implementation introduces:

  • Flash_corrupted()
  • Flash_recover()
  • Flash_setDefaultCfr4x()

Recovery Flow

  1. Probe flash state during initialization

    • Verify JEDEC ID read succeeds
    • Verify Status Register 1 returns expected default value (0x00)
  2. If corruption is detected:

    • Issue flash software reset
    • Poll until the device becomes responsive again
  3. After protocol initialization:

    • Restore default CFR4N/CFR4V values (0xA8) if required

Details

Flash_corrupted()

Detects SafeBoot/corrupted state using:

  • JEDEC ID read validation
  • raw status register read validation

Flash_recover()

Performs:

  • flash software reset
  • polling until reset completion using repeated ReadId() attempts

Flash_setDefaultCfr4x()

Restores default CFR4 values after recovery.

This is required because software reset recovery does not restore CFR4 to datasheet default values.

Motivation

The implementation follows the SafeBoot behavior described in the flash device documentation and improves driver robustness against:

  • unexpected resets
  • brownouts
  • watchdog resets
  • reset during non-volatile configuration updates

Without recovery handling, the flash may remain inaccessible until manually reconfigured or power-cycled.

Tested

Tested by intentionally interrupting non-volatile register writes using hardware reset before flash ready completion.

Verified:

  • corrupted state detection
  • successful recovery after reset
  • restoration of normal flash communication
  • successful protocol reconfiguration after recovery

…vices when interrupted non-volatile register writes leave the flash in a corrupted state.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant