• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 82 subscribers
  • Views 138 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.

TMS320F2812: L0 Memory Values Overwritten by Debugger?

6195937
Prodigy 10 points
Part Number: TMS320F2812


I am using the scripting environment with the XDS560v2 debugger. I load a program to RAM the H0 region to read the L0 region and transmit it off the part. I load the program, run all code not involved in the transmission (halting at a set breakpoint), I halt the CPU and have the XDS560v2 write the L0 region, then run the remainder of the code. However, once I allow the CPU to run the code to transmit the data off the part a few addresses in the region are always modified to the same wrong values (in particular, the 0x8856 address). I have debugger read back the entire region after running all the code and verify that those addresses are changed.


Is this this is a result of using the XDS560?

  • 0
    TI__Guru* 77460 points

    Thanks for reaching out to the E2E Forums.

    Can you advise on what value you are seeing at 0x8856? 

    If you see 0x7625 this is the opcode for the ESTOP0 instruction, which CCS places to create the SW breakpoint.  Once you are ready to export your data, if you clear the breakpoint it will remove this instruction from the memory before you scan it out.

    Another possibility is that your stack is also in L0, you can check your linker file(.cmd) to see where the stack is being placed.  Normally it is in M0 or M1, but it doesn't hurt to check this.  You could relocate it based on memory availability.

    Let me know on the above and we can debug as needed.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    Prodigy 10 points

    Hi Matthew,

    I see the value 0x911b. The consecutive address also changes and has the value 0x0000.

    Just to be clear, L0 is only data. The program is loaded to H0 along with the stack. 

    Kevin

  • 0 in reply to 6195937
    TI__Guru* 77460 points

    Kevin,

    Just to clarify that you are using the DSS as the scripting environment?  I'm not aware of either the debug probe or DSS would write something to a memory region to support the scripting service.  I looked at 0x911B from an opcode POV, and this isn't anything that would make sense on its own in terms of inserting to make the CPU do something.

    Would it be possible to share the DSS script?  I'll also ask a few of my colleagues in case they are aware of this behavior.

    Best,
    Matthew