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.

Unable to Connect To Target (TMS570LS1227)

Other Parts Discussed in Thread: TMS570LS1227, UNIFLASH

Hello,

I was using the TMS570LS1227 MCU with CCS v5.4 and everything was working fine as I was able to run a motor through a GUI and load code throughout the day. However, suddenly, without changing anything on the board or its connections, I am now seeing the following error message popup: 

"CortexR4: A fatal error occurred while attempting to remove the remaining debug state that could not be removed at disconnect. This might have occurred because a breakpoint was set at an address that is no longer valid. This behaviour may be turned off in the "Debug Properties" tab in the Customize dialog under the Option menu."

I've tried resetting the board, CCS, disconnecting and reconnecting everything, as well as testing the connection to the board itself by "Launching target configuration" (which failed to connect) for the appropriate version but none of these seemed to do the trick. I tried changing the Debug configurations as well but it didn't change the result. I wasn't able to find any other solution online. Is there something else I can try?

Thank you for the help.

  • It is possible that some corrupt code in the device is preventing the emulator from connecting to the CPU. Sometimes this can be overcome by holding the device in reset and starting the debugger, then releasing the reset. The hope is that the debugger can stop the CPU before it executes code that prevents the CPU from connecting. To verify that it is not a hardware problem, you can connect to each piece of debug logic separately before connecting to the CPU. Try these steps below and let me know at what point if fails:

    1] Start CCS
    2] Open Target Configurations Window.
    3] Right click on your target configuration for your device.
    4] Click on Launch Selected Configuration.
    5] A new window (Debug) should be open.
    6] Right click on the entry in this window and select Show all Core.
    7] Right click on "Icepick" and select "Connect"
    8] Icepick should be connected now.
    9] right click on "DAP" and select "Connect"
    10] DAP should be connected now.
    11] Right Click on Cortex_R4 and select "Connect"
    12] Cortex_R4 should be connected.
  • Hi Mr. Crosby,

    Thanks for the prompt help! I tried both approaches, but holding the reset button while starting the debugger seemed to have the same outcome. In terms of the step-by-step approach, the method fails at step 11. The first error that comes up is the same as I had posted above. But when I try right clicking on Cortex_R4 again and connecting, this error popped up:

    "Error connecting to the target:
    (Error -1265 @ 0x0)
    Device ID is not recognized or is not supported by driver. Confirm device and emulator configuration is correct, or update device driver.
    (Emulation package 5.1.73.0)"

    I tried this process with both configurations available for the device (TMS570_XDS100V2.0ccxml and TMS570LS1227.ccxml[Default]).

    In case it helps with the diagnosis, there is a constant white LED on at D7 (Power) as well as the blue LED at D8 (SPI).

    Thank you,
    Omkar
  • Update: I tried erasing the flash with Uniflash and saw the following errors:

    [16:50:09] FATAL >> CortexR4: Trouble Reading Register SP: (Error -242 @ 0x0) A router subpath could not be accessed. The board configuration file is probably incorrect. (Emulation package 6.0.83.1)

    [16:50:09] ERROR >> CortexR4: Error initializing flash programming: Target failed to read 0xFFFFFFF0

    [16:50:15] ERROR >> CortexR4: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation.

    Does this mean the register location is most likely corrupted and the board is bad? I tested the configuration with another TMS570LS1227 board and everything worked fine on that one.

    Thanks,
    Omkar
  • I think it is likely that the code you programmed into the part is preventing the emulator from connecting. Can you check the nRST pin with a scope? If it is toggling, the device is doing continuous resets. If not, check that the crystal is oscillating.
  • If you can connect with the DAP, there is one thing you can try to regain control of the part. (But it is tricky)
    1. Connect to the DAP as you did earlier, and leave the DAP connection highlighted in the Debug window.
    2. In a memory window enter the address 0x08000000 (start of RAM). The debugger will display the memory by reading it through the DAP without using the CPU.
    3. Change the value at that location to 0xEAFFFFFE (branch to self instruction)
    4. Change the memory window to address 0xFFFFFFC4. You should see 0x0000000A at this location. Change it to 0x00000005. This tells the bus matrix to switch Flash and RAM.
    5. Now write a 1 to location 0xFFFFFFCC. This causes a CPU reset.
    6. Now try to connect to the CPU in the Debug window.
  • Hi Mr. Crosby, 

    I tested the crystal and it seems to have a constant frequency of 16 Mhz as expected, so it doesn't look like the CPU is constantly resetting itself. I wasn't able to find a schematic but from testing the area around the nRST pin, it doesn't look like the signal is toggling automatically, as it only does that when I press the button. 

    As for the second suggestion through the DAP, I got to step 5, but once I hit 'enter' after setting the value to 1, the value at address 0xFFFFFFe4 changed to '29' automatically and this error appeared: "Dap: Error: (Error -242 @ 0x0) A router subpath could not be accessed. The board configuration file is probably incorrect. (Emulation package 0.0.0.0) " This prevented a connection to the CPU from the debug window. 

    I've ordered another MCU control card in the mean time so I can continue development, but was wondering if you possibly had any insight into what in the code could trigger this sort of behavior that blocks emulator access (so that the same thing doesn't happen to the replacement board)? Or would this likely just be a case of a faulty board unit?

    Thank you again for all your help,

    Omkar

     

  • Sorry, I wish I knew what caused this. You might want to replace the reset vector with a jump to self instruction in case it is something in your software. Then the debugger will set the PC to the entry point on a restart, but pushing the reset button will trap the CPU at the first instruction. Of course you will have to replace the reset before you can run without the debugger.
  • Omkar Savant said:
    Does this mean the register location is most likely corrupted and the board is bad?

    Address 0xFFFFFFF0 is the Device Identification Register (DEVID) which is read as part of the flash programming.

    Omkar Savant said:
    ERROR >> CortexR4: Error initializing flash programming: Target failed to read 0xFFFFFFF0

    That error was seen on another thread where a "bad" program was in flash which configured the MPU to disable access to the memory region containing the DEVID.

    Can you try setting the "System Reset on connect" option in the flash settings in either UniFlash and see if that allows the flash to be erased?

    The thread where setting "System Reset on connect" allowed debugging is Target Failed to read 0xFFFFFFF0 

  • Thank you both for the help. Unfortunately looks like setting "System Reset on connect" didn't do the trick either as the following errors came up: 

    [18:12:08] ERROR >> CortexR4: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 6.0.83.1)

    [18:12:13] ERROR >> CortexR4: Unable to determine target status after 20 attempts

    [18:12:13] ERROR >> CortexR4: Failed to remove the debug state from the target before disconnecting. There may still be breakpoint op-codes embedded in program memory. It is recommended that you reset the emulator before you connect and reload your program before you continue debugging

    I have ordered a replacement board and am working on that one now, but as a longshot do you know what sort of bad code could configure the MPU to disable access to the DEVID-containing region? Is there a particular step in the initialization sequence that usually takes care of this issue?

    Regards,

    Omkar

  • Did you find a solution for your Problem?
  • Hi Merlin,

    Yes Bob Crosby's first answer did the trick. Try the reset button approach many times, it's a matter of getting the timing right but it worked. You have to release the reset just after starting the debugger.