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

TMS320F28379D: TMS320F28379D: Trouble Halting Target CPU: (Error -1156 @ 0x0)

Donovan Sanders
Prodigy 30 points

Part Number: TMS320F28379D
Other Parts Discussed in Thread: UNIFLASH

Hello, I made a similar ticket last night related to this issue, but I think that this could be the root cause. When trying to debug on core 1 while attached to an XDS100v3, I keep receiving this error: " (Error -1156 @ 0x0) Device may be operating in low-power mode. Do you want to bring it out of this mode?"

I have tried several GEL scripts and the scripts appear to run succcessfully given the console output and checking the registers while debugging with symbols only. However, I believe the drive is still somehow relocking itself after this step. I am using CCS 10.4.0 I have double checked my settings to make sure there is nothing about resetting after connecting or programming. But still I receive this error after unlocking both cores.

Additionally, I've used Uniflash 4.5.0.2056 to recover a drive when it has been in this state before. However, uniflash also gives me the same low power error when I try to use the generated batch file. Looking at what its running before the error occurs, it seems to start initializaing things in core 2, then starts initialzaing things in CPU2_CLA1 before throwing the error. I would greatly appreciate some assistance with this. I only select core 1 when I attach on the debug screen, so it is also strange to me why cpu2 is even touched. Thank you in advance.

.........
        Mapping registers: C28xx_CPU2 - XintRegs
        Mapping registers: C28xx_CPU2 - Hidden
        Building search data: C28xx_CPU2
        Applying virtual groups: C28xx_CPU2 - VCU
        Executing Startup Scripts: C28xx_CPU2
        Initializing: CPU2_CLA1
        Mapping registers: CPU2_CLA1 - Core Registers
        Mapping registers: CPU2_CLA1 - CPU2_CLA1
        Mapping registers: CPU2_CLA1 - Hidden
        Building search data: CPU2_CLA1
        Executing Startup Scripts: CPU2_CLA1
Connecting...
error: C28xx_CPU1: Trouble Halting Target CPU: (Error -1156 @ 0x0)...........

  • 0
    TI__Mastermind 20380 points

    Hello,

    Those are startup scripts executed for multi-core devices since UniFlash allows you to debug/program the CPU1 and CPU2 subsystems. In this case, the debugger maps registers, applies script files (GEL), and loads symbols for both CPU2 and its CLA (CPU2_CLA1). The error occurs when you attempt to connect to CPU1.

    Best,

    Matt

  • 0 in reply to Matt Kukucka
    Prodigy 30 points

    Yes, I have setup these debug scripts to unlock both cores and both cores are unlocked when I check the registers but I still get this error when trying to debug. I am saying I am connected to CPU1 yes, but this error seems to possibly be about the CPU2_CLA1 being halted (which I do not use either CLA in my current project). But I have unchecked the settings to keep breakpoints and when I have attached successfully there are no breakpoints set. 

    I wondering why this low power issue still occurs, as I cannot debug the device. I can load symbols only to unlock the drive, but I cannot upload any new code to the device. It seems to act as if its still locked after the unlock occurs using my gel scripts which I see unlock successfully in the console output.

  • 0 in reply to Donovan Sanders
    TI__Mastermind 20380 points

    Hello,

    Can you please put the device in WAIT boot? This will keep the device spinning in the Boot ROM (inherently insecure memory) on reset. Therefore, you will be able to connect to device without the JTAG being interrupted by ECSL protection. 

    Best,

    Matt

  • +1 in reply to Matt Kukucka
    TI__Mastermind 20380 points

    To add on: I confirmed that I could program the flash after putting my device in wait boot and disabling all reset on connect options.

    Best,

    Matt

  • 0 in reply to Matt Kukucka
    Prodigy 30 points

    Hello, I was able to resolve the issue on my end with a different solution without entering wait boot mode. Just wanted to say thank you.  It seems it is something to do with the order of when i do the Link Pointer vs Programming the Password. It only worked when I did clicked program link pointer (which did not change the value), then did program password, then did program link pointer again to get the value I actually wanted and then the value actually changed, I had to do this for both cores in this order. Only after this was I able to use the drive like normal. Do you know why this may be? Even during the link pointer step and even the program password step while on core 1, I keep receiving multiple errors:

    "C28xx_CPU1: Error Occured during flash operation: No core matches the pattern CPU2"
    "Error executing PLL Configuration algorithm. Operation cancelled. (0xAA55AA55)"
    "Error during flash programming (flash algorithm returned error code). Not able to execute program algorithm. Operation can..."
    "Please make sure the memory location you are programming have not already been programmed"
    "Error encountered during security operation. Operation Cancelled."

    Still, even after these errors occurred while I was doing the program link pointer and program password steps, these errors came up in both cases and the operation said unccessful yet I saw the registers change values and eventually saw the LinkPointer change as well. But looking at the registers while the operation is running using continuous refresh in the debug window, i can see the LinkPointer initially gets the default value and unlocks the drive but then the memory errors and keep changing but then eventually the memory settles. It seems to me something keeps running in the background for some reason but I am not sure what. If you have any more information about why this happened with those settings in the on-chip flash for ccs 10.4.0, I would greatly appreciate it. Thank you. 

    Also I am using an XDS100v3

  • 0 in reply to Donovan Sanders
    TI__Mastermind 20380 points

    Hello,

    Given that CCS v10.4 is 5 years old and no longer supported by TI, there may be bugs in CCS or the Flash plugin itself that may be manifesting in this issue. I cannot say exactly what changed since then, the CCS release notes may have more hints.

    Donovan Sanders said:
    t only worked when I did clicked program link pointer (which did not change the value), then did program password, then did program link pointer again to get the value I actually wanted and then the value actually changed, I had to do this for both cores in this order.

    How does this compare to your programming flow before?

    Best,

    Matt