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.

CCS/TMS320F28379D: Looking for Documentation for Unlocking a Unit with CCS

Part Number: TMS320F28379D

Tool/software: Code Composer Studio

Greetings,

I need to debug a locked unit. a unit using CCS. Where can I find documentation which describes a procedure for unlocking it once CCS is attached?

Thank you,

Ed

 

  • Hi Ed,

    I believe you are looking for the flow of unsecuring a zone by providing the valid password. If 'yes', The Password Match Flow(PMF)  is what you need. This is described in the  Section 3.13.3.2 : CSM Password Match Flow of the device TRM (Technical Reference Manual). Please revert back if this is not what you are looking for. 

    https://www.ti.com/lit/ug/spruhm8i/spruhm8i.pdf

    Hope this helps. 

    Please click on the "verify answer" button if this response resolves your query.

    Thanks & Regards

    Pramod

  • Hi Pramod,

    While I was waiting for your reply, I discovered that.

    I need to be able to attach an emulator without disturbing the system, and unlock it so I can then examine it.  I know how to do the first part, and can see the 0s when I try to read memory.  But once I am at that point, I don't know how to do a PMF.  Is there a way to do it, or do I need to do something else first?

    Thanks,

    Ed

  • Hi Ed,

    When you say that you know how to attach an emulator without disturbing the system, I believe you are talking about removing the GEL file and trying to connect to your target. To do the whole PMF without the GEL is tricky. You would have to open the memory browser on CCS once connected and perform all the operations as you would have done it in your code. That would also unlock the zone.

    Let me know if this information helps.

    Thanks & Regards
    Pramod

  • Hi Pramod,

    You are correct in that part of the process of connecting is to remove the GEL files.

    But could one use a GEL file which does not define any of the callback functions, but instead, defines a function which unlocks the device?

    Thank you,

    Ed

  • Hi Ed,

    Yes. That should be possible. Please give that a try.

    Or you can even have empty callback functions in your GEL. I believe that should not affect your execution flow. 

    Thanks & Regards

    Pramod

  • Hi Pramod,

    OK.

    To do this, the script needs to be able to read registers.  The only examples I can find are reads which are done in the context of an assignment, i.e. a read-modify-write.  I tried a syntax which looks like the following:

    *(long int*)0x<address>

    The script processor didn't complain.  But will this have done an actual read?

    Is there any way to output the results of a  read?

    Thank you,

    Ed

  • Ed Sanders said:
    Is there any way to output the results of a  read?

    You could save the result of the read in a variable, and then use GEL_TextOut() to print the value to the CCS debug console.

  • Thank you Chester,

    Two more questions:

    1. Are variables declared similarly to C?
    2. The resource in the link above is great!  Is this one of the pages which will be taken down at the end of the month?

    Thank you,

    Ed

  • Ed Sanders said:
    Are variables declared similarly to C?

    See Local Variables for Functions and Global Variables for GEL Functions, so yes similar to C. What I can't remember is where it is documented which types are supported in GEL, but looking back at some custom GEL files created before have used both int and unsigned int, for either local or global variables. E.g.:

    unsigned int faultISR_address;
    
    /* When the program is loaded automatically get a breakpoint on the FaultISR function, so that the program halts
     * if a hard fault occurs. */
    OnFileLoaded( int nErrorCode, int bSymbolsOnly , int bProgramOnly )
    {
        /* Clear any breakpoint set from previous runs, to avoid getting multiple breakpoints at the same address.
         * Since GEL_BreakPtAdd may add a hardware breakpoint, clear any hardware or software breakpoints. */
        GEL_BreakPtDel (FaultISR);
        GEL_HWBreakPtDel (FaultISR);
        
        /* Add the breakpoint */
        GEL_BreakPtAdd (FaultISR);
        
        /* Save the address of the symbol for use by OnHalt() */
        faultISR_address = FaultISR;
    }
    
    menuitem "Exception"
    
    /* Unwind the stack after a Cortex-M exception has occurred, so that the CCS debugger shows the context at
     * which the exception occurred.
     * 
     * The LR is used to check for a EXC_RETURN value to verify that in an exception handler before unwinding
     * the stack. */
    hotmenu Unwind_Exception()
    {
        unsigned int saved_lr;
        unsigned int saved_sp;
        unsigned int *stacked_pc;
        unsigned int *stacked_lr;
        
        saved_lr = LR;
        if ((saved_lr & LR_EXC_RETURN_MASK) == LR_EXC_RETURN_MASK)
        {
            saved_sp = SP;
            
            /* Restore the PC and LR at which the exception occurred */
            stacked_pc = saved_sp + 0x18;
            stacked_lr = saved_sp + 0x14;
            PC = *stacked_pc;
            LR = *stacked_lr;
            
            /* Restore the SP value at which the exception occurred, according to if float point state was saved
             * upon the exception entry. */
            if ((saved_lr & LR_EXCEPTION_NO_FLOATING_POINT_SAVED_MASK) != 0)
            {
                SP = saved_sp + 0x20;
                GEL_TextOut ("Unwound stack after an exception with non-floating point state\n");
            }
            else
            {
                SP = saved_sp + 0x68;
                GEL_TextOut ("Unwound stack after an exception with floating point state\n");
            }
        }
    }
    
    /* When the target is halted, if halted at the start of the faultISR function then automatically
     * unwind the exception stack.
     * 
     * The reason for the conditional test on being at entry to faultISR is that when loading the program, 
     * or reseting the device, the CPU is sometimes halted at an exception and so an automatic attempt
     * to unwind the exception stack can break the debugging. 
     */
    OnHalt()
    {
        if (PC == faultISR_address)
        {
            Unwind_Exception ();
        }
    }
    

    Be aware of the GEL Namespace, about the default order in which names are resolved, if the same name is used for a target symbol and a GEL variable.

    Ed Sanders said:
    Is this one of the pages which will be taken down at the end of the month?

    Not as far as I know. It is the https://processors.wiki.ti.com pages which are being retired, and content has been moved to pages under https://software-dl.ti.com which is being maintained.

  • More good info.

    Thank you Chester.

    Ed

  • Hi Pramod,

    The experiment worked.  I am able to load a GEL script which allows me to unlock the unit and debug.  More in a new thread...

    Ed