Enable 128K virtual memory via external SPI SRAM by earlephilhower · Pull Request #6994 · esp8266/Arduino (original) (raw)

--edit--

This is at a state where it's working well and there is a reasonable API for users with a 23LC1024 SRAM wired up. The virtualmem example shows all the calls that are required.

Theory of Operation:

The Xtensa core generates a hardware exception (unrelated to C++ exceptions) when an address that's defined as invalid for load or store. The XTOS ROM routines capture the machine state and call a standard C exception handler routine (or the default one which resets the system).

We hook into this exception callback and decode the EXCVADDR (the address being accessed) and use the exception PC to read out the faulting instruction. We decode that instruction and simulate it's behavior (i.e. either loading or storing some data to a register/external memory) and then return to the calling application.

We use the hardware SPI interface to talk to an external SRAM/PSRAM, and implement a simple cache to minimize the amount of times we actually need to go out over the (slow) SPI bus. The SPI is set up in a DIO mode which uses no more pins than normal SPI, but provides for ~2X faster transfers.

NOTE: This works fine for processor accesses, but cannot be used by any of the peripherals' DMA. For that, we'd need a real MMU.

Hardware Configuration (make sure you have 3.3V compatible SRAMs):

• SPI interfaced byte-addressible SRAM/PSRAM: 23LC1024 or smaller
  CS -> GPIO15
  SCK -> GPIO14
  MOSI -> GPIO13
  MISO -> GPIO12
  (note these are GPIO numbers, not the Arduion Dxx ones. Refer to your ESP8266 board schematic for the mapping of GPIO to pin.)
• Higher density PSRAM (ESP-PSRAM64H/etc.) should work as well, but I'm still waiting on my chips so haven't done any testing. Biggest concern is their command set and functionality in DIO mode. If DIO mode isn't supported, then a fallback to SIO or moving to QIO is a possibility.

This is still a WIP, but the base handler is functional.
Using an exception handler that hooks into the invalid read/write address hardware exception, capture reads to 256MB starting at 0x1000_0000 and (eventually) map that into a SW managed cache in front of an external SPI SRAM.
This RAM will be slower than internal RAM since it is SW managed, but should accessible for use by all apps and the OS without any special concerns. Don't expect to use this RAM in ISRs or time critical sections.
The code now captures the read and write exceptions and continues operations, but the SPI SRAM read/write and the cache management is not in there yet. I need to dig out my SPI SRAM and hook it up to give it a try.
Based off of the PROGMEM misaligned exception handler.