I guess to test RAM, one would want to write known values into each location and validate that they can successfully be read back. Is that how you interpret a RAM check?
Yes, There are lots of ram check examples like writing alternating patterns of 0xAA55AA55. And writing rotating bit patterns then reading back to see if things are as expected. March tests, etc... I don't want the RTOS to be using the SPI PSRAM, so I'd not integrate it into alloc, but configure to integrate into esp32 memory map.
Not really sure about the flash test. Maybe just writing to a big partition that is everything but the app. If I don't do it in the bootloader then maybe select using only one core for FreeRTOS so there is less going on.
The lack of a message at boot is likely (opinion) because the test passed and there is nothing out of the ordinary to report.
I think they want to see a check list of things passing. Even if it's just a rudimentary test.
As for flash and ram read/write speeds, that sounds/feels distinct from testing whether the memory works over its entire range. Read/write speeds should be governed under a benchmark.
I agree. That's why I don't think the info is going to be all that useful to them. I figure the simplest thing is just do some R/W blocks and time them, then spit out the numbers. I feel like it's a case where management says "we need to test", then throws that nebulous requirement at an engineer in hopes that he'll fill in all the details. It's funny because the benchmark is what got this going. They said they wanted a benchmark and that could be the start of a test platform.
In the end I'm guessing that it will be a standalone app that goes through each component including ram and flash, performs some set to tests, and prints out "yah or nay".
John A