LM4C129DNCPDT not getting to main() using CCS5 and XDS200

Please find next image about debug error attached here

Hello Abhay,

Did you unlock the device using LMFlashProgrammer and Stellaris ICDI on the TM4C129 board and then try the XDS200 debugger? Does that work?

Also what is the run option being set? Is it run to main?

Regards

Amit

Hi Amit,

I'm working with Abhay on this project. It's our belief that we shouldn't need to unlock the Flash using the LMFlashProgrammer, since we haven't taken any of the steps you listed (in another thread) that should lock the flash. We've been using the JTAG interface via CCS.

We are using the "run to symbol: main" in the debug interface.

We waned to ask, is there any other way to lock the flash, which would be available in a normal programming/JTAG session? Is there any way we can tell if the flash got locked somehow, by looking at registers or memory locations? Is there any other problem this could be besides flash locking?

Thanks,

Ben

Hi Benjamin,

     Have you made your custom board to work before? Have you tried to make it work with a simple program, like blink an led at your custom board?

- kel

Hi Markel,

Yes, this is a board that's been working successfully for six months. We've been programming it, using it, debugging it, and then all of a sudden one day it programs, but doesn't go to main.

In addition, here at my site, we have 19 additional boards of the same production run which are currently working just fine.

-Ben

Hi Benjamin,

From your attached picture, there is a Hard Fault are you able to read the necessary registers and debug the Hard Fault?

So, this board needs to go through a Failure Analysis Process, to isolate the cause of this failure.

Say, you have two or more similar boards, and one of them is the faulty one.

Erase all flash of all boards then load the same firmware. Then run for several hours. (In some cases, this is done at a stress environment)

There is no harm in trying the LM Flash Programmer Unlock Utility. You can add that step before "Erase flash".

If the faulty board exhibit the same behavior, then it is possible that there is a hardware problem.

If it is a hardware problem, then troubleshoot your custom board.

- kel

Hi Markel,

I'll have to leave the fault questions to Abhay, the failing board is several thousand miles away from me at the moment. I'm sure he'll answer you tomorrow when he's back in the office.

My problem is, I don't want to erase the flash of the boards, because according to the TI rep above, getting into this state is only possible if you have done 3 things, and we have done none of them. Given the board's previously-working state, and the fact that we don't think we locked it, we're curious about two things:

1) If this is actually the problem

This is why we're curious about other things that could cause similar symptoms, which we can explore without changing the existing state, and...

2) If the flash locking is the problem, how did we get here?

We aren't trying to lock flash, so either it became locked from something we did unintentionally, it became locked as a consequence of a tool issue, or there is some errata or manufacturing defect which spontaneously locked the flash. The latter is our most serious concern.

Hope that helps,

Ben

Feel your pain - perhaps my report will (somewhat) aid/comfort.

While we don't use your device - we have > 7500 Stellaris & ~2K TM4C operating successfully in the field - some in place beyond 6 years.  We've never encountered such issue!  ...(except when vendor's rep visited - (in disbelief of our group's discovery of a PB0 fault on earlier device - later acknowledged {yet uncredited to our group} and vendor's test code improperly {and unwantedly} misconfig'ed PC0-PC3!)

So - indeed those "lock" warnings remain valid.  And - we strongly monitor & enforce each/every access of both, "Port_C"  and, "SysCtlClockSet()" as these are - by far, "most usual suspects" in causing your plight.  We've encountered same over 50 times during client field visits - too often such, "improper access" was denied...  (i.e. I didn't do it - nobody saw me - you can't prove it... {credit one Bartholomew Simpson})

Should yours really be, "Act of God" I'd look very carefully at your (assumed present) external xtal, xtal bypass, and at the presence & correctness of each/every JTAG connection.  (while many such parts claim, "internal pull-ups are acceptable" - we find such advice to be too risky - always insist upon external Rs.)

I'd check the 3V3 regulator and for the signal arrival/correctness of each/every Vdd & Vss pin - your suspect MCU - along w/adequate number of bypass C's.  Reset circuit should be inspected, too.

Our group works w/many ARM MCUs (multiple vendors) thus choose a vendor agnostic "real IDE."  (i.e. IAR our case, Keil also qualifies)  Via use of a free version - and tied w/J-Link - we've been able to sometimes, "read the memory contents" of such a, "locked MCU."  Note: we employ SWD in this role.  You do not need to install IAR to perform such check - from allied firm site, "Segger" - you may download several programs which enable your access of the MCU's contents - when employed w/J-Link.  (possibly w/out J-Link - although this we've never tried)

We've not been told the, last known operating state prior to this failure!  That's always critical info - n'est pas?  If in the field - away from programmers and probing staff - then ESD or similar such gremlin rises in likelihood.  But - if in the presence of programming staff - you know my belief...  (from many past findings)

Perhaps something here registers/resonates - provides a clue...

Hello Benjamin,

One simple thing we do (even with two boards) is to use the last bin file which caused the issue to be put on another board. I generally do not load a bin file from the compile directory but copy it to another directory so that an inadvertent compile does not remove something I wanted to check.

If it was something that was done unintentionally and remaining 19 boards are still working fine, I would suggest unlock using flash erase

Regards

Amit

Amit Ashara said:

...simple thing we do... load the last bin file (which caused the issue) to another board... 

Unfortunately - recent "misfortune" which befell this country's esteemed tax collection branch (total loss of any/all such files/emails) lands in tech-land, too...  Might any such, "incriminating evidence" have perhaps, "left the building?"

Might a better method be - prior to any/all code downloads - run that candidate code thru a, "data filter" which checks for and ALERTS upon detection of PortC and/or SysCtlClockSet() (or any change to either) to insure 2nd set of qualified, "eyes" reads/approves code for correctness?  Or - we can hope/pray...

Hi Markel,

I tried reading hard fault register. I could see that all the bits are zero except resevred bit set to 1.

I tried reloading fresh copy of code from repository and I could not see hard fault again , it goes directly into run mode (though set to run to main), whenver i tries to pause, it has always seen in function ti_catalog_arm_cortexm4_tiva_ce_Boot_init.

Please find the attached snapshot.

Thanks,

Abhay

abhay shinde said:

I tried reloading fresh copy of code from repository and I could not see hard fault again , it goes directly into run mode (though set to run to main), whenver i tries to pause, it has always seen in function ti_catalog_arm_cortexm4_tiva_ce_Boot_init.

I don't know if that is okay. So, consult your firmware guy. Does the same happen to other boards?

So, after reloading "fresh copy of code" the problem goes away.

In this situation I would run the board at a high temp oven for long hours. Set, the oven temp that is recommended for your hardware. I would do this with this faulty board and another or more working board, for comparison. This will help expose any intermittent failures there may be at your faulty board.

If there is no problem after this stress test, then use it for your testing or send it back to customer.

- kel

Hi Amit,

Abhay sent me the .out file here and we loaded it onto another board. This image worked OK and we had no issues debugging afterward. 

If it was something done unintentionally, this worries us because I don't want to be able to lock the flash on fielded units, either via a bug or some other unintentional change - this would obviously have warranty and field-return implications.

Can you tell us, is there a way to check whether or not the flash is truly locked on Abhay's board - WITHOUT unlocking it? 

Can you give us any details on all possible ways we could lock the flash via running a normal program over a JTAG debugger? 

At this point, we want to do everything we can to assure ourselves this problem will never happen in the field.

Thanks,

Ben

Hello Benjamin

You would need to return the part to TI for Failure Analysis. Of course we may resort to destructive testing if we see a lockout issue.

Regards

Amit

Hi,

I tried with sample blinky program which toggles LED. It worked with my board, so definitely flash is not locked and my hardware has no issue.

Then I tried with my original program (which I dint change and was working fine in past). I could see flash getting programmed but after that it directly goes into run mode without halting into main, then whenever i try to puse it, it shows following error message -

CORTEX_M4_0: Can't Run Target CPU: (Error -1268 @ 0x1090001) Device is locked up in Hard Fault or in NMI. 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 5.1.232.0).

Thanks,

Abhay

Hello Abhay

That is good news that the issue is now reproducible. Can you please send the bin image and the CCS project files, so that I can take the investigation and isolate the issue?

Please do mention if there is a requirement for any external hardware for the same?

Regards

Amit