CCS/TM4C1297NCZAD: Debugger goes away when I execute this code. Can't Run Target CPU; Error; Unable to determine target status after 20 attempts.

Hi Mark,

Mark Sheats said:

Now I am able step along for some distance until I get to the code in the first screen shot.  Once I press F5 again, it goes away, and I no longer have any control of the debugger.

Instead of running, can you continue to single step past that instruction?

Thanks

ki

I thought I was already single stepping, but I was able to refine it a little more.  F5 is "Step Into", and that's what I was using.  Now I have tried Ctrl+Shift+F5 (Assembly Step Into), and I was able to go farther, quite a bit farther.  I branched into some other code I don't have source for, and in the screen shot below, the next instruction in Assembly causes me to lose control of the debugger.

Just to be clear, after that it runs our program. Our instrument becomes completely functional, but I can no longer debug.

Sorry, yes I was asking about asm step into.

Can you show me a screenshot of your debug view when you step past that last asm instruction? Actually you can provide a screenshot of your entire CCS IDE.

Thanks
ki

Okay, here are a couple screen shots.  Hopefully this helps.

Is it possible that there is anything wrong with configuration on my laptop, or the actual installation? I would think it's not likely, since it's so repeatable on where it goes away. Someone else in the company is able to run the debugger with the same code and watch variables changing while the program is executing.

For some reason, the debugger loses debug connectivity to the target at that point. This causes the debugger to disconnect from the target. Hence you lose debug visibility. Have you tried reconnecting? I have a feeling that will not work due to the original debug connectivity issue that forced the disconnect in the first place. But curious what would happen.

You mentioned that a colleague is able to run the the same code and debug past the point you lose connectivity. Are they using the same target board you are? If not, can you have them try the same exact HW on their PC?

Thanks
ki

That's right, I am not able to connect again. The only thing I can do is use the red square to stop the debugger interface. My colleague has not tried to help me with this issue yet, but I have used his exact hardware on my system, and I still see the problem on my system, while he does not see it on his.

Interesting. Can you reproduce the issue with debug server logging enabled? Attach the generated log to this thread:
processors.wiki.ti.com/.../Troubleshooting_CCSv7

Note the below warning found in the link above:
"Logging data from the debugger can get very large, so it may be desirable to only enable debug server logging just before the event of interest is being exercised."

hence you may want to enable logging right before the next asm step that causes the issue.

Thanks
ki

Debugger hangs, test 1.logOkay, I was able to  reproduce the issue with debug server logging enabled and I am attaching the log file.

Note that one difference between the other developer and me may be that we are using different CCS version.  As I stated above, I am using 6.2.  Soon I'll try to get from him what he is using.  Another colleague is using version 7, and I think is having better success than me.

Debugger hangs, test 2.logI did a second test.  This time I enabled it a few instructions before the problem would occur, and this time maybe it ran longer.  The file is larger.

One more note of interest.  When I first tried to connect to my target, I could not connect at all.  I removed the cable from that USB port and plugged it into another one, and then I was able to at least connect.  The debugger would still hang at the same point.

Thanks for all your help!

Is there any issue with register R0 & R3 values, as compared with the linker command file memory limits?

Is it possible that my build is faulty?  The difference between my machine (not working) with 2 other coworkers' machines (working) is that I am building on my machine, and they are building on theirs.  I have tried their hardware on mine, etc.

Mark Sheats said:

Is there any issue with register R0 & R3 values, as compared with the linker command file memory limits?

Based upon the addresses, the program is trying to write to the GPIO Direction (GPIODIR) register of GPIO Port B.

Given that the source statement on which the problem occurs is ROM_GPIOPinTypeGPIOOutput (GPIO_PORTB_BASE, GPIO_PIN_6); the addresses are expected.

Mark Sheats said:

Before I was getting these messages:

CORTEX_M4_0: Error: Debug Port error occurred

CORTEX_M4_0: Trouble Halting Target CPU

How is the system clock configured?

The reason for asking is that can provoke a "CORTEX_M4_0: Error: Debug Port error occurred" program by over-clocking the CPU by passing external crystal frequency to SysCtlClockFreqSet() call to be lower than the actual crystal frequency which then causes SysCtlClockFreqSet() to set the CPU clock frequency greater than the maximum allowed.

Here is where we set clock frequency and initialize other things:

ui32SysClock = SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ |
SYSCTL_OSC_MAIN |
SYSCTL_USE_PLL |
SYSCTL_CFG_VCO_480), 120000000); // Run from the PLL at 120 MHz.
PinoutSet(); // Configure the device pins.
Kentec320x240x16_SSD2119Init(ui32SysClock); // Initialize the display driver.
GrContextInit(&sContext, &g_sKentec320x240x16_SSD2119); // Initialize the graphics context.
TouchScreenInit(ui32SysClock); // Initialize the touch screen driver.
TouchScreenCallbackSet(WidgetPointerMessage); // Set the touch screen event handler.
SysCtlPeripheralEnable(SYSCTL_PERIPH_UDMA); // Configure and enable uDMA
Delay_ms(500); // delay for 500 ms
uDMAControlBaseSet(&psDMAControlTable[0]);
uDMAEnable();
TouchScreenInit(ui32SysClock);
TouchScreenCallbackSet(WidgetPointerMessage); // Initialize the touch screen driver and have it route its messages to the widget tree.


Remember that two other people in the company are able to debug successfully with the same target hardware and code. It's only me having trouble with debugging--something on my laptop may be different. One colleague thinks it may have to do with boot.asm being different on my machine.

Mark - thanks for the logs. I will get them sent for analysis

Mark Sheats said:

Remember that two other people in the company are able to debug successfully with the same target hardware and code. It's only me having trouble with debugging--something on my laptop may be different. One colleague thinks it may have to do with boot.asm being different on my machine.

I recall that you were using CCS 6.2.0 while one of your colleagues was using 7.0. Did you ever find out what version your other colleague was using?

Thanks

ki

The original developer's version of the compiler is TI v5.1.1. He always said he was using CCSV5.5, but I downloaded 5.5 and installed on my laptop, and I was not able to open his project. I was able to open it with 6.2.

Another colleague is using compiler 19.6.0 STS (under CCSV7), and he is also able to debug well, not stopping where I stop.

The write to Port B, pin 6 is where it fails on my system, and this is the instruction to turn on the touch screen LCD display on our system

The error always occurs at exactly the same instruction.
The debugger steps through many instructions to get to that point without any issue.

Could it be there is not enough power to run the display? Could that cause an issue with the JTAG pins? We believe power to the board is more than adequate.

I have both CCSV6 and CCSV7 on my laptop, and I'm getting the same result.

Mark Sheats said:

Another colleague is using compiler 19.6.0 STS (under CCSV7), and he is also able to debug well, not stopping where I stop.

Did you try taking the *.out file your colleague built and loading it in your environment (do not rebuild it)? If you have not ,can you try?

Mark Sheats said:

The write to Port B, pin 6 is where it fails on my system, and this is the instruction to turn on the touch screen LCD display on our system

The error always occurs at exactly the same instruction.
The debugger steps through many instructions to get to that point without any issue.

Could it be there is not enough power to run the display? Could that cause an issue with the JTAG pins? We believe power to the board is more than adequate.

Since your colleague is using the same HW setup, that rules out issues with the target power supply. What is the debug connection? I see in a previous screenshot that you have a Stellaris ICDI connection. Are you using some kind of Tiva development kit with integrated ICDI connection (like DK-TM4C129x) or is this some custom board using an ICDI? Also are you connected to the target via USB port from a USB hub?

Thanks

ki

My colleague is now gone for the day, but perhaps I can try tomorrow.  Is it only one file I need to bring over from his machine?  Drop it into the same directory where my output files go and overwrite it?

I have provided some pictures of my test setup.  It's a direct USB connection to my laptop.

Please feel free to comment on any aspect of this setup and recommend improvements.

Thanks again for all your work on this.

Yup, that looks like the DK-TM4C129X connected directly to your (ThinkPad?) laptop using a standard USB cable using the integrated Stellaris ICDI connection. 

That all looks good when looking at your pictures.

Mark Sheats said:

My colleague is now gone for the day, but perhaps I can try tomorrow.  Is it only one file I need to bring over from his machine?  Drop it into the same directory where my output files go and overwrite it?

yes, you just need to take his *.out file. You can overwrite your existing one. Well, I recommend you back up your existing one first.

I recommend doing a manual launch of the debugger, connect the target, and explicitly load the *.out file from your colleague.

Please let me know how this goes

Thanks

ki

Good eye on the laptop type. I copied over the *.out file and looked at the instructions. The instructions don't relate the *.out file to running. How do you get the new Target Configuration to show up as available? (Have to run to a status update meeting now.)

I had a similar looking ThinkPad and docking station for a few years so I recognized it.

What do you mean when you looked at the instructions? Are you referring to the asm instuctions not being what you expected - his code is different?

Regarding the Target Configuration view, there is a short video that may clear things up:
dev.ti.com/.../

Thanks
ki

I was referring to the page of instructions you sent me. I saw different Target Configurations available, but I haven't seen yet how to create them. I was looking at and your next post came.

Sorry for my lack of knowledge of these tools. It's my first time using these tools, and first time dealing with a *.out file. So we clicked on the debug icon, and that got us into the run mode and programmed the flash. Then we clicked on Run, Load, Load Program and chose the new *.out file. Maybe there was a better way to do it.

But running the *.out file from my colleague, the debugger still goes away at the exact same assembly language instruction.

Mark Sheats said:

I was referring to the page of instructions you sent me. I saw different Target Configurations available, but I haven't seen yet how to create them. I was looking at and your next post came.

ah ok. Sorry, I got confused. You should have one for your project. But if you want to create new ones, slides 6&7 of the below link explain it:

http://software-dl.ti.com/ccs/esd/training/modules/target_configurations/CCSv5-TargetConfigurations.pptx

Mark Sheats said:

Then we clicked on Run, Load, Load Program and chose the new *.out file. Maybe there was a better way to do it.

That should work also.

Mark Sheats said:

But running the *.out file from my colleague, the debugger still goes away at the exact same assembly language instruction.

Thanks. Since you used the same HW setup and *.out file that works on a colleagues environment, it must be an issue with your HW environment.

May I ask you to try two more things? The first is update to the latest CCS version (7.4). If that fails to help, please also take the *.ccxml file from your colleague and use that file to launch the debugger, instead of the one you created.

As for the logs you sent, they have been analyzed with the following findings: The debugger tried to step past the instruction in question and a failure was returned. When that happens, the debugger will issue a halt (which was successful) and then try to get the current state of the target (halted/running/etc) but that status update attempt failed. The debugger is unable to get the proper error string for the failure and it tries 20 times before it gives up. Hence the true error message is unknown to us.

Nothing groundbreaking here as it is information we knew to some degree. Unfortunately we still don't know why that next step attempt failed. There is still a chance that it is some known driver issue that was fixed in a later CCS version - which is why I suggested the update. Also, making sure the target configuration is identical to a known working environment is a good idea - hence why trying out your colleague's *.ccxml file is worth a try

Thanks

ki

I am already using 7.4 now, and last night I did an update to make sure I had the latest of everything.

I just did a test.  We picked up his debug (interface) board and his target board, and carried over to my desk.  I renamed my *.ccxml file in the project list and dragged his over to the project and chose the option to link to it (not copy the file).  I then clicked on the debug button and saw the same behavior as before.  It seems like my laptop is not able to do what his computer can do, at least not after that one instruction that turns on the display.

We have not talked about project properties, like include files and ARM Linker options.  My settings look different from at least this colleague's settings.  Is it possible something there is causing an issue?

I have a big mixture of includes from two different Tivaware versions.  Could that be causing a problem?  Some things are pointing to

TivaWare_C_Series-2.1.3.156

And some are pointing to

TivaWare_C_Series-2.0

I created a new workspace, imported my previous v7 project (copied files), and tried to set everything to point to TivaWare_C_Series-2.1.3.156.  It seems that we still need a couple files from TivaWare_C_Series-2.0.

I am able to compile, but the linking process is not clean right now.  I can download some, but it won't finish the download and start debugging.

Now it seems that different *.ccxml files are making a difference.  If I use a different *.ccxml file, I can download completely and start running, but no debugging.