August 4th, 2024

Romram: Using QSPI RAM with RP2040's SSI in read-write mode

The article explores challenges of using external QSPI RAM with the RP2040 microcontroller, proposing a method to emulate write operations via a HardFault handler, achieving effective RAM utilization despite limitations.

Read original articleLink Icon
Romram: Using QSPI RAM with RP2040's SSI in read-write mode

The article discusses the challenges and solutions for using external QSPI RAM with the RP2040 microcontroller, particularly focusing on achieving read-write capabilities. The RP2040's XIP mode allows for read and execute operations but not writes, which limits the utility of external RAM. The author proposes a method to boot from flash memory, load it into RAM, and then run from RAM, utilizing simple logic gates to manage memory access. However, the inability to write directly to the RAM presents a significant hurdle.

To address this, the author suggests using a HardFault handler to emulate write operations. By leveraging the microcontroller's MPU, the handler can intercept write attempts, emulate them, and flush the cache as needed. This approach allows for the execution of unmodified software that requires RAM. The article also highlights potential pitfalls, such as the need to manage stack pointers and the timing of write operations to avoid conflicts with the XIP cache.

The performance of this setup is discussed, noting that read and execute operations are at native speed, while write speeds depend on the emulation method used. The author reports achieving a write speed of 36Mbit/s for memory copy operations, indicating that while there are complexities, the solution can be effective for applications requiring additional RAM on the RP2040. Overall, the article provides insights into the innovative use of hardware features to overcome limitations in microcontroller memory management.

Link Icon 4 comments
By @mrlambchop - 6 months
I recently worked on a product (Realtek 200MHz MCU + integraiton wifi/ble) that had a similar setup - QSPI connected PSRAM and QSPI connected Flash (with read/write).

The PSRAM had a reasonable size page cache in the chip that made this memory quite responsive from a CPU perspective - a few rare cache flushes were needed, but things like DMA and bus masters (onboard radios etc..) were completely coherent and it made development much easier to manage.

My takeaway was that PSRAM was surprisingly capable (with the right can of hardware controller in place). Kudos to Realtek for getting the hardware to work without a thousand impossible to debug CPU lock ups...

By @nxobject - 6 months
SSI is a very useful (and underdocumented!) RPi feature - it’s how socket-compatible Raspberry Pi 68k emulators work with the ~60ish latches that interface with the 68k bus.
By @mmastrac - 6 months
I think the successor to the RP2040 needs to features to absolutely clobber the market:

1. A true, ulta-super-duper-low-power mode, and 2. Proper external memory support.

By @cellularmitosis - 6 months
> Our HardFault handler can now ... quickly interpret the faulting instruction, emulate the write, flush the cache line, and resume.

This sounds similar to the approach taken by yocto-8

https://github.com/yocto-8/yocto-8/blob/main/doc/extmem.md