TM4C1294NCPDT: Trouble Reading Registers (Error -2030) When Debugging via XDS560v2 (CCS 10.3.1)

I do not see a reset button on either of my JTAGs. If you are referring to the uC, looking at the schematic, it looks like we tie !RST high, so there is no way to toggle it low. 

Edit:
I see there is a !RST on the JTAG connector. We could pull the !RST pin on the uC low via the JTAG

Also, I have three total boards, and both of the boards I have tried result in this issue.

Hello Paul,

You will need to toggle the RESET pin somehow, having it tied high isn't recommended for a design as there are important cases to toggle it like this one. If the JTAG reset isn't connected to the MCU reset pin that probably won't help - that part of the connection isn't clear to me.

If the board locked up due to a software error its likely to occur on every board running the same software.

If you have a fresh board that hasn't had software loaded and the tools work with it, that'd point more to the TM4C MCUs got into a locked state.

Best Regards,

Ralph Jacobi

To be clear, !RST is connected directly to the JTAG connector. However, it has a 10k pullup for when the JTAG is not connected. 

Based on the instructions in the document you linked to, I need to toggle this line. But this is already part of the JTAG connector. So I need to install a button between the JTAG and the uC? Because the !RST signal is already controlled (or at least part of) the 10-pin JTAG connector that we use. I would think that the JTAG itself should be able to control that pin. 

I have three boards that have different software statuses. The one I have been developing on has current software on it. Board two has an old version of software on it, not sure how old. Board three has no LED activity, so I think the uC has no code on it. All three boards fail to debug in a similar way. 

Board 3 gave an error of

Trouble Removing Breakpoint with the Action "Finish Auto Run" at 0xbe58: (Error -2030 @ 0xF) Attempted to access an unknown or invalid register. Confirm the register is valid and accessible, and retry the operation. (Emulation package 9.3.0.00058)

I am not in a position to modify this hardware currently. Is there another avenue I could explore? 

Hello Paul,

Since you believe one of the boards has no MCU firmware, then maybe the issue is not related to a device lock up. I will see if the Tools experts have any insights they can offer for a root cause that could differ from my initial guess.

Best Regards,

Ralph Jacobi

Hi Paul,

MML CHLK said:

I used the config utility provided by Blackhawk, and my XDS560v2 passes all tests. It and the XDS200 also pass the connection test in the debug configurations menu in CCS, so I think my hardware is fine.

Based on the above, we can confirm that the debug probes are fine and low level JTAG communication between PC <-> probe <-> device is fine. The issue is higher up at the device level, usually an issue with the device state or some configuration issue. It is odd that everything was working fine and then all of a sudden the issue occured.

Few other troubleshooting tips to try:

Deleting target cache files: https://software-dl.ti.com/ccs/esd/documents/users_guide/ccs_troubleshooting.html#delete-target-cache-files

Using a new workspace folder.

It may be also be a good idea to try updating your CCS version to the current latest (12.1)

Thanks

ki

fsclean did not help, nor did using a new workspace. I will see if installing the new version of CCS is possible. That will likely take some time. Thanks for your suggestions.

MML CHLK said:

I will see if installing the new version of CCS is possible

Please let us know how it goes. I'm not sure if the updated CCS version will help. But it is always easier for us to debug an issue if you are using the latest version of the tools.

Thanks

ki

alright, I just managed to get CCS 12.1.0 installed. I tried to debug three times, and got the same list of errors. I made sure to check my family of processors (TM4C12X or something similar) and both SD and Blackhawk debug probes during installation. 

Paul

Thanks for trying. 

hmm... I seem to be out of suggestions. If I recall correctly, you are working with custom boards. Do you perhaps have a TI board like a LaunchPad that you can test with? 

Yes, I am working with custom boards. 

Actually, I am able to borrow a launchpad with the same uC on it. 

I tried to debug three times. Each time, I got the "Trouble Removing Breakpoint" / "Finish Auto Run"  -2030 error. However, each time, I pressed resume anyway, and the code seemed to run. The only reason I think it's running is because if I pause, it is sitting in a I2C state machine waiting to send some data. I have never used this launchpad before, but I assume it has a different or absent I2C connection, so it makes sense that my peripherals would not work. I will look into it shortly and edit my post if I find anything relevant. 

edit: the I2C pins that I am using lead to the unpopulated X11 

I added a printf statement near the top of my code and tried to debug a fourth time. I got the usual "Trouble Reading Register REG_ENDIAN" -2030 and then one "Trouble Reading Register SP" -2030 error, but again the code seemed to run after resuming a third time, and I was able to suspend and see that I was waiting at the I2C section of the code again. However, I saw no console output as expected from my printf. 

Not sure what to make of all this. And I will say, it feels random which error I get. Different text but always -2030 it seems. 

MML CHLK said:

Actually, I am able to borrow a launchpad with the same uC on it. 

I tried to debug three times. Each time, I got the "Trouble Removing Breakpoint" / "Finish Auto Run"  -2030 error.

Just to confirm - this error occurs on a target connect (before any program load)? Or is it after you loaded a program and ran it?

Yes, on a target connect. I could be wrong, but I thought the program is loaded at that point, but not yet executed. To be clear, here is the process:

1. press debug
2. a couple progress bars complete
3. The debugger halts at main, and the console output has a GEL Output:, "Memory Map Initialization Complete," and Trouble Reading Register/Trouble Removing breakpoint -2030 error
4. Pressing resume results in 1 additional error per press on the custom board OR either (one additional error on first press and then code execution on second press) or (code execution on first resume press) on the launchpad
5. (launchpad only) code is running, I can pause and see that I'm waiting in I2C code, but the debug session is still messed up because there is no console output (besides the above) as there should be (printfs)

Based on the above, youa re doing a project debug session.

Pleasse try a project-less debug session - also known as a manual launch:

https://software-dl.ti.com/ccs/esd/documents/users_guide/ccs_debug-main.html#manual-launch

With a manual launch, the debugger will be started but remain disconnected. You will need to manually connect the target. Please check to see that these two steps occur without issue.

I remember trying this before with no dice. The process isn't clear to me though so let's walk through it.

Step 1 option 1, my CCS has no option "Launch Selected Configuration."  I can hover Debug As and then Either "1 Code Composer Debug Session" or "Debug Configurations..." The former seems to launch as usual and has the same result. The latter brings up a Debug Configurations window. I only have one debug configuration so I just select that one and press Debug, and again it seems no different than normal. 

The other step 1 option ("Double-click on the desired target configuration file to open the Target Configuration Editor and click on the Debug launch button)"  has the same result as usual.

So manual launch is no different it seems, if I'm doing it correctly. 

MML CHLK said:

The other step 1 option ("Double-click on the desired target configuration file to open the Target Configuration Editor and click on the Debug launch button)"

Actually I'm looking for you to try something like the below video:

Ki said:

below video:

NOte the video can be enlarged when double-clicked.

Thanks a lot, this was much more clear.

I tried it with both probes on the launchpad. Both had the same result in that I could connect and run with no error codes. However, there was still no console output in CCS, and pausing the debug resulted in the same window as in your video in that I could not see any code ("no debug information available, or outside of program code."). 

Next, I tried the XDS560v2 on our custom board. It was the same result as on the launchpad, with no errors, yet not really debugging either. The code would run (and the LEDs on the board would blink correctly, and pause correctly when I suspended debugging) yet I could see no console output, suspending would not show where in the code I was, and the Register view could not read any registers. 

MML CHLK said:

However, there was still no console output in CCS, and pausing the debug resulted in the same window as in your video in that I could not see any code ("no debug information available, or outside of program code."). 

The steps in the video only starts a debug session and connects to the target. No program is loaded to the target. No debug symbols are loaded either. Hence you would not get any debug visibility. Hence the message you saw is expected.

MML CHLK said:

Next, I tried the XDS560v2 on our custom board. It was the same result as on the launchpad, with no errors, yet not really debugging either.

Again this would be expected. since no debug symbols were loaded either.

MML CHLK said:

yet I could see no console output

You are referring to the -2030 errors, correct?

MML CHLK said:

suspending would not show where in the code I was

This is expected since no debug symbols were loaded

MML CHLK said:

and the Register view could not read any registers. 

You should be able to see register content however. What do you see in the registers view?