• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 903 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.

TMS320F28379D: DCSM - How to continue debugging from WAIT mode

Anil Singhal
Intellectual 810 points
Part Number: TMS320F28379D


I have locked the device and to debug the code, I place the TI boot loader into the WAIT mode.

After unlocking the device via the CCS debugger, I set a break point at the start address (0x80000).  However, pressing the continue button, causes the following error:

C28xx_CPU1: Error: (Error -1135 @ 0x3FF16A) The debug probe reported an error. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation. (Emulation package 8.1.0.00007)
C28xx_CPU1: Unable to determine target status after 20 attempts
C28xx_CPU1: Breakpoint Manager: Unable to remove requested AET job
C28xx_CPU1: Failed to remove the debug state from the target before disconnecting.  There may still be breakpoint op-codes embedded in program memory.  It is recommended that you reset the emulator before you connect and reload your program before you continue debugging

How can I continue debugging after unlocking the device?

  • 0
    TI__Expert 5430 points

    Hi Anil,

     By locked, you mean you changed the CSMPSWDs from its default value right?

    What do you mean by unlocking the device? Did you provide the valid passwords via the CCS debugger(GEL) and were you able to connect to the device?

    Also please check the DCSM register space after this unlocking sequence to make sure that its really unlocked. You’ll get a clue on what is really happening because of which you are getting the above error.

    Hope this helps.

    Thanks & Regards

    Pramod

  • 0 in reply to Pramod P
    Intellectual 810 points

    Thanks Pramod for your response.

    I have read the technical reference manual several times. I have programmed the OTP.  I know all about the OTP blocks and the LINKPOINTER register

    What do you mean by unlocking the device is your question.? May be I am not using the right terminology.  YES the device has been unlocked by providing the right password.  FYI: prior to unlocking the device, the contents of protected blocks along with registers are all ZERO. After unlocking the device, the memory contents and register contents are readable.  YES.. I DO BELIEVE THAT THE DEVICE HAS BEEN UNLOCKED.

    Please see my previous posts.  I am not a novice on this topic.

    Is VIVEK available to answer this question?

  • 0 in reply to Anil Singhal
    Intellectual 810 points

    Hi Pramod,

    I apologize for bit of a terse message in my previous response.

    The problem is this and I post this for all other users of Delfino who are using DCSM and trying to debug at the same time.

    The PROBLEM is: After UNLOCKING the device while in the TI bootloader's WAIT mode, and placing a breakpoint in the my application code, TI boot loader re-programs the DcsmRegsZ1.Z1_CSMKEY registers.  This locks the device again and when the break point is enabled, one gets the debugging error.

    I don't know what the solution is so that after unlocking the device, the TI boot loader keeps the device unlocked.

  • 0 in reply to Anil Singhal
    TI__Expert 5430 points

    Hi Anil,

    Appreciate the fact that you have read the TRM and telling me that you are not a novice in this topic. My intention was to help you with the pointers in order for you to continue to debug your problem like you asked (The subject of this post).

    Coming to the PROBLEM: Looking at the description in your latest response, I believe that the debugger is getting disconnected due to an ECSL violation (please read through the ECSL section in the DCSM chapter of the TRM for more details). In short it is this, If the core is halted at a secure location, the ECSL will come into effect, disconnecting the debugger which is why you get the error message on CCS.

    To avoid this, please write the correct lower 64 bit password CSMKEY (CSMKEY(0/1)) registers in your application before the breakpoint is hit. This will allow you to step into/halt inside a secure code while maintaining the CSM protection while the ECSL protection is disabled.

    Hope this helps you continuing the debug of your application. Kindly let me know if this does not solve your issue.

     

    FYI, Vivek is currently on vacation.

    Thanks & Regards

    Pramod

  • 0 in reply to Pramod P
    Intellectual 810 points

    I will repeat the steps I take.

    1. Place the device in the WAIT mode by placing GPIO84=Low & GPIO72 = HI.

    2. I place the correct password in DCSM.CSMKEY (0&1). I unlock the device by using the On-Chip Flash tool by pressing the UNLOCK button.

    3. I verify that the device is unlocked by examining the contents of my code starting at 0x80000.  Prior to unlocking the device, memory contents at 0x80000 are displayed as ZERO where as after unlocking the device I can see my code. 

    4. On Core 1 the debugger is stopped at address 0x3FF16A which is the 1st instruction after the reset.

    5. I place a breakpoint at address 0x80000 which is the starting address of my application and it is the same location where TI boot loader branches to when booting from Flash.

    6. I press the go button and the debugger gets disconnected due to an ECSL violation.

    I even reported the cause in my previous post: The TI boot code re-programs the CSMKEY registers and thus re-locking the device and that causes an ECSL violation.

    I appreciate the help but over the last day or so, I have not received any information that is solving problem. You have suggested that "To avoid this, please write the correct lower 64 bit password CSMKEY (CSMKEY(0/1)) registers in your application before the breakpoint is hit. This will allow you to step into/halt inside a secure code while maintaining the CSM protection while the ECSL protection is disabled."  How is that helpful?

  • 0 in reply to Anil Singhal
    TI__Expert 5430 points

    Anil,

    I understood your sequence which is why I suggested you to write the correct 64 bit lower CSMKEY in your application before you place a breakpoint and halt your CODE. Looks like you didn't understand my suggestion fully. Let me explain.

    Please write the code which unlocks ECSL(CSMKEY 0/1) at the start of the application code (0x80000) and then place the breakpoint at a later address so that by the time the debugger halts at the breakpoint, you would have the ECSL unlocked. This is what I meant when I said "before the breakpoint is hit".

    Only other way that I can think of would be to make sure that you program only the upper CSMPSWD 2/3 and leave the lower 64 bit CSMPSWD 0/1 default in the OTP. That way, even if the TI bootloader attempts to write the default value, the ECSL would still be disabled while the zone would be secure. But I would recommend this method only for debug.

    Hope this helps.

    Thanks & Regards

    Pramod

  • 0 in reply to Pramod P
    Intellectual 810 points

    The code is resident in the FLASH and it has been shipped to customers.  We were trying to prevent UN-authorized access to the code.  So it is difficult to change the code for debug purposes.   The idea is to load the symbols and debug as needed.

    Since I spent time going through the TI debugger and I have identified the area where DCSM registers are being reprogrammed, the only solution I can think of it is to skip over the offending code. 

    I tried it manually and can now debug the code as planned.  The only thing I need to do is to automate the process so that others don't have to be an expert on DCSM.

    I am thinking of either using GEL files or DSS (Debug Server Scripts)..  But the documentation on the TI website is sparse on GEL files. The only documentation on GEL commands seems to be "spraa74a Gel File.pdf"

    Do you have access to any other documentation?

  • 0 in reply to Anil Singhal
    TI__Expert 5430 points

    Anil,

     

    Unfortunately, we do not have any other documentation on GEL as far as I am aware apart from the one you mentioned.

    However I just wrote down an example of a GEL function which might help you to automate this. You can tweak this and use it accordingly.

    hotmenu CPUreg_write_debug()

{

               GEL_BreakPtAdd(0x80020);          // Put a breakpoint before the CSM is locked again. This is just an example.

               GEL_BreakPtAdd(0x80030);          // Put a breakpoint after the CSM is locked but the ECSL is still disabled. This is just an example.

               GEL_Run();

               PC = PC + 0x8;    //Move the PC according to your function where you attempt to write to CSMKEY0/1. Again this is just an example.

               GEL_Run();

   GEL_TextOut("\n\n Make sure that its at the second breakpoint now \n\n");

}

    Once you have put this function in your GEL file save it and reload the gel, this function will be listed under the Scripts option in the menu bar in CCS for you to execute when you want. You can get more information on this in the GEL documentation you have pointed out. If you still have any questions, let me know I’ll help you.

    Regarding the DSS, I just googled about it and I think we have a lot of information available online and on the forum as well. I am not very proficient on its usage however as of now.

    Thanks & Regards

    Pramod

  • 0 in reply to Pramod P
    Intellectual 810 points

    Awesome!!.. This really helps.

    Thanks