Atomic operations don't work on memory in PSRAM #2505

New issue

Open

opened 2025-06-06 12:18:56 -05:00 by sfe-SparkFro · 2 comments

sfe-SparkFro commented

2025-06-06 12:18:56 -05:00

(Migrated from github.com)

~~I unfortunately don't have any replication code to share right now, as I'm working on a project that's private for the time being.~~ Edit: See next comment

But the short explanation is that I have some code that calls __atomic_fetch_add(my_int, 1). When my_int is in SRAM, everything works fine. When my_int is in PSRAM, the system gets into an infinite loop, forever incrementing my_int (seems like once every clock cycle).

I saw this thread in which it is mentioned that atomic operations are only supported for memory <=32 bits in size (otherwise a spin lock is used), and not supported in PSRAM. That's fine, the performance hit of a spin lock is negligible for me. But seems like there's currently no check for the memory location to actually do a spin lock if the memory is in PSRAM.

~I unfortunately don't have any replication code to share right now, as I'm working on a project that's private for the time being.~ Edit: See next comment But the short explanation is that I have some code that calls `__atomic_fetch_add(my_int, 1)`. When `my_int` is in SRAM, everything works fine. When `my_int` is in PSRAM, the system gets into an infinite loop, forever incrementing `my_int` (seems like once every clock cycle). I saw [this thread](https://forums.raspberrypi.com/viewtopic.php?t=380551#p2274670) in which it is mentioned that atomic operations are only supported for memory <=32 bits in size (otherwise a spin lock is used), and not supported in PSRAM. That's fine, the performance hit of a spin lock is negligible for me. But seems like there's currently no check for the memory location to actually do a spin lock if the memory is in PSRAM.

sfe-SparkFro commented

2025-06-06 13:58:54 -05:00

(Migrated from github.com)

Actually, I did make some replication code. It uses Arduino Pico since PSRAM support doesn't exist here yet.

int my_int;
// int PSRAM my_int;

void setup() {
  while (!Serial) {}
  delay(1000);
  Serial.begin(115200);
  Serial.printf("PSRAM Size: %d\r\n", rp2040.getPSRAMSize());
  my_int= 0;
}

void loop() {
  Serial.printf("my_int: %i\n", my_int);
  __atomic_fetch_add(&my_int, 1, __ATOMIC_ACQ_REL);
  delay(1000);
}

Using a board with PSRAM, running as is works fine:

PSRAM Size: 8388608
my_int: 0
my_int: 1
my_int: 2
my_int: 3
my_int: 4
...

Swapping the comments on the top 2 lines so my_int is in PSRAM, it freezes when __atomic_fetch_add() is called:

PSRAM Size: 8388608
my_int: 0

Connecting a debugger, my_int is just being incremented in a loop forever.

Actually, I did make some replication code. It uses [Arduino Pico](https://github.com/earlephilhower/arduino-pico) since PSRAM support doesn't exist here yet. ``` int my_int; // int PSRAM my_int; void setup() { while (!Serial) {} delay(1000); Serial.begin(115200); Serial.printf("PSRAM Size: %d\r\n", rp2040.getPSRAMSize()); my_int= 0; } void loop() { Serial.printf("my_int: %i\n", my_int); __atomic_fetch_add(&my_int, 1, __ATOMIC_ACQ_REL); delay(1000); } ``` Using a board with PSRAM, running as is works fine: ``` PSRAM Size: 8388608 my_int: 0 my_int: 1 my_int: 2 my_int: 3 my_int: 4 ... ``` Swapping the comments on the top 2 lines so `my_int` is in PSRAM, it freezes when `__atomic_fetch_add()` is called: ``` PSRAM Size: 8388608 my_int: 0 ``` Connecting a debugger, `my_int` is just being incremented in a loop forever.

kilograham commented

2025-06-12 17:40:55 -05:00

(Migrated from github.com)

Probably just going to leave this as documentation. If memory doesn't support CPU atomics, then I think that is expeted behavior; leaving open in 2.2.0 for discussion tho