OpenOCD configuratioins for TWR-K60D100M

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

OpenOCD configuratioins for TWR-K60D100M

2,274 Views
krishnaraj
Contributor I

Hi,

I am using latest version (0.7.0) open ocd for debugging Freescale tower module TWR-K60D100M. But for some reason the open ocd could not identify this module and throws error on debugging. Below is the error message:

Open On-Chip Debugger 0.7.0-dev-00079-g08ddb19 (2013-03-01-11:10)

Licensed under GNU GPL v2

For bug reports, read

        http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'jtag'

srst_only separate srst_gates_jtag srst_open_drain

adapter speed: 1kHz

cortex_m3 reset_config sysresetreq

Info : add flash_bank kinetis pflash.0

Info : add flash_bank kinetis pflash.1

Error: Can't open OSBDM device

in procedure 'init'

The command used to start the open ocd is as mentioned below:

/usr/local/bin/openocd.exe -s /usr/local/share/openocd/scripts/ -f /usr/local/share/openocd/scripts/interface/osbdm.cfg -f /usr/local/share/openocd/scripts/board/twr-k60n512.cfg

I am not sure about why this error appears. I am also not sure whether open ocd supports this tower module. Could any one please let me know whether latest version of open ocd supports the TWR-K60D100M tower module. If so, anyone please let me know whether open ocd software requires any changes?


Regards,

Krishnaraj.

Labels (1)
0 Kudos
6 Replies

804 Views
stan-
Contributor I

Hello,

I understand this is over an year old now, but this might help someone else.

The problem could be missing udev permissions. Adding the permissions solved it for me. I am using Ubuntu 13.04. Google around for alternative paths and commands if your system is much different. I did the following:

Simply create the file /etc/udev/rules.d/52-osbdm.rules and enter this as the contents:

SUBSYSTEM=="usb", ATTR{idVendor}=="15a2", ATTR{idProduct}=="005e", MODE="0777", OWNER="<ubuntu-user>"

Don't forget to replace <ubuntu-user> with the actual username.

After this reload the rules with: sudo udevadm trigger.

If this doesn't work, then the problem is not in udev rules.

Good luck,

- Stan

0 Kudos

804 Views
smckown
Contributor II

Somewhere between versions 30.13 and 31.21 of the OSJTAG (OSBDM) firmware, USB VID:PID of the OSJTAG USB interface was changed, and openocd trunk as of 4/19/2013 doesn't know this combination.  In the source code, the change is trivial.  In src/jtag/drivers/osbdm.c file, change these two lines which appear at line 133:

static const uint16_t osbdm_vid[] = { 0x15a2, 0x15a2, 0 };
static const uint16_t osbdm_pid[] = { 0x0042, 0x0058, 0 };

To instead read:


static const uint16_t osbdm_vid[] = { 0x15a2, 0x15a2, 0x15a2, 0 };
static const uint16_t osbdm_pid[] = { 0x0042, 0x0058, 0x005e, 0 };

Then, './configure', 'make' and 'sudo make install' as usual.  When ./configure is ran, use all the --enable-XXXX options needed, see './configure --help' for a full list. The option '--enable-osbdm' compiles in OSBDM support.

I'm successfully writing firmware using this change to a Kinetis tower board.  I've posted a patch to the openocd-devel mailing list, so some future version will probably contain this change.

Steve


0 Kudos

804 Views
jpa
Contributor IV

Thanks, Steve!  I've been beating my head against this today, so your response couldn't have come at a better time for me. 

Followed your code changes, rebuilt with --enable-osbdm --enable-maintainer-mode, and I no longer get the "can't open" message that the OP quoted.  I still can't debug (lots of JTAG-DP STICKY ERROR among other things) but I'm at least past this stumbling block. 

Thanks again,

John

0 Kudos

804 Views
smckown
Contributor II

FYI, openocd-0.7rc1 includes the USB VID:PID described in this thread.

John, I can't debug either.  I don't need to track down a solution right now, but if I do run across anything useful in the future I'll be sure to post here.

0 Kudos

804 Views
jpa
Contributor IV

For what it's worth, I built openocd-0.7rc1, then downloaded and installed the gnu tools using "arm-2011.09-69-arm-none-eabi.bin" and that seemed to do the trick, at least so far as being able to build the "getting_started.s" file from the examples, load it into the board and from all appearances, step through the code using the gdb command line.  No more "sticky errors" with this version of gdb. 

John

0 Kudos

804 Views
krishnaraj
Contributor I

Hi,

I am waiting for the answer for my above question. Could anyone please respond.

Regards,

Krishnaraj.

0 Kudos