Hi everyone,
I'm struggling to find a right and reliable way to use an external PSRAM with RP2350B boards.
Here are the 2 boards I have:
* Pimoroni PGA2350
* WeAct RP2350B Core Board (with an additional 8MB PSRAM soldered module)
According various informations gathered on the RP2350 datasheet, this forum and Gemini/ChatGPT, I proceed with those steps in order to test embedded PSRAM:
PSRAM initialization:And... that's it ?! It seems to be surprisingly enough to tell the RP2350 to use the PSRAM on address:(or 0x15000000 for uncached)
First question:
why all examples use XIP_CTRL_WRITABLE_M1_BITS and not XIP_CTRL_WRITABLE_M0_BITS?
The latter would allow to use 0x10000000/0x14000000 base addresses (respectively cached/uncached).
Indeed, I tested both, without any issue so far. So I wonder what is the difference between M0 and M1 region?
Then, after having intialized the PSRAM thanks to the init_psram() function, according to examples found, I simply have to initialize a pointer to the freshly mapped base address:
So, simply using this pointer, should allow me to read/write the entire 8MB of my PSRAM module.
Here is the test I used:This code seems to work well. But I have a little problem:
If I initialize test_size above 8MB (example: size_t test_size = 1024 * 1024 * 9; // or 10 or 11 or 12...), the test also runs successfully without any issues![:shock:]( "Shocked")
I have no explanation of this, and I wonder if this code really writes on PSRAM and not elsewhere...
To give more context about my requirements: I don't want to make things like expanding heap to PSRAM, or making a complex allocator. Having a valid pointer on base address is enough for my use cases (frame buffers, volatile large buffers, etc...).
I'm struggling to find a right and reliable way to use an external PSRAM with RP2350B boards.
Here are the 2 boards I have:
* Pimoroni PGA2350
* WeAct RP2350B Core Board (with an additional 8MB PSRAM soldered module)
According various informations gathered on the RP2350 datasheet, this forum and Gemini/ChatGPT, I proceed with those steps in order to test embedded PSRAM:
PSRAM initialization:
Code:
// Size of the PSRAM (8 MB = 8 * 1024 * 1024 bytes)#define PSRAM_SIZE_BYTES (8 * 1024 * 1024)// GPIO 47 as CS#define PSRAM_CS_PIN 47void init_psram() { gpio_set_function(PSRAM_CS_PIN, GPIO_FUNC_XIP_CS1); // Set GPIO 47 as CS pin xip_ctrl_hw->ctrl |= XIP_CTRL_WRITABLE_M1_BITS; // Configure XIP controller for writable M1 region}Code:
// Base address of the PSRAM/Flash mapped in XIP (cached)#define PSRAM_BASE_ADDRESS 0x11000000First question:
why all examples use XIP_CTRL_WRITABLE_M1_BITS and not XIP_CTRL_WRITABLE_M0_BITS?
The latter would allow to use 0x10000000/0x14000000 base addresses (respectively cached/uncached).
Indeed, I tested both, without any issue so far. So I wonder what is the difference between M0 and M1 region?
Then, after having intialized the PSRAM thanks to the init_psram() function, according to examples found, I simply have to initialize a pointer to the freshly mapped base address:
Code:
uint8_t* psram_buffer = (uint8_t*)PSRAM_BASE_ADDRESS;Here is the test I used:
Code:
size_t test_size = 1024 * 1024 * 8;for (size_t i = 0; i < test_size; ++i) { psram_buffer[i] = (uint8_t)(i % 256);}printf("Verifying data in PSRAM...\n");bool success = true;for (size_t i = 0; i < test_size; ++i) { if (psram_buffer[i] != (uint8_t)(i % 256)) { printf("Verification error at index %lu: Expected %d, found %d\n", i, (uint8_t)(i % 256), psram_buffer[i]); success = false; break; } }if (success) { printf("Verification successful for %lu bytes.\n", test_size);} else { printf("Verification failed.\n");}If I initialize test_size above 8MB (example: size_t test_size = 1024 * 1024 * 9; // or 10 or 11 or 12...), the test also runs successfully without any issues
I have no explanation of this, and I wonder if this code really writes on PSRAM and not elsewhere...
To give more context about my requirements: I don't want to make things like expanding heap to PSRAM, or making a complex allocator. Having a valid pointer on base address is enough for my use cases (frame buffers, volatile large buffers, etc...).
Statistics: Posted by laurent — Sat Jul 26, 2025 8:34 pm