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

TMS320F28388S: Error on 28388S processor when trying to run CM after CSM is enabled

Thomas Dombroski
Prodigy 70 points

Part Number: TMS320F28388S

I used the dcsm_security_tool project to generate the dcsm settings for my processor. I set it up so all secure flash and ram (both CPU and CM) are locked in zone 1 and tried running my project. The CPU behaves as expected and I can run the processor both locked and unlocked without issue.

The CM will not run when the DCSM is locked though and my debugger immediately disconnects as soon as I execute this function:

// Configuring CM to run at 125MHz (AUX Raw = 500MHz).
SysCtl_setCMClk(SYSCTL_CMCLKOUT_DIV_4, SYSCTL_SOURCE_AUXPLL);

Once the debugger disconnects, I cannot reconnect unless I put the processor in SCI boot mode. Even if I comment out the line above, the next SysCtl call will have the same effect.

Why would running this function cause this behavior and what do I need to do to work around it? Is this caused by incorrect DCSM settings?

  • 0
    TI__Mastermind 28580 points

    Hi Thomas,

    Can you confirm there's no issues with the CM when you have no security enabled?

    Are you setting a breakpoint at the SysCtl_setMClk function when the issue occurs? If you set a breakpoint in a secured region of memory, the debugger will immediately disconnect. You can prevent this by performing an ECSL unlock in the CCS On-Chip flash tool.

    Thank you,

    Luke

  • 0 in reply to Luke Jones
    Prodigy 70 points

    Yes. If I run with the CSM unlocked, both the CPU and processor initialize/run without issue. When I change the build configuration to release, which keeps the CSM locked, the CM doesn't run correctly. In an attempt to debug the issue, I connected the debugger (which unlocks through a script in the gel file) and ran a dscm lock script before single stepping through my CPU1 main. The memory shows up as all zeros but the symbols still line up with the memory addresses of the function calls. I kept single stepping until I got the the sysctl_setCMClk function and as soon as I executed that, my debugger would be disconnected and I wouldn't be able to reconnect. Although with more testing, it looks like the disconnect would sometimes happen at subsequent CM initialization calls.

    The CM appears to get stuck in 0x1618 – 0x16C4 memory range so I was going to try not locking the CM to CPU and CPU to CM memory locations to see if the CSM is interfering with the communications between the two processors. Is there additional setup steps needed to ensure the CM's secure flash/RAM security settings are initialized when we run the CM?

  • 0 in reply to Thomas Dombroski
    TI__Mastermind 28580 points

    Hi Thomas,

    Can you step into the sysctl_setCMClk function to see when exactly the debugger gets disconnected? Is the location in the code you get disconnected at consistent?

    Do you see different results when the CM to CPU MSG RAM is left unsecure?

    Thank you,

    Luke

  • 0 in reply to Luke Jones
    Prodigy 70 points

    Hi Luke,

    Leaving the CM to CPU MSG RAM as unsecure didn't help with the problem. 

    This is the line of code that was executing when the debugger disconnected:

    HWREGH(CLKCFG_BASE + SYSCTL_O_CMCLKCTL) |=
    ((uint16_t)divider << SYSCTL_CMCLKCTL_CMCLKDIV_S) |
    ((uint16_t)source << SYSCTL_CMCLKCTL_CMDIVSRCSEL_S);

    This is the console output when the debugger disconnected:

    C28xx_CPU1: Error: (Error -1135 @ 0xA611) The debug probe reported an error. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation. (Emulation package 9.6.0.00172)
    C28xx_CPU1: Unable to determine target status after 20 attempts

    When I try to reconnect after this problem occurs I get this error:

    Trouble Halting Target CPU:
    (Error -1156 @ 0x0)
    Device may be operating in low-power mode. Do you want to bring it out of this mode? Choose 'Yes' to force the device to wake up and retry the operation. Choose 'No' to retry the operation without waking the device.
    (Emulation package 9.6.0.00172)

    The only way I have found to connect again once I am in this state is to put the processor in SCI boot mode and then reconnect with the debugger.

  • 0 in reply to Thomas Dombroski
    TI__Mastermind 28580 points

    Hi Thomas,

    Is the function containing this line of code allocated to secure memory? If you perform an ECSL unlock instead of a DCSM unlock in the On-Chip flash tool, do you still see this issue?

    Thank you,

    Luke

  • 0 in reply to Luke Jones
    Prodigy 70 points

    Hi Luke,

    I eventually figured out what was going on with the DCSM. It looks like if you automatically unlock the DCSM on debugger connect with a gel file script, then lock the DCSM, you can step through the CPU1 code and the symbols will line up. This is true even if you are executing from secure memory (you are not disconnected as soon as the DCSM is locked even though you are debugging secure memory). Our CPU code would reset the CM and as soon as that happened the debugger was disconnected and could not be reconnected. The thing that confused me is the fact that I was not immediately disconnected when the DCSM was locked. I am assuming the lock was not actually applied until the CM reset occurred (even though all of the memory was zeros in the memory browser). I am just going to mark this as resolved.