TM4C1294NCPDT: FaultISR Not Fixed By Reset?

Hello Terence,

How are you confirming the software doesn't reset? If you land in Fault ISR every time, I don't see how you can confirm the reset button does not reset the software because once you hit the reset button on the board you will break the communication with CCS debug and should not be able to access any debug functionality until you reconnect the debugger when re-downloading software.

Hi Ralph - Thanks for your quick reply. In the main loop of my software I toggle the PN0 LED every second or so. When pressing reset after the fault ISR I fail to see the LED blink. Where in any other state of the software, pressing the reset button restarts the software just fine and the LED blinks indefinitely as expected.

To explain farther: I'm using LWIP with the ethernet controller on the Tiva board to communicate with the board through a test application I wrote that runs on a PC. I added a feature to the test application to allow the user (me) to press a button on the test application to send a message to the board to test the fault handling. When the board receives this message it simply runs the single line of code I posted in my previous message. At this point the code enters the FaultISR.

Ralph Jacobi said:

If you don't trigger the FaultISR does the code run correctly every time you assert reset?
 

Correct

Ralph Jacobi said:

It is possible to connect the debugger without downloading the code in order to load the out file as a symbol file to see where the code is getting stuck, so that should be the next step.

Details on how to do this are covered here (I think all steps exist in the latest CCS as described): e2e.ti.com/.../1465314

Okay.  I've followed the instructions at the link you've given.  I created a new target configuration.  When I launch it, nothing happens except the Console window displays:

CORTEX_M4_0: GEL Output:
Memory Map Initialization Complete

The next step of the instructions state: "Once done, right click the core and select Connect target". 

I'm not sure what this means.  Is there a core dump file somewhere???  I've looked through the file system and I'm not finding one.

Hello Terence,

When you Launch the Target Configuration, you should get a Debug window like this:

If using a LaunchPad like myself, then you would right click the Stellaris ICDI and that gives the "Connect Target" option.

From there you can use the Save Memory feature to save both Flash and RAM contents (you will need to refer to your .cmd file for start address and word lengths).

Thanks, Ralph.  That makes sense and I'm able to click "Connect Target" after launching.  I still need to load symbols though.  I understand I can go to the "Run" pulldown menu and select "Load Symbols" and select the .out file for the build that is running, however, I'm not sure what to enter for code offset and data offset values as shown in the image below.  Any idea where I can find that info?

Hi Terence,

While looking into this further I learned something I didn't know about with accessing the device via the Target Configuration, so we actually have a much more useful means for initial debugging available...

The Registers view will display all the current register settings for the device, which is useful because now we can actually work along the lines of our Fault detection documentation: www.ti.com/.../spma043.pdf

Can you read through the document and see if you can identify if there is any faults occurring? I would even try and see if you can observe your forced Fault in CCS debug and view the registers and then compare those registers to when the Reset issue occurs and if you are hitting the same Fault then that would mean somehow the code is triggering it without your message being sent! Also while you go through possible Fault sources, please keep in mind as reading that any steps which mention using the Disassembler won't be usable as we won't have access to that feature due to not being able to use the debugger when the error occurs.

I don't want to leave my other thoughts completely abandoned so let me speak about the prior idea which for now we can bench unless the Fault app note isn't enough.

First off, when re-reading through all of what was posted in the older E2E post, I am not sure now that Amit's comment which I re-communicated about 'load symbols' was appropriately descriptive of what we want to do - what we really are seeking is a memory dump more than anything and 'load' is a term typically used in the context of downloading TO the device, not FROM.

Let me elaborate in much more detail what I was aiming for:

Using the Save Memory feature, you can download the code contents as TI Data. This will be raw data without any debugger info, so just address & data, but that will still be useful.

What we want to do with this data is try to find out if the code execution after hitting the Reset button when the FaultISR condition occurs ends up placing the Program Counter into 'no man's land' or some other critical flaw.

To do this, the next step would be to run your code in debug mode and hit the FaultISR as desired. Then we would memory dump that as well.

At that point we could diff the two files and see what changed when the Reset issue occurs, though some of that would be manual work such as tracing down specific addresses etc. by using the CCS debug view to make sense of the first raw data file that has the error behavior within it. It's not exactly a pretty method, but when the debugger can't track the issue, suddenly we are left with archaic methods.

The fault debug method is going to be far easier than what I was thinking though, please try that method first and let's try and save full memory dumps as a last resort.

Hi Terence,

Glad you found the issue! I learned a lot too so it was beneficial for both sides haha. I actually wanted to share one more debug technique I learned of late yesterday regarding what to do for issues when you need to see changes to registers after hitting the Reset button.

You can disconnect from the core before resetting so you don't trip up the debugger, and then re-connect after resetting to see the register changes. In other words: connect to target, load firmware, run, hit fault, and then you would disconnect from the target, issue the reset with button press, and then finally reconnect to the target. Now you would be able to see what register settings changed. Hopefully that is also a useful technique for you!

I will mark your prior post as the one for thread resolution.