Skip to main content

Using the SPI Flash

The C0-microSD+ carries 16 MiB of SPI flash. The module boots from it and stores your device application in it, and the space left over is yours to use as non-volatile storage. Data that you write there survives a power cycle.

This page covers using that storage from your device application. For the rules that govern every write to the flash, including the erase behavior that makes flash different from memory, see SPI Flash Write and Erase Semantics.

Reaching the flash from your application​

The flash is memory-mapped, so your device application reads and writes it with ordinary loads and stores. There is no driver to install, and the Hardware Abstraction Layer has no flash API.

Store your data in the user data region, which runs from 0x00200000 to 0x00FFFFFC. The bitstream region below it holds the image that the module boots from, and the module locks that region against writes. Your application cannot lift that lock: the hardware forces the unlock key to 0x00000000 whenever the core is running, so the region is unconditionally locked for as long as your application executes.

Choosing where to store data​

Your device application binary sits at the start of the user data region, at 0x00200000. Nothing in the module protects it, and every write erases a whole 4 KiB sector, so a write placed too close to the binary corrupts it.

Place your data well above the binary. The last megabyte of the user data region, from 0x00F00000, is a safe home for it and leaves the binary room to grow.

warning

An xip build runs directly from the user data region rather than from the LRAM. A device application in an xip build that writes over its own image erases the code that it is executing. Keep every write well clear of the binary.

Reading data back​

The core caches what it reads from the flash. When the contents of the flash change while the core is running, a later read can return the cached value instead of the new one. You see this after a host reflashes the module while the core runs.

Stop the core and start it again after any change to the flash that your running application did not make itself. That returns the core to a known state and discards anything it holds in its cache. See Starting and Stopping the Core.

Surviving power loss​

A flash write that loses power part way through leaves that sector holding neither its old contents nor its new contents. Write your data in a form that you can check, for example by storing a checksum next to it, and keep the previous copy in a different sector until the new copy verifies. If your device application reads back a sector that it cannot validate, fall back to the previous copy rather than trusting a partial write.

Next steps​

Last updated on