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.

TMS320F28379S: Emulator Cannot Program Flash

Part Number: TMS320F28379S
Other Parts Discussed in Thread: UNIFLASH

Tool/software:

Greetings,

                I am trying to use an XDS100v3 to program a DSP, and an unable to do so.  It tells me that the device may be operating in low power mode which it is not.  We don’t use that capability.  If I configure CCS to not halt the processor, to only load symbols, and use a different GEL script which doesn’t affect the unit, it can connect, unlock the unit, and I can halt the processor, see memory, etc.  So from there, I can read the LPMCR register which is 0x0000FC which is the power up value.  If I change the configuration to add Halt on Connect, it will fail to connect.

                 Other than the LPMCR register, what can cause the emulator to think that the processor is in low power mode?

                 We are using CCS 10.4.0.00006.

 

Thank you,

Ed

  • Hi Ed,

    Have you been able to connect and flash the device previously? Could you try putting the device in wait boot mode? 

    Best Regards,

    Ben Collier

  • Hi Ben,


    In the past, I have been able to connect and flash the device on multiple HW platforms. This is a new HW design which is essentially a new form factor for an existing and working design. I feel that there must be a HW difference, but it is escaping me. In the area of the JTAG, both sets of schematics are identical.

    Yes, I tried Wait Boot Mode with no luck.

    BTW, this happens using multiple copies of the emulator.

    I don’t know if this matters, but in the initial post, I mentioned that I could put the system into a passive mode and only load symbols. Since then I have been working with it, and have found that after running it, and collecting information, if I try to stop it, I will get the same low power fault. If I close the debug session and connect again, it has always succeeded.

    Another clue… The device is running code due to the fact that the initial use of the uniflash files worked using the same type of emulator. And I can update code using our normal code download process.

    When the debugger tells me that it thinks the device may be operating in low power mode, what information is it using to make that assessment?

    Thank you,

    Ed

  • Hi Ed, Ben is OOO, hopefully he'll be able to reply later this week.

  • OK.  Thank you for the heads up.

    Ed

  • Ed,

    Could you try the 'Test Connection' option inside of the menu for the Target Configuration? 

    If that passes, then the JTAG schematic/layout is probably fine. Next it would be good to look at you power rails and XRSn circuit. 

    Best Regards,

    Ben Collier

  • Hi Ben,

    I was able to solve the problem for which I needed the emulator connected.  Unfortunately, because of that, I needed to relinquish the hardware so that others could use it.  So this will need to wait.

    But I did get another clue.  When I added some dummy code at the start of our code to do unlock the DSP, then the intermittent problems went away.

    When I connect and try to burn the flash, our GEL script unlocks the core and does so at OnTargetConnect().  Is that the right place to do it, or is there an earlier place I should be using?

    Thank you,

    Ed

  • Ed,

    But I did get another clue.  When I added some dummy code at the start of our code to do unlock the DSP, then the intermittent problems went away.

    Ok, did you setup any security on this device in the past? 

    Best Regards,

    Ben Collier

  • Yes.  It was locked when it was first built.  Do you think that is why I can't connect and burn the flash?

    Thank you,

    Ed

  • Hi Ed, unfortunately Ben is OOO this week.  He should be able to get back to you early next week.  I appreciate your patience and apologize for any inconvenience.

  • No problem.  I assume this thread will stay alive so we can continue when Ben returns?

    Thank you,

    Ed

  • yes, the thread won't lock until there has been no activity for 30 days.  

  • Hi Ed,

    Could you please take a look at this app note? https://www.ti.com/lit/pdf/spracp8

    You should be able to connect to the device when it is in wait boot mode, unless the device has been permanently locked. Please follow these steps for manually connecting to the device: https://software-dl.ti.com/ccs/esd/documents/users_guide/ccs_debug-main.html#manual-launch

    You should not be able to flash the device until you follow the steps in the above app note for unlocking the device.

    Again, depending on the security you have used, you may not be able to lock the device.

    Best Regards,

    Ben Collier

  • Hi Ben,

    Unfortunately, I fixed the issue we were having, and needed to relinquish the hardware so that others could use it.

    But if I understand the App Note correctly, this is doing what our code would normally do, but before anything else is done?  CCS would then use it to unlock the drive prior to doing anything else with it thus avoiding the errors?

    Thank you,

    Ed

  • Ed,

    CCS would then use it to unlock the drive prior to doing anything else with it thus avoiding the errors?

    This is correct.

    Best Regards,

    Ben Collier

  • Great!  Thank you Ben.  If I get the HW back, I will give it a try.

    Thanks again,

    Ed