• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 31 subscribers
  • Views 1359 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.

LAUNCHXL2-TMS57012: CCS throws Failed to download RAMCode

v01d
Expert 1965 points
Part Number: LAUNCHXL2-TMS57012
Other Parts Discussed in Thread: SEGGER, RM48L952

Cannot understand what causes this, and also how to get out  / fix it:

Sometime during the session after the code uploaded & runs, if I stop the debugger and continue/step from that point, the CCS throws this :

CortexR4: Trouble Reading Register PC: Failed to measure CPU clock frequency
CortexR4: Trouble Reading Register CPSR: Failed to download RAMCode. Failed to prepare for programming. Failed to download RAMCode!
CortexR4: Trouble Reading Register SP: Failed to download RAMCode. Failed to prepare for programming. Failed to download RAMCode!

.. What is CCS doing with RAMCode while I'm trying to just step / go or continue ?

Also odd, but the CPU seems stuck on the instruction, or is held in halt/ break. The only thing to do is full re-set.   This, does not necc. fix it , as from next debug upload/attach, the behavior may repeat.

What can be causing this, and what is it actually doing with dowloading from RAMCode ? How to fix this?

  • 0
    TI__Guru**** 192486 points

    Please check if the VCC power supply and clock are okay. You can bring out the VCLK, HF LPO on to the ECLK terminal, then monitor the clock at ECLK pin.

    Does the JTAG lose connection? 

    Does this happen in sys_startup.c or in your own code section? 

  • 0
    Guru 92251 points
    v01d said:
    What can be causing this, and what is it actually doing with dowloading from RAMCode ?

    Are you using a Segger J-Link?

    I searched a CCS 10.3 installation for the string "Failed to download RAMCode" on the only occurrence was in C:\ti\ccs1030\ccs\ccs_base\DebugServer\drivers\JLink_X64.dll

    When programming the flash when a program is downloaded by starting a CCS debug session, I think the flash programming code has to be downloaded into RAM. However, not sure what would trigger the CCS debugger to want to program flash when the debugger is stopped and then resumed.

    Perhaps if you can attach the Debug Server Logs for when the problem occurs, that would help to understand what is causing the problem.

  • 0 in reply to Chester Gillon
    Expert 1965 points
    Chester Gillon said:
    Are you using a Segger J-Link?

    Yes.

    After looking more into this, the problem seems related to my other issue I reported after this against CCS , setting SW break points.

    If, you do the attach configuration with loading symbols only, the CCS/debugger ignores the option to Dissallow all software break points, and, in jects soft break points instructions. 

    If, and once, you hit such point at runtime, it is not possible to resume form such state, as the core is not stepping/executing anymore. This is the case for me with J-Link, and why i want to avoid all SW enabled breakpoints. 

    Once it's in that break-in state, trying to step/resume leads to all sort of failed issues as described, RAMCode error,  Failed to read PC, SP, etc registers. 
    I do not have any debug logs at hand to attach, may be I need to enable them.

  • 0 in reply to Chester Gillon
    Expert 1965 points
    Chester Gillon said:
    , I think the flash programming code has to be downloaded into RAM

    I do not know.

    But , with the JTAG interface access, it seems odd I would need a special 'bootloader' to program the flash.

    EDIT:  Ah I see what you mean there , it seems they call it Indirect flash programming ,ie. through CPU

    https://wiki.segger.com/Programming_External_SPI_Flashes

  • 0
    Expert 1965 points

    Well, this is some clue :

    Segger's  "Unlimited Flash Breakpoints" explanation:

    " ---------------------------------------------------------------------------------------------------------------------------------------------------

    How does this work?

    Basically very simple:
    The J-Link software reprograms a sector of the flash to set or clear a breakpoint.

    What performance can I expect ?

    A RAMCode, specially designed for this purpose, sets and clears Flash Breakpoints extremely fast; on micros with fast flash the difference between breakpoints in RAM and flash is hardly noticeable.

    "------------------------------------------------------------------------------------------------------------------------------------------------------

    Ok, so my  un-wanted SW (rather than Hw..) breakpoints which get set,  trigger that magic "RAMCode" to re-program my flash memory runtime. 

    So this RAMCode then needs to re-program my flash section where I'm setting a break point. 

    The RAMCode in this instance, is prob created by TI, as Segger gives SDK  to allow 3rd p to implement that how they see fit, to be used with JLink  dll.

    Now it seems I have more questions : I really hope that RAMCode is marked executable by default, as my runtime setup does not allow any code to run from RAM (MPU no exec).

    Further, I 'm interested to know how injecting new instructions  & reprogramming flash co-exists with MPU regions.  Very hypothetically, but if say a couple of injected " bkpt #0" into my executable context's flash may put it outside of a defined executable MPU region.  For bkpt we prob don't care, as MPU will allow bkpt to be exec in any CPU mode ...?   But what if these sw breakpoints push my other statements outside of the MPU region limit..? How can you resume then?

  • 0 in reply to v01d
    Guru 92251 points
    v01d said:
    Further, I 'm interested to know how injecting new instructions  & reprogramming flash co-exists with MPU regions. 

    I looked at an example for a RM48L952 debugged using CCS 10.3 and a Segger L-Link.

    Initially the MPU permission for the RAM was set to PRIV_RW_USER_RW_EXEC and could step the program successfully.

    The MPU permission for the RAM was changed to PRIV_RW_USER_RW_NOEXEC, and that caused errors attempting to step the program:

    The errors aren't the same as in your case, but after the "Trouble Reading Register SP" was reported has unable to step the program.

  • +1 in reply to Chester Gillon
    Guru 92251 points
    Chester Gillon said:
    The MPU permission for the RAM was changed to PRIV_RW_USER_RW_NOEXEC, and that caused errors attempting to step the program

    A work-around appears to be to go the J-Link control panel and change the Settings -> Flash Breakpoints from "Auto" to "Off":

    Which means the J-Link only then set hardware breakpoints:

    Since there are a limited number of hardware breakpoints (6?), once all are in use then get an error attempting to set further breakpoints.

    However, at least only using hardware breakpoints seems to make debugging reliable when the RAM doesn't have execute permission.

  • 0 in reply to Chester Gillon
    Expert 1965 points

    Ha, well this one I deff gonna try, because CCS 's option to not Allow SW breakpoints does not work.

    Thanks, I will try this out.