Loading...
 

SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world. And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download (registration required) various documents highlighting:

System Workbench for STM32

Forum List Topic List

[ prev topic ]  

Can't run debugger - It was working

Posted by St3v3 on 2015-11-25 08:04

At one time I was able to run and debug my application from Sytem Workbench on the STM32L476 Discovery board. It has now become broken with this error message:
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Warn : use ‘STM32L476.cpu’ as target identifier, not ‘0’
adapter_nsrst_delay: 100
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
adapter speed: 1800 kHz
Info : clock speed 1800 kHz
Error: open failed
in procedure ‘program’
in procedure ‘init’ called at file “embedded:startup.tcl”, line 473
in procedure ‘ocd_bouncer’

    • OpenOCD init failed **

shutdown command invoked

The STM32 ST-LINK Utility still is capable of loading firmware into the board.

The dongle is listed in Dev Manager under Universal Serial Bus devices as Location 0 (Port_#0001.Hub_#0001)

Can anyone tell me what has gone wrong?

Reads: 19491
Link
Posted by JackN on 2015-11-25 16:13

Hi,

I struggled with a similar situation for 2 days. The error message sometimes changes but was consistent in failing. Then it went away and then came back - very frustrating. I eventually narrowed it to being caused by invalid breakpoints. (breakpoints that were in comments or referring to line numbers that was no longer valid in the code).

Everytime it comes back, I have to remove all breakpoints, clean the project and rebuild. Occassionaly I also have to use ST Link utility to wipe the existing program from the board’s memory. Then it usually works again until I forget to clean up my breakpoints, and I am forced to repeat all over.

I hope this helps.

Link

Posted by St3v3 on 2015-11-27 06:31

Hi
Thanks for the suggestions. I checked and don’t have any break points set, cleaned the project, wiped the board etc, still no luck. I also have a Nucleo board and debug was working on that last night. I just closed the project and now can’t get debug to work on either board tonight. The error for the Nucleo board project is:
Error with command: gdb --version
Cannot run program “gdb”: Launching failed

This one was working yesterday.

The error for the L476 Discovery board today is:
Error in final launch sequence
Failed to execute MI command:
-target-select remote localhost:3333

Error message from debugger back end:
localhost:3333: The system tried to join a drive to a directory on a joined drive.
localhost:3333: The system tried to join a drive to a directory on a joined drive.

For both boards I do create the .bin and .elf file and STM32 ST Link will load the board and execute.

The next thing I can try is start from a clean slate, new project and see if I can change the behaviour but when it works one day and not the next not sure how much time I want to invest. It’s a shame because ST has given me at least 4 of the various boards and the hardware seems interesting.

Link

Posted by St3v3 on 2015-11-27 07:09

Well, I was able to get the Nucleo project debugging again by Right click on project, click Debug As > AC6 STM32 C/C++ Application.

This seems to have repaired something in the configuration and I am able to again Load, Run and Single Step on the Nucleo board.

I’ll continue flogging the L476 Discovery board and see if I can sort anything out.

Link

Posted by St3v3 on 2015-11-28 07:13

I have more information. First I was able to confirm JackN’s observation that an improper break point will stop the debug. In this case I put a breakpoint on a comment line and debug fails. Removing that breakpoint allowed success on the Nucleo board. At this point I can debug the Nucleo board but not the L476_Discovery Board.

I got the debug log from OpenOCD and this is the important error:
Debug: 256 29 stlink_usb.c:1602 stlink_usb_open(): stlink_usb_open
Debug: 257 29 stlink_usb.c:1619 stlink_usb_open(): transport: 1 vid: 0x0483 pid: 0x374b serial:
Error: 258 270 stlink_usb.c:1632 stlink_usb_open(): open failed
Debug: 259 270 hla_layout.c:49 hl_layout_open(): failed
Debug: 260 270 command.c:628 run_command(): Command failed with error code -4
User : 261 270 command.c:689 command_run_line(): in procedure ‘init’
in procedure ‘ocd_bouncer’

Device manager sees the programming device like this:
USB\VID_0483&PID_3748

Is it significant that OpenOCD thinks the PID is 0x374B and Device Manager thinks PID is 0x3748? B versus 8?
I should also say this is 64bit Windows 7 on a Dell Latitude laptop. STM ST-Link Utility loads the L476 fine.

Can anyone suggest further troubleshooting?

Link
Posted by Vetch on 2016-11-29 09:47

Hi,
I tried to reproduce this issue : I set 5 breakpoints on different comment lines but there is no issue and the debug session is running well on my L476RG. So I think that the root cause is not to set breakpoints on comment lines.
I noticed some USB issues with SW4STM32 (whereas it works with CubeMX) were due to the USB driver. Some USB 3.0 Controllers (such as NEC/Renesas) have a bug that prevents the binary to be downloaded to the board.
Please, may you check you are using the latest version of the controller to fix this issue.
Note that sometimes, the device manager seems to be up to date but the issue is fixed after executing the setup provided in the zip.
It can be downloaded from :
https://s3.amazonaws.com/plugable/bin/2014-03-Plugable-Renesas-USB-3.0-200-2.1.39.0.zipQuestion

Link

Posted by dnbharrin on 2016-11-28 19:13

In my case on the Nucleo 64 STM32L476 board, the debugger was working the previous day. Then today, I got the:

“in procedure ‘ocd_bouncer’

    • OpenOCD init failed **

shutdown command invoked”

error.

All I did was disconnect board from computer and reconnect. Initiated debug and it worked fine again.

Too bad all errors aren’t that easy to solve.

Link
Posted by dnbharrin on 2016-11-30 20:10

Debugger was running, now I can’t get it running again. Same board, same configuration, same project, same program with absolutely no changes. Why is it different now!!!
Here is the error box I get when I try to run debug with all the default settings for the Ac6 STM32 Debugging configuration:

Error in final launch sequence
Failed to execute MI command:
load C:\STM32_Nucleo_Projects\GPIO_Test1_20161124\Debug\GPIO_Test1_20161124.elf

Error message from debugger back end:
Error erasing flash with vFlashErase packet
Error erasing flash with vFlashErase packet

Note that Build and Run were accomplished with no errors.

Also I get a strange tab in the Console window labeled “0x800171a”. It contains:

No source available for “0x800171a”

in red font.

Link
Posted by dnbharrin on 2016-12-06 01:10

Found answer to problem in another thread:

Use Task Manager to kill any openocd.exe processes that are still running.

Debug ran fine after killing the openocd.exe process.

Link

Posted by Vetch on 2016-11-29 09:51
Hi, some big companies are using firewall or VPN that blocks USB port (3333). May you check it?
Link
Posted by KerwoodDerby on 2017-12-08 20:08
BINGO! I was going ‘round and ‘round with my F3 Discovery board just now until I read your comment and, desperate to try anything, I changed the port to 1022 (as in, less than 1024) and suddenly I could debug. Apparently my employer’s IT staff have decided they need to block high-numbered ports, even on localhost. Bah!
Link