[ciaranmaca]

Hi,

Thanks for the reply. Yes, I set the target to cc32xx.cfg and that got me partly there. I still hard an error about signal definitions. But taking inspiration from the gcc scripts in the tools folder of the TI SDK for CC3200 I added these two lines to the interface/ftdi/cc3200lp.cfg script:

# Add for SWD
ftdi_layout_signal SWD_EN -ndata 0x0080
ftdi_layout_signal SWDIO_OE -data 0x0008

And hurray, it works.

Thanks for your help. I consider the issue resolved.

Ciarán

[ciaranmaca]

Hi,

No, that didn’t work either. I get the following error:

Ciarán

 

^error,msg=”-var-assign: Could not assign expression to variable object”
-exec-continue
^error,msg=”Warning:\nCannot insert breakpoint 1.\nCannot access memory at address 0x20004ac8\n”

— GDBServer output —
Open On-Chip Debugger 0.9.0 (2016-09-01) [https://github.com/sysprogs/openocd]

Licensed under GNU GPL v2

For bug reports, read

http://openocd.org/doc/doxygen/bugs.html

adapter speed: 1000 kHz

jtag

adapter_nsrst_delay: 100

jtag_ntrst_delay: 100

cortex_m reset_config sysresetreq

VisualGDB_OpenOCD_Ready

Info : clock speed 1000 kHz

Error: JTAG scan chain interrogation failed: all zeroes

Error: Check JTAG interface, timings, target power, etc.

Error: Trying to use configured scan chain anyway…

Error: cc3200.jrc: IR capture error; saw 0x00 not 0x01

Warn : Bypassing JTAG setup events due to errors

Info : accepting ‘gdb’ connection on tcp/63987

undefined debug reason 7 – target needs reset

Error: Target not examined yet

Error: Target not examined yet

Error: Target not examined yet

Error: Target not examined yet

Error: Target not examined yet

Error: JTAG scan chain interrogation failed: all zeroes

Error: Check JTAG interface, timings, target power, etc.

Error: Trying to use configured scan chain anyway…

[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

[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

[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

 

[Author]

Posts