Loading...
 

Zephyr project on STM32

   Zephyr Workbench, a VSCode extension to manage Zephyr on STM32.
It enables users to easily create, develop, and debug Zephyr applications.
Main features:
  • Install host dependencies.
  • Import toolchain and SDK.
  • Create, configure, build and manage apps.
  • Debug STM32.
You can directly download it from the VSCode marketplace
For more details, visit the Zephyr Workbench

System Workbench for STM32


Run and Debug Configurations don't work

I’ve updated my software already, running std lib 1.6.0 and all.

I was in this bad habit of “braching” projects by simply making a copy of my current project to edit. After doing this several times, I found that when I clicked the “Run” or “Debug” button, the IDE would try and use a different “run” or “debug” configuration, one associated with a previous project. That’s wrong, right? It complains of course, and says that the file is not found, and says an error occurs.

Fine. That’s fair I suppose. Lots of files to keep track of in a project. I get it. I lost one somewhere.

So I try to be smart about it. No more laziness. I start a new project from the wizard, and copy only my own high level application sources and headers in. I add in my preprocessor definitions and it builds just fine.

So I go to run it or debug it, and it tries to run a configuration from some other project again! What!?

So I investigate further.

I click the little down arrow for “Run” and I get the configuration manager. Neat. But, no configuration for my newly created (via the wizard) project even exists. Great. That’s fine. It’s cool. So I simply click a button and add a project to a newly created “configuration” which should now be associated with my project. I give this configuration the same name as my project (because it just feels orthadox, you know?). I apply those changes, and hit “Run” from the manager window.

So it tries.

It erases flash, but fails to re-flash it with my application. What!?

A dialog window appears saying: Error: ‘MyProjectName’ not found.

So I go back into the “run” configuration manager and delete the configurations that are associated with other projects. Maybe the IDE fixated in some kind of love relationship with one of these others for some reason, see?

I click OK, and attempt a “run” and alas, my console displays the following message output:

Open On-Chip Debugger 0.9.0-dev-00418-g9afb8b4-dirty (2015-09-28-12:09)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/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 : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Error: libusb_open() failed with LIBUSB_ERROR_ACCESS
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

My target is blank, and openOCD periodically polls the thing and produces more junk in the console window.

I have no idea what’s happening. Everything is falling apart! What do I try next?

This probably comes from me being new to eclipse. Any gurus over here that can tell me what I’ve done wrong?

This has all happened over a period of 4 days. Time to get it working again.

Thanks guys!

Same kind of problem for me


Open On-Chip Debugger 0.9.0-dev-00418-g9afb8b4-dirty (2015-09-28-12:09)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 300 kHz
adapter_nsrst_delay: 100
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : clock speed 240 kHz
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Info : STLINK v2 JTAG v24 API v2 SWIM v11 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 72.776474
Error: init mode failed (unable to connect to the target)
in procedure ‘init’
in procedure ‘ocd_bouncer’



The IDE was installed via the windows installer.

I’m doing a re-install currently. I’ll check back if things don’t change.


After a full re-install, System Workbecnh is still a broken application.

The following error message doesn’t actually say what is wrong.

Open On-Chip Debugger 0.9.0-dev-00415-g2d4ae3f-dirty (2015-06-12-17:54)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/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
none separate
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v11 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.255446
Info : STM32F446.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080001e0 msp: 0x20020000

    • Programming Started **

auto erase enabled
Error: couldn’t open Lidar

    • Programming Failed **

shutdown command invoked

So am I just floating on my own here?

There is very little I can do with this information. Is anyone else seeing this?

Hi,

Looks like OpenOCD can connect to your board now.
Just to make sure, is “Lidar” the name of your project ?

Kevin.

That’s right, the name of the project is “Lidar”. Are there naming conventions I broke? I can try re-naming it if you would recommend it.

Hey, thanks for looking into this! It’s really great to hear from someone.

Anything I can try for you? Maybe you can more easily characterize the problem if I do more of “the things”?


Installed Eclipse CDT and then The openSTM32 plugins.
It was working properly before the update.

Now it just fails with



Open On-Chip Debugger 0.9.0-dev-00418-g9afb8b4-dirty (2015-09-28-12:09)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 300 kHz
adapter_nsrst_delay: 100
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : clock speed 240 kHz
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Info : STLINK v2 JTAG v24 API v2 SWIM v11 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.237246
Error: init mode failed (unable to connect to the target)
in procedure ‘init’
in procedure ‘ocd_bouncer’



Error in final launch sequence
Failed to execute MI command:
-target-select remote localhost:3333

Error message from debugger back end:
localhost:3333: Le système a tenté de joindre un lecteur à un répertoire stocké sur un lecteur joint.
localhost:3333: Le système a tenté de joindre un lecteur à un répertoire stocké sur un lecteur joint.


I desinstalled and reinstalled STLlink drivers, both: STSW-LINK004 and STSW-LINK009 multiple times without success.
My card is a Nucleo L152RE. As I said, it was working before the update.

I can access my nucleo board properly using ST-Link Utility.

21:52:11 : ST-LINK SN : 0672FF495056805087185238
21:52:11 : ST-LINK Firmware version : V2J24M11
21:52:11 : Connected via SWD.
21:52:11 : SWD Frequency = 1,8 MHz.
21:52:11 : Connection mode : Connect Under Reset.
21:52:11 : Debug in Low Power mode enabled.
21:52:11 : Device ID:0x437
21:52:11 : Device flash Size : 512KBytes
21:52:11 : Device family :-STM32L15xxE/L162xE

The Eclipse Debugging is also working properly with my Discovery STM32F407VG.
I use both the std script for the discovery or a custom script with STLink V2 and SWD

All my projects are generated with CubeMX.


Since it’s working with the Discovery I really think problem is related to STLink V2.1..The discovery is using STLink V2 and Nucleo STLink V2.1.My Drivers Installation shouldn’t be the problem since it’s working with STLink utility and Eclipse with Discovery board.

Emblocks has the same kind of problems with Nucleo.

By “script”, do you mean linker? Or startup?

I’ve issues with these things on embitz as well. Basically acting like all the symbols for _estack, _ebss etc are completely unknown to the linker. But the GNU debugger has been failing me as well on this board.

Why do you think it is the V2.1 drivers? I know the VCP drivers for Windows are quite buggy, so I switched from using the SWD semihosting a long time ago.

And I’ve never touched the mbed (mass storage device) drivers for the nucleo.

So for flash and debug, wouldn’t the drivers be identical?

It looks like the debuggers are getting 95% of the way there before something goes horribly wrong.

By script I mean OpenOCD configuration script (debug cfg->debug-> at bottom)

In fact it’s not a driver problem since STMLink tool is working properly.

STLink V2 and V2.1 are quite different since USB endpipes seems to be different.
There also seems to be problems with the fact that V2.1 are compound USB devices and that libusb is not so good with those things.
I think the problem is more an OpenOCD problem which has problems with V2.1 devices.

I see what you mean now, thanks for the clarification.

Perhaps if the ST-Link on the Nucleo/mBed device were re-flashed with the utility with a V2 binary, (like what is found on the older discovery kits). Hardware should be compatible, and if openOCD talks to a V2 just fine, maybe I can just try ditching the V2.1 firmware altogether?

Do you have experience flashing the V2.1 with the ST flash Utility?

I have made quite some research to reprogram the embedded stlink on the nucleo, but I haven’t been able to find anything concerning this procedure.
The stlink software enable to update firmware but not to choose the firmware you’ll be installing.
That feature would be very nice..

some possible things to try

If you have a previous openocd still running (check on the debug perspectiv)e close it as welel as any gdb open still leaving here. Any kind of zombie process will prevent any new sucessulf openocd conection to the tagret.

Can you get access to the same target on sameusb port with the stlink utility ?

Try others usb ports


I have 3 USB ports on this machine. Moving the one of the other ports did not change the behavior of openOCD.

I tried connecting and doing a full flash erase using St-Link Util on each of the ports, which went fine according to it’s output:

10:56:55 : ST-LINK SN : 066BFF515350836767133618
10:56:55 : ST-LINK Firmware version : V2J24M11
10:56:55 : Connected via SWD.
10:56:55 : SWD Frequency = 1,8 MHz.
10:56:55 : Connection mode : Connect Under Reset.
10:56:55 : Debug in Low Power mode enabled.
10:56:55 : Device ID:0x421
10:56:55 : Device flash Size : 512KBytes
10:56:55 : Device family :-STM32F446x
10:57:10 : Flash memory erased.

So I went a terminated and closed all debug perspectives, and tried a re-flash.

I got a new output:

Open On-Chip Debugger 0.9.0-dev-00418-g9afb8b4-dirty (2015-09-28-12:09)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/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 : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Error: libusb_open() failed with LIBUSB_ERROR_ACCESS
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

Looks like a driver problem to me, so I went and updated my St-Link drivers (again), but this produced the same output.


I manage to get things working when using a ST stlink USB dongle or a discovery board.
No success when using a nucleo (STM32L152RE). Have to check the nucleo L4.