CCS/TM4C129XNCZAD: Debugging an asm bootloader

Hi Peter,

Peter Borenstein said:

I import the project from TivaWare_C_Series 2.1.4.178. I follow CCS warning to change the compiler from TI v5.2.6 to TI v18.1.1.LTS. CCS is at version  8.0.0.00016. The target hardware is the EK-TM1294XL. The connection is ICDI.

I've got the exact same setup here.

However,

Peter Borenstein said:

Breakpoints don't work initially and I can't step through the assembly code.

I can't reproduce these issues. I imported the project and built it with the default options (-o2)

I have no issues setting breakpoints in C files when the code is first loaded. I was able to set one on line 1783 of bl_emac.c (I double clicked on the editor marge at 1776 but the debugger moved it to 1783 where relevant code was). I have no issues setting breakpoints in bl_startup_ccs.s and I can step through that asm file just fine. I can set a breakpoint at line 257, run to the breakpoint and then asm step into ProcessorInit.

Peter Borenstein said:

The code doesn't run properly with optimizations off. I think the issues are caused by the chip running code from SRAM.

I can't comment on the above two issues as I lack the expertise of the device and the example code. I will forward this thread to the device experts who can provide more insight.

Thanks

ki

ki,

I put a fresh install of tivaware v2.1.4.178 on another PC. The issue occurse. I have to do some odd combination of suspending and disabling/re-enabling to get the breakpoint to break.

I see the same breakpoint movement to line 1783 in my setups. The pbreakpoint is at an SRAM address 0x20000B3C. but it breaks at address 0x20000B44 (after the hack steps)

Here is a screenshot of the breakpoint's properties at the start. The properties don't change between this point and when CCS is coerced into to respecting the breakpoint.

This issue occurs in the project boot_serial which is available in the resource explorer. boot_emac_flash must be imported from the TivaWare install directory. Perhaps using this project could eliminate some variables?

Peter Borenstein said:

but it is comical that the TI employee responsible for CCS doesn't see the the debugging error and the TI employee responsible for devices does.

This happens sometimes. The common reason for that is the tools person (in this case - me) lacks fundamental expertise of the device (and example/SDK) to properly understand the issue to reproduce it - knowledge that both the device expert and the experienced customer would find trivial. I will work with Charles so he can help me reproduce the issue.

Thanks

ki

The breakpoints will be "ignored" again after a core reset or restart command is given.

Breakpoints placed in the flash address are always respected including after core resets. I have to give a core reset to get back into flash. The restart button puts you where CCS starts (_c_int00 at an SRAM address).

Breakpoints placed in the flash have a label "H/W BP". Does this label mean hardware breakpoint? The The ignored breakpoints are labeled "S/W BP". Is there a way to set a H/W BP in SRAM code instead of a S/W BP?

After a core reset is given, I can see assembly code that matches the source in bl_startup_ccs.s. I have to see this in the dissasembly window. CCS doesn't display the source and says "Break at address "0xdc8" with no debug information available, or outside of program code." Because of this, I set the breakpoint by clicking the margin in the disassembly window.

May I rise to the defense of Ki-Soo-Lee?     It has long been noted that he has effectively serviced,  "THOUSANDS of client-users" - and his knowledge is unusually broad, deep & caring.

That said - Vendor Agents - even outsiders here who have Co-founded - taken past Tech Firm PUBLIC - cannot be expected to know "everything" - especially when "cold" - and when otherwise, "Scrambling to Assist!"

I thus find Peter's choice of the word "comical" highly IMPROPER - even regretful.     A word-choice such as, "unfortunate" (yet understandable - as Mr. Lee well detailed) - would have proved far more appropriate & markedly superior...      To "attack" one striving to assist - never proves,  "well-thought, kind or wise!"

Hello Peter,

I have been having a private discussion with Charles, but let me share what I have found.

I have been able to reproduce some of the issues. Specifically:

Peter Borenstein said:

Breakpoints for C files can not be set when the code is first loaded. Disabling and enabling a breakpoint will cause it to take effect after the code is allowed to run. I also see the breakpoint take efect if the chip is suspended and resumed, but thos results are intermittent. I know the processor will hit a while(1) loop on line 1776 of bl_emac.c. I set a break point in this loop. Pausing the chip shows it is within this loop. I can single step over the breakpoint. After I resume running, the chip might start hitting the breakpoint . If I pause, disabled and re-enabled the breakpoint, it will break. I do this by unchecking and checking the box in the Breakpoints window. Note to re-create this issue, the dev kit needs to be plugged into a switch. A previous wait looks for network connectivity. before hitting line 1776 of bl_emac.c

I can definitely reproduce this consistently now. Basically once the debugger halts or steps over the address where the breakpoint is, it now seems to "recognize" that breakpoint. I set a few breakpoints in the C code, on lines 1783, 1865, 1909. I manually halted and it was on line 1783. When I ran again, it would only halt on 1783. After it halted on 1783, I source stepped to 1865. The I ran. It would halt on 1783. When I ran again, now I'd halt on 1865. Eventually I got the breakpoint on 1909 recognized when I went through a similar step.

Peter Borenstein said:

Line 257 of bl_startup_ccs.s does not work with the step over or step into commands. Either of those commands seem to act like the command resume running. ProcessorInit is on line 190 of bl_startup_ccs.s. I can set a break point after the label "ProcessorInit " and it will stop, but the process will behave as if "resume running" was clicked if the breakpoint is not set.

Now this part I didn't consistently reproduce. After an explicit program load, I can always halt on breakpoints I set in the asm file. I can also step in/over line 257. However, if I restart the program, I get the issue where the breakpoints in the asm file are ignored.

this is still under investigation...

Charles Tsai said:

After l first loaded the program the CPU is first halted at the reset vector. It hasn't copied the code to the SRAM yet. I don't know how the debugger places the s/w breakpt at this time. Eventually when the run code is copied to the SRAM whatever was previously in the SRAM will be overwritten.

the debugger will be aware of the run address and will try to set a breakpoint at the run address, even before the code got copied to it

It could be that then the breakpoint op codes set in SRAM gets overwritten when the code is copied to it. But the question is why does it eventually "work" once that address is reached? Maybe the debugger recognizes that there is no breakpoint opcode there and reapplies it. 

Ki-Soo Lee said:

It could be that then the breakpoint op codes set in SRAM gets overwritten when the code is copied to it.

This seems to be the case. If you load the program and run it so that the code has been copied to SRAM, and then halt the program and set breakpoints in the C file, everything works. 

Charles Tsai said:

Now I tried to let the code run first. It will stay in the while(1) loop of the UpdateBOOTP function as it is waiting for the magic packet. If I place s/w breakpts on some of the lines inside the while(1) loop then it will break.

I see you already confirmed what I wrote just before. I missed that originally. Sorry!

Ki,

Ki-Soo Lee said:

Hence the latter option of setting the breakpoints after the code is copied into RAM seems to be the best bet.

This seems very difficult to do because the code that does the copying itself is executed in SRAM. When CCS starts, the processor (PC) is already at SRAM address 0x20000E1A. The breakpoints are overwritten from SRAM.

The 6th op code branches to the function that does the copying and therefore overwrites all of our breakpoints.

The code after this copy loop is at address 0x20000DA2. The loop copies 4 bytes at a time. So I would need to step through this loop 873 times, then set a post-loop-breakpoint after this loop, then resume running, and finally, when the post-loop-breakpoint breaks, I can set other breakpoints.

Ki-Soo Lee said:

Now this part I didn't consistently reproduce. After an explicit program load, I can always halt on breakpoints I set in the asm file. I can also step in/over line 257. However, if I restart the program, I get the issue where the breakpoints in the asm file are ignored.

this is still under investigation...

It is still a mystery why you can set into line 257, but I would not expect you to be able to break on line 208. Line 208 is right after the copy loop. I expect this loop is overwriting the breakpoints.

This does not seem like a large problem because I can set a break point on line 195, but it may be a clue...

Ki-Soo Lee said:

Hence the latter option of setting the breakpoints after the code is copied into RAM seems to be the best bet.