• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 82 subscribers
  • Views 356 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F2800157: RAM Data Not Zeroed After Code Load

Chen-Chih Liu
Intellectual 340 points
Part Number: TMS320F2800157
Other Parts Discussed in Thread: C2000WARE

Tool/software:

Dear Experts,

I used the CCS Debug tool to load a program, and before clicking the "run" button, I noticed that the RAM (LS0 and LS1 RAM) areas contained non-zero data. Upon further investigation, I found that these data were mostly copied from Flash, as the RAM contents were largely, but not entirely, identical to the Flash contents. I have not observed this phenomenon on other TI C28x devices before.

Even when using the TI demo code, the issue persists. I have confirmed that the RAM data are not associated with functions running in RAM. For instance, while the functions running in RAM occupy the range from 0x8000 to 0x8AAC, some data also appear at 0x9200.

After tracing, it seems that the data at this RAM location are being copied from Flash at 0x8A200.

Could you please clarify if, on the F2800157, some Flash data are copied to RAM, causing the RAM to contain non-zero data after loading the program but before running the code? (Even after running the code, this RAM data does not revert to zero.) This behavior is unusual, as I have not encountered it on other C28x devices.

For reference, I am using the F2800157 EVB for verification.

Thanks and regards,

C.C.Liu

  • 0
    TI__Guru* 81560 points

    C.C.

    Can you give the example project, version of CCS, and version of C2000Ware you are using? 

    I agree that the copy of the flash to RAM code is taken care by a memcopy function call inside our examples that is part of program execution.

    There is an alternate method to copy the code from flash to RAM through use of boot init tables; but this should be obvious in your .cmd file of the project, just looking a few C2000Ware examples I don't see this method in use. Even then, the device has to execute code, even though not in the .main.

    My only other thought is if the memory contents are from a prior run, or if you have code already in the flash and you have the boot pins configured to boot to flash, then as part of that code execution the memcopy would have happened before you connect to the device.

      There are lines in the GEL file associated with the device that does a mem init on connect, that would zero the memories out; if that GEL is not present then this would not happen automatically.

    If you change the boot pins to "Wait Boot" you could see if this phenomena goes away.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    Intellectual 340 points

    Hi Matthew,

    CCS version: 12.5
    C2000Ware version: C2000Ware_5_01_00_00
    TI demo project that I used: ..\C2000Ware_5_01_00_00\driverlib\f280015x\examples\flash\flashapi_ex1_programming

    Meanwhile, after switching the boot mode to 'Wait Boot', the RAM (LSx) is still being filled with flash data (the RAM data is filled after loading the program but before I start to run the code).

    Thanks and Regards,

    C.C, Liu

  • 0 in reply to Chen-Chih Liu
    TI__Guru* 81560 points

    Chen-Chih,

    Thanks for giving the example file, let me see if I can re-create this on my setup.

    Best,

    Matthew

  • +1 in reply to MatthewPate
    TI__Guru* 81560 points

    Chen-Chih,

    I have reproduced the behavior and have an explanation. 

    When we load a .out file that contains flash addresses, the CCS flash plug-in does so by first copying the flash API/some kernel in order to pass flash contents into it to be programmed.  This is what you are seeing in the L0 SRAM after a program load, but before you execute the code.

    Now, if you proceed to execute the code through the memcopy function, you will see the contents are different than what existed after the program load with CCS.

    So, the memory you are seeing after a flash loaded program is not used by whatever project you have loaded.

    If you want after the program is loaded, you can fill the L0/L1 SRAM with all 0x0000, and you will see the project executes successfully as the memcopy happens as it should.

    On other devices, where there was more SRAM, we likely placed this code in a higher address SRAM that may not have been used, and so it wasn't obvious.  Here, since there is not alot of SRAM, the same sections are getting re-used by the program loader, and the project itself.

    Another thing you can try for debug, is after the code is programmed, disconnect and re-power(in wait boot), then manually connect to the target (don't use the debug button, which will re-load the flash and SRAM again), load symbols of this project, and you should see SRAM is all 0x0000 and again project will run correctly.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    Intellectual 340 points

    Hi Matthew,

    Thanks for your explanations. After testing the F280049C, I found that the Flash data was copied to start at 0xC0000 (GS0) after programming the code, which had not affected my code for this chip before, so I hadn't observed this behavior.

    In my own applications for the F2800157, I have some global variables without initial values. If Flash data is copied to LSx, these uninitialized global variables may be assigned the copied Flash data, causing abnormal program behavior.

    To solve this problem, I found that the LSxINIT register can be used to initialize the LSx RAM. After configuring this register, the LSx is indeed cleared to zero. I would like to confirm: can I configure this register at the beginning of the main function (before any system initialization)?

    Thanks and Regards,

    C.C, Liu

  • +1 in reply to Chen-Chih Liu
    TI__Guru* 81560 points

    C.C., 

    I had a recent post about something similar.  Please take a look at what this customer mentions in his last post, basically inserting the INIT into code_start_branch.asm.  Doing the init at this time would guarantee we are not overwriting anything that is done in .cinit.

    https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1416967/tms320f28p650dk-questions-about-gsxram-initialization-after-cpu1-watchdog-reset

    Best,
    Matthew