‎2022-01-31 01:38 PM
Hi I am using FreeRTOS on STM32H7. For large data, I am using qspi attached and memory mapped external psram.
Question is: what will happen if both task try to read/write to psram at the same time?
Is there any cache or buffer in place?
What if the scheduler switch to another task while the qspi transfer is still in operation?
Is accessing memory mapped qspi ram thread safe?
I am getting strange errors, similar to the memory corruptions when something overflows.
Memory is accessed directly at the address 0x90000000.
Solved! Go to Solution.
‎2022-02-02 12:05 AM
Thank you for your answers.
Good to know that is is safe to use it as normal memory.
The problem was that I had wrong psram size set and therefore 0x90000000 and 0x90800000 shared same memory :tired_face:
This caused to overwrite memory at 0x90000000 when writing to 0x90800000.
‎2022-01-31 02:35 PM
Two tasks can't be active at the exact same time, the CPU only runs one instruction at a time.
But effectively, yes, the CPU will block until it gets the information it needs to continue. This is true for other sources of data such as internal flash.
If you're seeing memory corruption and something overflowing, likely the issue is elsewhere in your code.
If two tasks are reading and modifying the same data, you need to implement the appropriate logic so they don't talk over each other, such as critical sections or OS-specific locks.
‎2022-01-31 02:58 PM
If your HW is properly validated, you'd know if it was working correctly.
The memory mapping should work the same from all tasks, threads, and code perspectives. If it doesn't you have other underlying issues, see point one..
‎2022-01-31 02:59 PM
Arguably the Cortex-M7 is super-scalar, and some H7 implementation have two cores operating independently and concurrently..
‎2022-02-02 12:05 AM
Thank you for your answers.
Good to know that is is safe to use it as normal memory.
The problem was that I had wrong psram size set and therefore 0x90000000 and 0x90800000 shared same memory :tired_face:
This caused to overwrite memory at 0x90000000 when writing to 0x90800000.