Other Parts Discussed in Thread: C2000WARE,
We are using the STL_March_testRAM and STL_March_testRAMCopy functions (as provided with C2000ware) to test all RAM memory on the TMS320F280045 device. We are using the "copy" version from M0 and M1 and the destructive version for all others. We are running these tests immediately after the C environment is configured in the pre_init function (right before auto init).
When I measured the number of cycles taken by the test using a debugger I get 1246065 CPU cycles in average for the GS ranges which are the largest (8192). Running at 100Mhz (I think) this would mean something like 1.24 milliseconds for each GS range. But I also used a GPIO pin to calculate how much time each test took with an oscilloscope and got an average of 125 milliseconds for each GS range. I confirmed that setting and clearing of the GPIO pin doesn't add much overhead, so the timing is close to actual.
Checking https://www.ti.com/lit/an/spracb9/spracb9.pdf Table 3. It seems that the performance should be measured in microseconds not in milliseconds.
I have a hard initialization time requirement (< 500 ms which also includes SPI handshaking with another MCU). As much as possible we would like to keep the RAM test done at initialization, based on SPRACB9's stated performance we should be able to achieve it.
Any ideas why the RAM tests are taking so long in my application?
Thanks in advance,