SparkFun Forums 

Where electronics enthusiasts find answers.

Open source ARM Debugger
By bloggins666
#188203
I have some experience using the Atollic TrueSTUDIO tool to develop s/w for a STM32L4... processor. I have my own STM32F429 Discovery board and I was hoping to work with it just using free s/w (eclipse and openocd). I have had some success with this combination but I find it problematic.

I work exclusively with LInux (running Kubuntu 14.04LTS) and I'm connecting to the Discovery board via USB cable to the ST-Link/V2 connector.

I'm using eclipse (Luna) and openocd 0,9.0. I have used the ST-Micro utility to bring the Firmware on the ST-Link/V2 to V2J2m15.

From the command line or within eclipse (the results are the same) I have this as my command line for openocd:

openocd -f board/stm32f429discovery.cfg

Here is the output:

Open On-Chip Debugger 0.9.0-dev-00223-g1567cae (2015-01-12-13:43)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : clock speed 2000 kHz
Error: open failed
in procedure 'init'
in procedure 'ocd_bouncer'
in procedure 'transport'
in procedure 'init'

I have attached the output with the debug output level set to 3.

What am I doing wrong here? I had the same problem with another board. It was working fine and I had been developing my software without a problem. I may have done an OS update and it suddenly stopped working.

I then bought this board and tried to develop upon it but I am brought up with this problem. I was able to get the other board (STM32F401C-DISCO) to work by updating the ST-Link/V2 firmware on it. The same process does not work with this board.

Cheers!!
You do not have the required permissions to view the files attached to this post.
By bloggins666
#188279
So, I've figured the problem out myself.

The error "open failed" was in the usb_open() which is controlled by the "vid" and "pid" values. For those of you not acquainted to the quagmire knows as USB, that would be "Vendor ID" and "Product ID". Upon examination they were getting the values of 0483:3748 which is coded up in the file: stlink-v2.cfg which is referred to by the file: stm32f429discovery.cfg. This is the described file to be used when running openocd with the stm32f429 Discovery board.

If you run the following command: lsusb

You get the output (I have only left in the output for the relevant device):
Bus 002 Device 002: ID 0483:374b STMicroelectronics

So, the value is wrong, the device is using 374b, I changed it in the file stlink-v2.cfg and now I can connect. I run into all sorts of other problems but at least this one is fixed locally.

How did this happen? Could an OS update have changed the file? Any ways this specific problem is now fixed and understood.

My bigger worry is the lack of activity on this forum. I'm very surprised that I didn't see any traffic on this issue. Especially since I see that this 0.9.0 release was from May 18th of 2015. Is this still an active project?

Cheers!!
By bloggins666
#188293
Now the problem I'm dealing with is the response that comes back from the device when the error:

stlink_usb_error_check(): unknown/unexpected STLINK status code 0x9

Is printed. This value is placed in the databuf array within the handle when the function: stlink_usb_xfer_rw() is called.

The stack dump is:
Thread #1 [openocd] 13125 [core: 3] (Suspended : Step)
stlink_usb_xfer_rw() at stlink_usb.c:308 0x45506a
stlink_usb_xfer() at stlink_usb.c:348 0x45559e
stlink_cmd_allow_retry() at stlink_usb.c:420 0x45657d
stlink_usb_mode_enter() at stlink_usb.c:651 0x45663f
stlink_usb_init_mode() at stlink_usb.c:793 0x457708
stlink_usb_open() at stlink_usb.c:1,736 0x457708
hl_layout_open() at hla_layout.c:46 0x454b18
hl_interface_open() at hla_interface.c:58 0x454a25
hl_transport_init() at hla_transport.c:183 0x454c6e
run_command() at command.c:613 0x444840
<...more frames...>
I hope someone can tell me what is happening here. I have no idea what spec to read to find out what the ST-Link device should be responding with here. I defined a bogus value for the switch() statement so it returned ERROR_OK but the device went into a tailspin at that point.

Again any help would be greatly appreciated. I can run any debug setup required if someone has some ideas as to what I should try or a test that can be done.

Cheers!!