CCS/TM4C123GH6PM: debugger losing control on program

Hi Baruch,

 Does the program run correctly when you are in run mode (not single stepping)?

 Did you single step in the C code or in the assembly code?

 If you single step in the C code and see the code kind of jumping around, then it is likely due to the compiler optimization. By default the optimization is set to 2. You can change to "off "and you should be able to see the single stepping not jumping around. But first answer the questions if your code run correctly in run mode before changing the optimization. Also you should keep the optimization at proper level for your application in its final development.

  If the program does not run correctly even in the run mode then it is a different issue to investigate. 

the code runs correctly on run mode, and optimization level is already on 0.

Does it make a difference if you set the optimization to "off" instead of "0"?

Oh, my bad, I meant that the optimization is turned off. Happens in both disassembly and c step-by-step runs.

What is your function? Can you show at which line inside the function? Did you compile in thumb2 or ARM state? Are you viewing in ARM mode or Thumb2 mode in the dissassbler window?

The MCU reads and writes values to the  display unit's registers, then, in line 182,  the mess starts:

about thumb2\ARM mode, I'm not sure, where do I check it?

The wr8 is your own function. Why are you not using the TivaWare API? If you want to change the direction of the GPIO pin you can use the below API. Please refer to the TivaWare library and examples.

GPIODirModeSet(uint32_t ui32Port,
uint8_t ui8Pins,
uint32_t ui32PinIO)

wr8 writes to the display unit. It uses the SSI, so underneath there are API functions.
However, I don't think it causes the problem, because it worked fine for a couple of months and I didn't touch it.

Hi Baruch,
Do you still have the problem? If you do a clean project and rebuild project will it make a difference?

Sorry I wasn't available. I tried to clean and rebuild the project, the problem still encounters in the same place, I'm afraid.

EDIT:

I add here two more screenshots from the disassembly window, with the assembly\C mixed view. The first on is before I step into wr8 function (line 179):

and this where the debugger goes when I step into it:

Baruch,

Does the code function correctly if you step-over the function in question rather than step-into?

One setting you could check into is the "Disable interrupts" option in the Debug options. If the disable interrupts when source stepping option is enabled that could be impacting execution.

Besides that, to debug this further you could try single stepping through the assembly code and correlate the instructions with the values in registers/memory to see which instruction or where things are going wrong causing it to land in invalid memory. That might give some additional clues to the source of the issue. 

No, when I try to step over the function, the problem occurs. Furthermore, even when I put a breakpoint anywhere in the code flow after this function, it happens.
I'm not in the office today, I will check the 'disable interrupts' option on Sunday and update you.

Okay, I checked it, and the setting are just as shown in your screenshot. disabled for assembly, enabled for source.
I will try to track the assembly step-bystep later, as you advised.