TMS570LS0432: mC entering into dabort file and not reaching to main

Hi,

Looks like it is a CCS issue. It is working fine with an earlier version of CCS. But not with the version 9.2. It should be some settings issue.

Kindly guide me.

Also, kindly let me know how I can resolve the .bss exceeding available memory issue.

Regards,

Navin

Hi Navin,

Do the power on reset and erasing the whole flash help?

If any ESM group3 errors occurs, the nERROR pin outputs low. A power on reset or a write of 5h to ESMEKR is required to release the ESM error pin back to normal state. If this error is not cleared, the code will get stuck in sys_startup.c (if you use HALCOGen generated startup.c).

Hi Wang,

Thanks for the reply. I am getting the below error on power on RESET during debug session. Kindly let me know.

Dap: Error: (Error -242 @ 0x0) A router subpath could not be accessed. The board configuration file is probably incorrect. (Emulation package 8.1.0.00007) 

CortexR4: Error: (Error -2063 @ 0x0) Unable to reset device. Power-cycle the board. If error persists, confirm configuration and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 8.1.0.00007) 

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 8.1.0.00007) 

CortexR4: Unable to determine target status after 20 attempts

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

Regards,

Navin

Also, Only one particular Blinky program is getting loaded through an earlier version. Other code especially with OS is looping inside dabort, invects, etc files . It is not specifically going into startup.c.

Regards,
Navin

Hello Navin,

It looks like the code you programmed is making the part enter an exception state repeatedly. This prevents the CPU from entering a debug state, resulting in the behavior you observe. You need to try to erase the part, assert and release nRST to see if the erase command is able to halt the CPU and erase the flash.

Please try this procedure to let CPU enter a debug state:

1. Open the target configuration window, and launch the selected the configuration
2. Switch to debug window
3. Press the reset (nRST) button and hold it
4. Click “Connect Target” immediately after you release the nRST button
5. The board should be connected after couple tries

Hi Wang,

When I follow the steps that you mentioned. I get the below message. The program goes to this location & stops.

Break at address "0x5584" with no debug information available, or outside of program code.

Regards,
Navin

When I try to read the DAP or Icepick memory through memory browser.

For IcePick, it gives me this error. Is there a hardware failure with this device. If so, what could be the cause of it. Can a certain code load (even with wrong linker cmd file) cause hardware damage?

IcePick: Trouble Reading Memory Block at 0x59b8 on Page 0 of Length 0x160

Regards,

Navin

Hello Navin,

Does this mean that target is connected through JTAG, but there are still some problem when reading memory through DAP and icepick? Can you erase the flash? 

This is useful link for troubleshooting JTAG connection:

http://software-dl.ti.com/ccs/esd/documents/ccsv7_debugging_jtag_connectivity_issues.html