Jump to content
ntfreak

ICDI support in OpenOCD

Recommended Posts

Is there a way to mask interrupts while stepping? I'm trying to debug a USB CDC enabled code. After a breakpoint I try stepping and end up in USB0DeviceIntHandler.

 

I've seen some posts about cortex_m3 maskint, but it seems this command is not available (nor applicable) in this patched version on OpenOCD.

 

This is something i need to look into more, as you have seen the std cortex implementation does have a maskisr function that does what you want.

The higher level adapters (stlink/icdi) do not have access to this implementation, but with a few changes i sure we can get it working on the icdi aswell.

 

One solution if you are using an ide is to use the "run to", as this sets a breakpoint and works around the issue.

 

Cheers

Spen

Share this post


Link to post
Share on other sites

I have followed scompo's tutorial and I have successfully built openocd, but couldn't make it to work.

 

I launch openocd:

 

$ sudo ./openocd --file ./LM4F120XL.cfg
Open On-Chip Debugger 0.7.0-dev-00089-gf064aac (2012-11-19-20:57)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
adapter speed: 1000 kHz
Info : clock speed 1000 kHz
Info : ICDI Firmware version: 9270
Info : lm4f120h5qr.cpu: hardware has 6 breakpoints, 4 watchpoints

 

Then I launch GDB and connect to openocd:

$ arm-none-eabi-gdb main.axf
GNU gdb (Linaro GDB) 7.3-2011.10
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=arm-none-eabi".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /home/jalon/src/stellaris/stellaris-launchpad-template-gcc/main.axf...done.
(gdb) target extended-remote :3333

 

When I type the target ... :3333 command in GDB, something goes wrong. Openocd spits this:

 

Info : accepting 'gdb' connection from 3333
Warn : acknowledgment received, but no packet pending
undefined debug reason 6 - target needs reset
Info : dropped 'gdb' connection

 

And GDP prints:

Remote debugging using :3333
Remote 'g' packet reply is too long: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
(gdb)

 

Am I missing anything? Do I have to flash the program using lm4flash? Do I have to do something with lmicdi?

Share this post


Link to post
Share on other sites

 

And GDP prints:

Remote debugging using :3333
Remote 'g' packet reply is too long: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
(gdb)

 

Am I missing anything? Do I have to flash the program using lm4flash? Do I have to do something with lmicdi?

 

It is a known issue, depending on where your gdb came from, see http://www.mail-archive.com/openocd-development@lists.berlios.de/msg18182.html for a workaround.

 

When I get some spare time I am meaning to update OpenOCD to better handle this issue.

 

Cheers

Spen

Share this post


Link to post
Share on other sites

Hi guys,

 

I just compiled OpenOCD on my Mac (10.7 using Homebrew libs because I compiled in support for ft2232 devices as well). Whenever I launch openocd it seems to die the first time around, however if I launch it immediately following it seems to kick in. I ran a --debug 3 on it and here is what it reports when it dies:

 

http://pastebin.com/ahr208hm

 

The funny thing is that this appears to be repeatable. If I kill openocd I can then launch it again and it will fail, at which point I can launch it AGAIN and it will kick in.

 

Board is just the standard Stellaris launchpad.

Share this post


Link to post
Share on other sites

martytoof,

 

Make sure you are using the latest patchset, quite a few tutorials link to older ones - latest is #14 so you would do the following

git fetch http://openocd.zylin.com/openocd refs/changes/22/922/14 && git checkout FETCH_HEAD

 

I do not use mac so have not tested under that OS, what version libusb are you using?

 

Cheers

Spen

Share this post


Link to post
Share on other sites

Yup, I specifically checked out 14. Keeping up to date was the first check :)

 

As far as libusb is concerned:

 

 

jackal:tcl pkiela$ brew info libusb
libusb: stable 1.0.9, HEAD
/usr/local/Cellar/libusb/1.0.9 (11 files, 416K) *
==> Options
--universal
Build a universal binary
 
 
This isn't a huge problem since running it twice in a row literally seems to work every time, I just didn't know if this was a known issue or not. I can certainly report it as a bug if that would be preferable. 

Share this post


Link to post
Share on other sites

 

This isn't a huge problem since running it twice in a row literally seems to work every time, I just didn't know if this was a known issue or not. I can certainly report it as a bug if that would be preferable. 

 

 

It is not a known problem, but i would like to find out why. Like i say i have only tested linux and windows and they do not have this issue - for me anyway.

 

First i would say check you have the latest ICDI firmware loaded - the version you have will be printed when OpenOCD connects - ICDI Firmware version: 9454

Mine is using 9454, at the moment the only way to update is on windows, you have to install the LMI Flash Programmer - http://www.ti.com/tool/lmflashprogrammer

 

The error returned is a read timeout, so the ICDI is receiving a cmd but not replying, if updating the firmware does not change the issue then as a test could you change the timeout value to 2 secs.

This can be changed by altering the define ICDI_READ_TIMEOUT to say 2000 (2secs) - file src/jtag/drivers/ti_icdi_usb.c:42.

 

Cheers

Spen

Share this post


Link to post
Share on other sites

In what version of OpenOCD did Stellaris Launchpad get added.  Is it in version 0.6.0, in 0.6.1, or later?

I was trying to figure out if I could use a prebuilt binary, but if there is a list of what was added when I still haven't found it.

(Don't see Stellaris Launchpad listed as being new in the 0.6.0 or 0.6.1 versions, but not clear what that means.)

 

If it isn't in 0.6.1 - is there a prebuilt version for windows that includes Stellaris Launchpad support?

Share this post


Link to post
Share on other sites

In what version of OpenOCD did Stellaris Launchpad get added.  Is it in version 0.6.0, in 0.6.1, or later?

I was trying to figure out if I could use a prebuilt binary, but if there is a list of what was added when I still haven't found it.

(Don't see Stellaris Launchpad listed as being new in the 0.6.0 or 0.6.1 versions, but not clear what that means.)

 

If it isn't in 0.6.1 - is there a prebuilt version for windows that includes Stellaris Launchpad support?

 

Found part of the answer to this.

 

Launchpad not supported in OpenOCD 0.6.1 (which is currently the latest release).

 

Haven't found prebuilt windows binary yet.

Share this post


Link to post
Share on other sites

Hello I am Manish .I am doing ARM cortex M4 Programming with STM32F4 discovery ,code flashes properly but it having problem when debgging with GDB.Following result i have found.please guide me how to slove that.

 

manish@manish-Inspiron-1501:~/my-wow-adc$ arm-none-eabi-gdb obj/STM32F4_Test.elf
GNU gdb (Sourcery CodeBench Lite 2013.05-23) 7.4.50.20120716-cvs
Copyright © 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-none-eabi".
For bug reporting instructions, please see:
<https://sourcery.men...m/GNUToolchain/>...
Reading symbols from /home/manish/my-wow-adc/obj/STM32F4_Test.elf...done.
(gdb) target extended-remote localhost:4242
Remote debugging using localhost:4242
0x080077fc in Reset_Handler ()
(gdb) monitor reset init
(gdb) load
Loading section .isr_vector, size 0x188 lma 0x8000000
Loading section .text, size 0x7e34 lma 0x8000188
Loading section .ARM, size 0x8 lma 0x8007fbc
Loading section .init_array, size 0x4 lma 0x8007fc4
Loading section .fini_array, size 0x4 lma 0x8007fc8
Loading section .data, size 0x5b0 lma 0x8007fcc
Start address 0x80077fc, load size 34172
Transfer rate: 6 KB/sec, 4881 bytes/write.
(gdb) b main
Breakpoint 1 at 0x80073f2: file src/main_temp.c, line 4.
(gdb) c
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.

then program halts

I am not getting why

Note: automatically using hardware breakpoints for read-only addresses.

above line prints and how to caime from that. :huh:

Share this post


Link to post
Share on other sites

manish,

 

You should have really created separate thread as this one relates to the TI ICDI support within OpenOCD.

 

Sorry but i see nothing wrong in the above log, you have flashed the target, set a breakpoint (@ main) and then told it to continue.

 

The note about breakpoints is nothing to worry about, it just means gdb has detected that hardware breakpoints are supported and is using them.

OpenOCD passes gdb info about the memory map, from which the above decision is made.

 

Cheers

Spen

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×