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)
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.
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?
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.