• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 82 subscribers
  • Views 131 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.

C2000WARE: F28002x chip in-circuit debugging configuration: how to configure without erasing flash.

dd sss
Prodigy 10 points

Part Number: C2000WARE
Other Parts Discussed in Thread: TMS320F280025C

Problem: When customers use the 28002x product, they encounter program runaway issues. Using our company's host computer software, it was confirmed that only the bootloader (a private bootloader written after address 0x80000) exists in the chip. Rewriting the APP portion with the private bootloader allows it to work normally again. Currently, it is unclear whether the issue lies with the private bootloader, the APP portion, or the chip itself.

Now, there is a faulty device. I want to only connect to the board via emulation (debug probe) to inspect which part of the code in the flash is problematic. Previously, I tried following configuration tutorials, but each time I connected via emulation, either the flash got erased, or if connected without erasing, I couldn't view the data in the flash. Do you have standard operating instructions for this? P.S. The project has DCSM passwords configured, but normal emulation erase/write operations can successfully program the chip, so this should not be a hindrance.

  • 0
    TI__Mastermind 20380 points

    Hello,

    What memories did you secure with the DCSM with the GRABRAM/GRABSECT register? If you didn't program these registers and kept as default (all 0xFF), then the flash/RAM will not be accessible when the zone is locked. Please execute the CSM password match flow if this is the case.

    As detailed by the TRM:

    Best,

    Matt

  • 0
    Prodigy 10 points

    Hello Matt,

    Thank you for your help. The DCSM encryption module has already been configured in CCS; otherwise, I wouldn't be able to perform normal emulation. I configured CCS according to the manual (based on my understanding, when not programming the flash, CCS should also read my password from the TMS320F280025C.ccxml configuration, because once the flash has been OTP-programmed, it's encrypted, and it cannot be processed without decryption). However, when I run the emulation (Load symbol only), the data in the flash still shows as 0. Below are my configuration screenshots. Could you help review if there is anything else that needs to be adjusted? Thank you.

  • 0 in reply to dd sss
    Prodigy 10 points

    Sorry, I forgot to attach the screenshots earlier.

  • 0 in reply to dd sss
    TI__Mastermind 20380 points
    dd sss said:
    I configured CCS according to the manual (based on my understanding, when not programming the flash, CCS should also read my password from the TMS320F280025C.ccxml configuration

    Do you mean that you changed the CSMPSWDs in the GEL file in CCS? 

    The issue most likely is due to the CCS GEL file issuing a reset to the DSP when the emulator connects. I recommend either:

    • Follow the steps in Section 6 Non-Intrusive Debug of SPRACF0 to remove the GEL reset call
    • Execute the CSM unlock after connecting again (by modifying the default passwords used by the DCSM init function in the GEL)

    Best,
    Matt

  • 0 in reply to Matt Kukucka
    Prodigy 10 points

    Thank you, Matt. I have configured as per your steps with the GEL file, and the CSM information has also been entered in the GEL file. The current situation is as follows: each time I emulate and program the code into the flash, then disconnect the emulator and immediately perform a Non-Intrusive Debug, I can read the code programmed during the previous emulation (the entire process is done without power cycling). However, after I completely power down and then power up again, when I attempt a Non-Intrusive Debug, all data in the flash appears as 0 again.

    My hypothesis is that when the code was initially programmed via emulation, the CSM was already unlocked. Therefore, performing Non-Intrusive Debug immediately afterward succeeded. But after a power cycle and subsequent Non-Intrusive Debug, it fails because the CSM is no longer unlocked. This is my conjecture. Do you have any better suggestions? Below is my configuration code:

  • +1 in reply to dd sss
    TI__Mastermind 20380 points

    Hello,

    The issue is the following:

    On every reset, the Boot ROM executes a security initialization routine that re-locks the DCSM if the CSMPSWDs are not default. The GEL file also implements a redundant security init function that can be called in OnTargetConnect(). However, SetupDCSM() isn't executed in your GEL file anymore once OnReset() is commented out. 

    You can try the following:

    1. Uncommenting the OnReset() function in OnTargetConnect(). The device will be issued a reset when the debug probe connects (intrusive connect), but this allows the DCSM password match flow to execute in SetupDCSM(). 
    2. Execute the DCSM password match flow writing to the CSMKEY registers in the OnTargetConnect() function.

    Best,

    Matt

  • +1 in reply to Matt Kukucka
    Prodigy 10 points

    Hello Matt,

    After adding the OnReset() function, I am now able to perform Non-Intrusive Debug, and the flash is not erased. Thank you very much for your help over the past few days.