• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 81 subscribers
  • Views 233 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F280045: STL_March_testRAM taking too long

Jose Lopez2
Prodigy 180 points
Part Number: TMS320F280045
Other Parts Discussed in Thread: C2000WARE,

Hello,

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,

Jose Lopez

  • 0
    TI__Guru 50575 points

    Are you running the function before the SYSCLK and Flash are configured? Can you confirm that you actually are running at 100 MHz and not at the 10 MHz INTOSC rate? Similarly at start up I think Flash wait states are set to the max value and cache/prefetch are disabled, so that could be adding some cycles. Are you executing the STL_March functions from Flash or RAM?

    Whitney

  • 0 in reply to Whitney Dewey
    Prodigy 180 points

    Hi Whitney,

    I am running the function right after C initialization as part of the system_pre_init function which is called in c_int00 (boot28.asm).  Very few things are done before it, according to comments:

    • Initialize stack pointer
    • Initialize status bit fields
    • Set C28x modes
    • Setting status bits/registers to reset values

    I am not sure I am running at 100 Mhz.  Even if the processor was running at 10Mhz  the time for my example GS range would be 12 milliseconds and not the 125 milliseconds I measured with the oscilloscope.

    We decided to run the RAM test functions before the initialization of variables as we noticed that the destructive tests would, of course, destroy the RAM contents, and the non-destructive tests were slower.   

    We are running the flash initialization later as the first step in main, we are setting the waitstates to 4 (not sure if this is good or not).  Would you recommend moving this flash initialization to happen before the RAM test?

    The STL_March functions are running from Flash.

    Thanks,

    Jose Lopez

  • +1 in reply to Jose Lopez2
    TI__Guru 50575 points

    It sounds like you are probably running at 10 MHz if you aren't configuring SYSCLK until you get to main. You could take a look at the ClkCfgRegs to check the divider/multiplier values.

    4 wait states is correct--you'll see in the datasheet that 4 is required for a 100 MHz CPUCLK. You can check the value of FRDCNTL in Flash0CtrlRegs to see what it is configured to when the mark test runs. On a reset the RWAIT field is 0xF, but off the top of my head I don't recall if boot ROM adjusts it.

    But yes, moving this configurations to a point before the RAM test could be an option.

    Whitney

  • 0 in reply to Whitney Dewey
    Prodigy 180 points

    Hi Whitney

    I moved my clock and flash initialization routines to pre_init before the RAM tests and it seems to have fixed the issue.  I am now measuring an average of 3.7 milliseconds for the GS ranges and a total of 24 milliseconds for the whole test.

    Thanks!

    Jose Lopez