TMS570LS3137 Debug Session Stuck

Casey,

This just means an error flag is set.   Some of these flags are not cleared by a warm start reset (only a power on reset will clear them all).    The reason is that you may want to know the source of the last reset.

Or alternatively there may be something in the way the device is programmed that causes a flag to be set systematically on every startup.

Knowing the actual value of esmREG->SR1[2] aside from it being nonzero will tell what the issue is.

Now which register to read?   Well esmREG->SR1[2] isn't so obvious but look at the header file:

typedef volatile struct esmBase
{
    uint32 EEPAPR1;           /* 0x0000                 */
    uint32 DEPAPR1;           /* 0x0004                 */
    uint32 IESR1;             /* 0x0008                 */
    uint32 IECR1;             /* 0x000C                 */
    uint32 ILSR1;             /* 0x0010                 */
    uint32 ILCR1;             /* 0x0014                 */
    uint32 SR1[3U];           /* 0x0018, 0x001C, 0x0020 */
    uint32 EPSR;              /* 0x0024                 */

It's offset 0x001C  which in the technical reference manual is shown to be ESMSR2

But the TRM just lists this as a bunch of flags - the key is that they correspond to the Group 2 of ESM inputs.

The device datasheet lists what these Group2 errors all are:

So for example if you see bit 4 set this means there was an uncorrectable error detected in the flash by the flash module controller (FMC)...   That's an example -- you need to find out which bits are set in your particular case and use the table above to decode their meaning.

-Anthony

this is happening right after I load the code with CCS for debug - its hit and miss with the XDS100 and worse with the XDS200 - so the problem is the tools. What does it buy me to know the failure, I cant control the flash download to debug process
I want to reliably load code to debug without this error occurring

No, it's not an problem with CCS that I can tell you.

You're getting stuck with some diagnostic. You need to know which one it is by checking the code then we can figure out how to address it.

CCS doesn't manage these for you. If your code creates the fault it just helps you debug the problem by letting you see what is going on and by reading the fault status. But it doesn't try to fix or hide the fault from you.

And the code you've got loaded is just the emply template w.o. anything to handle the fault, that's why the 'while(1) is there...'

for(;;)

{

}/* Wait */

You're supposed to replace this eventually with some code of your own to handle the fault, but how you handle it is going to depend on the needs of your application / system. That's why we leave these stubs there for you to fill in.

Hope that explains it better.

the code is not reaching main. it does not stop at main like it is supposed to after a code load
- how can it be my code creating the fault? - it has not run yet - I assume only the TI init files have run so far

Yes I understand.  

However, you have to consider that this is not a problem with the debugger and so you need to look elsewhere if you want to solve the problem.

Why?   The debugger is not responsible for getting you to main().   It might instruct the core to run from a reset and halt when it reaches main() but if the startup code doesn't always reach main...  which is definitely the case as you can see... this isn't a problem with the debugger or the XDS hardware.

[for example the path from c_int00 to the  'for(;;)' is one path that doesn't ever reach main()].

Ok so then it comes back to this:  we need to understand which ESM error is being detected.    If it is something like an ECC error we need to check your build and programming setup to make sure it's configured to match your device.    

the code is getting stuck at

/* Check if there were ESM group3 errors during power-up.
     * These could occur during eFuse auto-load or during reads from flash OTP
     * during power-up. Device operation is not reliable and not recommended
     * in this case.
     * An ESM group3 error only drives the nERROR pin low. An external circuit
     * that monitors the nERROR pin must take the appropriate action to ensure that
     * the system is placed in a safe state, as determined by the application.
     */
    if ((esmREG->SR1[2]) != 0U)

reading the value of esmREG->SR1[2] it returnsx 00000080....which is a reserved bit?

Steven,

Sorry I missed that last question - Casey ping'd me on it.

It is weird that it's a reserved bit.  Let me check that it's not something undocumented.

Steven,

My mistake.   The indexing is 0 based so esmREG->SR1[2] is actually Group 3.

And 0x80 is FMC uncorrectable error bus 1 and bus 2.

I'd look at your ECC generation and programming as a culprit for this.

-Anthony

This is happening when i first invoke CCS to go into debug - and hangs before I get control of the debugger - what ECC and programming could I have changed to cause this?
again this is BEFORE I get to run any of my code

Steven,

First, you need to understand that you're not 'hung'.   The software is just entering a for(;;) loop and it occurs prior to reaching main().   So you likely have the default debugger configuration of 'Auto Run' 'On a program load or restart' to 'main'  [there is a config window where you can change this behavior but you don't really need to... ]  

The point is this problem seems totally debuggable.   You should be able to issue a system reset, find the PC at the reset vector c_int00, and single step right into that for(;;) loop.  

Anyway,  how do you have CCS configured to 'flash' ?    If it's like this below from my setup then you've got Auto ECC Generation disabled and we should look at your linker command file.

Also what does your HalCoGen config look like under "SAFETY_INIT"? 

Some of these checkboxes actually create errors so that you can self-test the error detection mechanism.

Maybe not the place to go right away if you are just getting started w. this device for the first time...

Are you getting any sort of data or prefetch abort?   [if you put a breakpoint at addresses 0x0C and 0x10 you'll trap any of these..  If you can halt on these locations then the LR value will basically point you at the problem or very close to it...]

-Anthony