CC3200 Stand-alone project with Launchpad

[ciaranmaca]

Hi,

I am deciding whether to introduce Visual GDB into our embedded team. We use TI’s CC3200 (among other micro-controllers,mostly all cortex m based). I loaded up the Blinky project as detailed in the tutorial and it worked great – setting breakpoints, stepping, etc (using TI launchpad, the FT2232 based eval kit). Now I want to run my own standalone project, so I did the ‘convert to standalone’ process, deleted all of the code from the project, and put back in my own code – a selection of SDK libs that my own project uses, plus my own code. Then I edited the CFLAGS and LDFLAGS (mainly for -fno-builtin -nostdlib). Builds lovely. Set a breakpoint in main, then launch the debug session then this:

Nothing! It didn’t hit the breakpoint and doesn’t seem to be running.

If I pause the execution, it’s in assembler and shows :

0x0000978e  b.n 0x978e 

Which suggests a loop but the addresses are bootloader addresses?

 

What is going on? Anyone any idea?

Thanks

Ciarán

 

 

[support]

Hi,

If the project works with a normal non-stand-alone version, the easiest way to figure out what is wrong would be as follows:

1. Create a normal project again. Enable the .map file generation.
2. Copy it to a different directory. Convert it to a stand-alone one. Rebuild it.
3. Use a diff tool to compare the 2 .map files. If the differences don’t immediately point to the problem, feel free to post the map files here and we will try to help you locate the issue.

[ciaranmaca]

Hi,

I created a standalone project from the standard blinky and that worked. Yet my own standalone project doesn’t. I am building with very simple code and I am using the same linker command file and build options as the stand alone blinky. When I view memory when debug starts I can see that my ‘intvecs’ are sitting at the right location. But I cannot stop at any breakpoint. My reset vector is pretty much a copy of the blinky one – I set the stack pointer, zero the bss, and jump to main. I have no runtime code other than that and no libs to initialise. When I set a breakpoint in the reset vector it doesn’t stop there. I have compared my other settings openocd etc with the blinky and see nothing different. I must be missing something?

Ciarán

 

[ciaranmaca]

Hi again,

Just a small additional piece of info. It seems that when I start the debugger that execution goes to the bootloader (in ROM starting @ 0x0) and it gets stuck there in a loop. If I pause the execution and use gdb to set the pc to my reset vector and then continue, I can stop at my break points and so on.

So it seems my breakpoints work. But something in the startup sequence is wrong. I’m not sure what commands VisualGDB uses via gdb /openocd to halt/load etc. But I see no reason given my settings why they would differ from those of the blinky project. That is the mystery.

 

Ciarán

[support]

We would still recommend comparing the .map files of the working and broken projects side-by-side. Significantly different addresses of sections or missing groups of functions could provide good clues on what is going on.

[ciaranmaca]

Hi again,

Positive news. I’ll report here for future readers. When I examined the map file between the project which worked and the one which didn’t I found no real difference. Then I made a discovery : I was using the same linker command file between the two projects – bar one major exception: the broken (non-debuggable) project did not have the line “ENTRY (reset_vec) in it. My assumption was that this would be ok, because vector table had my stack at position 0 and reset vec at position 4 as Cortex needs. But here is the thing: this vector table is NOT actually executed by Cortex at startup – instead, at startup Cortex, on this particular part, the CC3200, executes a vector table in ROM, and runs a boot loader. In a non-debugger scenario, the bootloader loads an image from flash and makes the requisite changes to the PC etc. But with the debugger non of that happens. Instead the debug environment needs to take over and set the PC to the reset vector. So it is critical that the entry point is right. The answer was provided by

readelf -e <imagefilename>.elf which showed the difference in entry point between the two images. That was the key.

 

So now it is looking much better and I consider this particular issue resolved. Thanks for your reply.

Ciarán

[Author]

Posts