• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 81 subscribers
  • Views 245 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.

TMS320F280049-Q1: F280049 is stuck/locked and cannot be unlocked

Wayne Huang
Genius 14765 points
Part Number: TMS320F280049-Q1

Dear Champs,

I am asking this for our customer.

The user is testing DCSM with their own bootloader.

1.

They found there was something wrong like below fig. when they tested DCSM with their bootloader and they could not take F280049 out of this state or unlock it with the password even if they powered cycle the device.

Do you have any idea why and how they can take F280049 out of this state?

2. In their testing,

If they do not use DCSM and only use their app code and bootloader, everything works.

If they use DCSM and only use their app code without the bootloader, everything works.

If they use DCSM with their bootloader, then it fails and become question 1 above after power-cycle.

Their DCSM is running on secure LSx RAM responsible for bank0 flash erase/program but some of bootloader data .cio/.stack/.ebss are in unsecure GSx RAM. Does it matter?

They only use CSM  Zone 1 for LSx RAM, all bank0, all bank1.

Do you have any suggestion for them to debug for their bootloader?

Wayne Huang

  • 0
    TI__Genius 14765 points

    Dear Champs,

    Here is update.

    Question 2 is solved after the user moved all the bootloader codes onto LSxRAM including .cio/.stack/.ebss.

    However, some boards that were tested earlier using bootloader .cio/.stack/.ebss in unsecure GSx RAM are still in the state of question 1 - that is, it seems the devices are in some kind of low power mode when CCS JTAG is trying to connect it even with WAIT boot mode or even power cycle it.

    CCS asks if the user wants to bring it out of low-power mode.

    After selecting yes, the user see below message, but it does not help.

    We are confused, why JTAG cannot be connected even WAIT boot mode is used?

    In summary,

    would you please help the user with the question 1 above - how to bring the fail devices out of low power mode?

    Or they have to replace the fail devices with new ones?

    (note that the user does not think there is anything wrong with their HW board because before testing their bootloader with DCSM, they confirm everything works well.)

  • 0 in reply to Wayne Huang
    TI__Expert 5130 points

    Hi Wayne,

    When you mention "If they use DCSM with their bootloader, " does that mean DCSM zone is configured and the PSWD has been modified as shown in the first snippet? If yes, then I would suggest modifying in the GEL file the new modified CSMKEY and give it try and see if you are able to connect to the JTAG.

    Wayne Huang said:
    Their DCSM is running on secure LSx RAM responsible for bank0 flash erase/program but some of bootloader data .cio/.stack/.ebss are in unsecure GSx RAM. Does it matter?

    This should not matter as the data flow here is from a secure memory (LSxRAM) to the unsecure memory(GSxRAM) and that should go through just fine. Please try the above suggestion and get back to see if your issues are resolved. Let me know in any case.

    P.S: I'll be out on Timebank till 1st Dec and would request you to kindly await for further responses till I am back.

    Thanks & Regards
    Pramod

  • 0 in reply to Pramod P
    TI__Genius 14765 points

    Dear Pramod,

    Do you mean to ask them to modify the 

    C:\ti\ccs1210\ccs\ccs_base\emulation\gel\f280049.gel?

    And modify the CSMKEY directly in below function?

    hotmenu SetupDCSM()
    {

    GEL_TextOut("... DCSM Initialization Start ... \n");

    ....

    GEL_TextOut("... DCSM Initialization Done ...\n");
    /* Write passwords to the KEY registers. 0xFFFFFFFF's are dummy passwords.
    User should replace them with the correct password for their DSP */

    *(unsigned long *)0x5F010 = 0xffffffff;
    *(unsigned long *)0x5F012 = 0x47FFFFFF;
    *(unsigned long *)0x5F014 = 0xFFFFFFFF;
    *(unsigned long *)0x5F016 = 0xFFFFFFFF;

    *(unsigned long *)0x5F050 = 0xffffffff;
    *(unsigned long *)0x5F052 = 0xe3FFFFFF;
    *(unsigned long *)0x5F054 = 0xFFFFFFFF;
    *(unsigned long *)0x5F056 = 0xFFFFFFFF;

    }

    However, you can see from above error messages, it cannot even run OnTargetConnect()...

    And you can see there is no "GEL_TextOut("... DCSM Initialization Start ... \n");" running...

    That is, there is something wrong before DCSM checking...

  • 0 in reply to Wayne Huang
    TI__Expert 5130 points

    Hi Wayne,

    Yes. Please modify the CSMKEY with the programmed password in the GEL file and give it a try. Kindly check if there is any other place in the GEL file where this register is being written. Also, please ensure that there are no other additional writes to the CSMKEY registers in the GEL file (as part of other custom functions).

    There could be multiple reasons why the messages on GEL file may not be coming. We'll get into that after this experiment.

    Also, please send across a snapshot of the DCSM register space and te DCSM OTP space to see what maybe causing the issue.

    Thanks & Regards
    Pramod