Thank you so much for such an easy to understand and informative video. I've wanted to learn how to use GDB with VS Code for my bare-metal work for quite some time and now I finally can! I really appreciate you taking the time to do this!!
I am trying the same right now. Up to this moment doesn't work yet. It seems to me that some keys used above in the video has been changed to something else, therefore the current Cortex-Debug plugin doesn't get configured properly.
Thanks for your great work! It would be nice if you could enable subtitles, they're good help when english is not first language and there are certain fine subtleties in the speech
2 года назад
Thank you for the comment. I'm aware that I might pronounce some words badly, but I try to speak as clearly as possible. I see that there are no auto generated subtitles, but other videos have them. I'll see what I can do.
@ Thanks for your response. Not badly, just some homophones issues :) I just noticed that: some of your other videos have subtitles By the way: Do you have any experience with bare metal programming of STM32 CAN peripheral? I'm trying to build a RIOT socketcan driver and I'm having some trouble getting it to work.
2 года назад
I will be learning can this year for a project, but It's on an fpga and it might be late for you. I'm then going to try on stm as well and maybe make a video.
@ Great. By then maybe I can contribute something if needed I finished yesterday the config according to your video. I added some details like ${cwd} for make and modified $PATH Thanks again for your excellent tutorial
the update to j-link on the firmware V2.J36.S7 and V2.J37.S7 doesnt work, downgrade doesnt work :( in ST-Link Reflash ive got ERROR: Unsupported ST-LINK firmware how to fix that? EDIT: it working on nucleo, doesn't working on original st link v2
A small warning regarding the optimization levels -O0 because i spent a few hours because of this. On specific models (32F4, 32F3 and probably others) usart, character received interrupt breaks. The RXNE bit fails to reset.. Also debugger breakpoints sometimes make the uart to break until the device is power cycled
2 года назад+1
I have not heard of this problem and I will try to replicate it. Were you using reading RX with interrupts or dma or polling? I have experienced a well known bug with trasmitting with dma and it's a problem when the peripheral will transmit only once and never again. Problem is solved by enabling UART interrupts so that when the transmit is finished, interrupt is called and HAL will clear bussy flag inside interrupt routine. Link for references: community.st.com/s/question/0D50X00009XkgtY/dma-uart-with-hal-remain-busy-bug
@ sorry, i missed the original relly. I was using a char received interrupt. actually the problem was the debugger after all, but it was very hard to pin it down. What i notished is that i have to avoid, under all circumstances, to have a breakpoint in the interrupt, or else the interrupt will not rearm. My theory is that the required bit was expected to update with a clock edge that its missed because of the breakpoint. After that and resuming the normal execution, no interrupt will be trigger again which doesnt change even if i press the reset button. The only solution was to power cycle the board. If you want me i can retrace my steps in an email. With that being said, i just started working with Arm so i have about a week of experience overall. I may be doing something completely stupid somewhere.
2 года назад+1
Interrupts represent great solutions, but come with a mountain of potential problems, that you will have. First I would suggest to read up on the UART - interrupt receive workflow. I just took a look into HAL api and it looks like HAL_UART_Receive_IT will store 'Size' amount of character into a buffer and it will call Receive Complete Callback to let you know. You can use that interrupt function to catch that event. After you parse your data and you are redy to receive more, then just call HAL_UART_Receive_IT again. This will ensure that if you put your breakpoint to where the peripheral is finished receiving, you should not have any more problems. I will be making a video on interrupt safety in the future :)
@ thank you for your response. Sadly i know, i do have mcu experience, just not with arm yet. i did a glance at HAL library and went directly on register programming. Partly because i like to hurt myself, but most importantly because i found Hal to be severely lacking. Messages that i have are of arbitary length and CLCR terminated so i couldnt know how many chars i would receive beforehand to set the hal interrupts, so i did the byte by byte approach, saving the complete message on a queue to be processed later. Unfortunately i dont know all the traps for this architecture yet, and here we are. ;). With that being said, cant wait for your next videos
2 года назад+1
i understand your concern. I have (currently as well) worked with parsing messages of arbitrary length. In short: I used a large buffer, that it could hold a few times the maximum length Then from main with a function I have a static index that holds the last position in buffer that I have checked. I also read current DMA pointer location/index to know, where the last received character is placed. Then I just use another function that checks for a potential message between those two locations. At the end I update the last position index. I rely on the fact that I parse messages from main faster than the messages are comming. This is not very timing accurate, but plenty fast enaugh. I hope this gives you an idea. This implementation, at least, does not need interrupts and that's one problem generator less. Cheers.
Thank you so much for this video! I got my stutil based debug running however it works only once. When I hit stop and try to hit run again later, I get the below error (I am using a Mac). If I force-close “st-util” and re-run, it works again! What am I missing ? SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session connected libusb: warning [darwin_open] USBDeviceOpen: another process has device opened for exclusive access libusb: warning [darwin_open] USBDeviceOpen: another process has device opened for exclusive access libusb: error [darwin_claim_interface] USBInterfaceOpen: another process has device opened for exclusive access st-util 2021-10-19T20:20:04 WARN usb.c: Stlink usb device found, but unable to claim (probably already in use?) 2021-10-19T20:20:04 DEBUG common.c: *** stlink_close ***
2 года назад
I will test this on the latest versions that I can get on my system and report back to you.
I have anpplication that has a bootloader and a main application ,2 bin files and one dfu file, i see the previous developer generated elf file for bootloader... when i try to debug I only get disassembly view and not C code... any clue how to go about getting it to show me the C code when stepping through
2 года назад
I haven't worked much with dual binaries, but I would assume that either elf file has not been compiled with debug symbols (-g3, -ggdb) or that you don'h have the source code, there fore it cannot step it. Also, the fact that you have two main functions for bootloader and the application might confuse vscode, but I'm not sure.
@ it confuses gdb for sure when i put a break at main it sets it in bootloader main and application main. Either way since this application is RTOS based, steppig through code is sometimes pointless since the very next line is not guaranteed to be what you expect
2 года назад
That's an interesting problem. I haven't had a need for a custom bootloader, but I might take a look. I have worked with freertos in classes, but not in work, only bare metal event loops and interrupts.
Hi sorry for asking again. I run into another problem and I hope it is ok to ask again. Now I can run the debugger using st-util and arm-none-eabi-gdb on VSCode, but it will not stop at the beginning(main). It seems that it will run first and after a random amount of cycles then pause, in the while(1) loop. Below is my "launch.json file", I do add the "runToEntryPoint" tag: "configurations": [ { "name": "ST-Link Debug", "cwd": "${workspaceFolder}", "executable": "./build/CPP_Test.elf", "device": "STM32F407VE", "request": "launch", "type": "cortex-debug", "runToEntryPoint": "main", "servertype": "stutil", "interface": "swd" } and here is the debug output: ``` Reading symbols from /home/ben/stm32_tools/abe_build/builds/destdir/x86_64-pc-linux-gnu/bin/arm-none-eabi-objdump --syms -C -h -w /home/ben/stm32_ws/CPP_Test/build/CPP_Test.elf Reading symbols from /home/ben/stm32_tools/abe_build/builds/destdir/x86_64-pc-linux-gnu/bin/arm-none-eabi-nm --defined-only -S -l -C -p /home/ben/stm32_ws/CPP_Test/build/CPP_Test.elf Launching GDB: /home/ben/stm32_tools/abe_build/builds/destdir/x86_64-pc-linux-gnu/bin/arm-none-eabi-gdb -q --interpreter=mi2 /home/ben/stm32_ws/CPP_Test/build/CPP_Test.elf Set "showDevDebugOutput": true in your "launch.json" to see verbose GDB transactions here. Helpful to debug issues or report problems Launching gdb-server: /usr/local/bin/st-util -p 50000 --no-reset Please check TERMINAL tab (gdb-server) for output from /usr/local/bin/st-util Finished reading symbols from objdump: Time: 35 ms Finished reading symbols from nm: Time: 41 ms Reading symbols from /home/ben/stm32_ws/CPP_Test/build/CPP_Test.elf... Warning: 'set target-async', an alias for the command 'set mi-async', is deprecated. Use 'set mi-async'. 0x08004250 in main () at Core/Src/main.cpp:98 98 n++; Program stopped, probably due to a reset and/or halt issued by debugger Note: automatically using hardware breakpoints for read-only addresses. Run to 'main' timed out. Trying to pause program ``` I'm not suire if it has something to do with the 5th line when launching gdb-server it use the "--no-reset " flag. Thank you very much !!
2 года назад
I'm late, but let me give my thoughts. I hade some weird errors with debugging and most of the time it came from st-util. It works mostly fine, but sometimes a strange version just sends it. I've been using a workaround: cortex-debug supports stlink as well, debugger used by STM32CubeIDE. You can give the debug plugin the path to the debugger: Install CubeIDE somewhere, I have a folder in $HOME for this sort of stuff: ~/Software/STM32CubeIDE-1.8.0 You can find the debugger in there: cortex-debug.stlinkPath": "/home/matej/Software/STM32CubeIDE-1.8.0/plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_2.0.100.202109301221/tools/bin/ST-LINK_gdbserver" Also, before you throw away st-util, make sure that you have a path in settings.json!
Thank you for your time.. But still I'm not able to run my debugging and I don't get why, I cofigured everything like in your video and also tried everything else... doesn't work
Год назад
Sometimes plugins have unstable update. You should use debug logger (one of the tabs on the bottom) and terminal/gdb output to determine which part is not working. You have target gdb server -> arm-gdb -> cortex debug.
Hi, not sure if you're still answering these questions, but I'll try anyway. I was able to configure debugging with st-util and it's nice as it can be targeted correctly by specifying serial numbers, as I often work with multiple devices connected to my PC. On the other hand, I can't get Live Watch to work with stutil, that's why I have another openocd configuration that manages to display Live Watch. The thing is that openocd doesn't target specific board even though I use serial number in the configuration. Any idea how I can get everything working on one debug server?
Thanks for this. I have a couple questions if you’re open to GI ring a couple answers. I have several Nucleo, Discovery, blue pill, and black pill (stm32f411 version) . 1) What are the differences between Jlink and STlink features? 2) There is a new STLink V3. Can you update a V2.0 or 2.1, or black pill to V3?
3 года назад+1
tldr: For basic download and debug it doesn't matter. Try both for yourself and your use case. Stlink is cheaper and comes with dev boards, but can be limiting in debugging. The most important difference is that stlink is only for stm32 and jlink is universal. If we talk about the independant devices, which both companies sell, that is the difference. Jlink by Segger is a product of a company that is focused on debuggers and all the software for debugging and testing therefore it's much more powerfull and the fact that they support all OS platforms with frequent updates is great. Stlink is also provided as on-board debugger for the dev boards. It does everything you need as far as downloading code, debugging, basic swo trace, etc. It is somewhat limited to official CubeProgrammer and I rely on open source tools to use on linux and in development environment. As far as stlink v3 goes I have no experience with it. It looks as un update to v2, hardware as well so probably not upgradable from v2, as I have also seen it on some newer dev boards as well, but it's also sold separate. It hase more gpio, it's faster and more expandable, but still just for stm32. I use for my development and learning the jlink edu which has cost me 50e. It is great, software works very fast and never had an issue, unlike stlink. I kind of forgive stlink as I see it more as a startup tool to get prototyping and learning as fast as possible without worrying about debuggers. Software support is very rich both the company and other plugins, like vscode.
@ Wow, best and most complete answer I have ever gotten from asking anyone a question on RUclips. Thank you! I may buy a "SEGGER J-Link EDU Mini " I ran across. It's only $20 and and official product not a knockoff.
Hello I loved the video, but I am in a bit of a problem. I can get the debugger working both in windows and linux. But on both systems it is really slow, especialy compared to your video. It takes a long time for visual studio to know where it reached a break point even though the debugger reports it nearly instantly. Do you have any idea what it could be. On windows it even goes as far where gdb completely crashes after stepping a couple times. After the breakpoint is reached the gdb server will start reading register addresses which take about 10+ seconds. If the breakpoint is hit multiple times it will work fast, but a new breakpoint again is very slow. Do you by any chance know what the problem could be?
2 года назад
I have also seen this on one of my computers. My main pc work fine. I will check what could be the probem, I could only think vscode or cortex debug, jlink gdb or arm gdb.
2 года назад
So my main pc that works fine has these versions: vscode: 1.60.2 cortex-debug plugin: 0.4.6 preview, gcc-arm-none-eabi package: 10.2.1 (20201103 release) segger J-link gdb server v7.52c My other one that has that issue: vscode: 1.60.2 cortex-debug plugin: 0.4.6 preview, gcc-arm-none-eabi package: 10.3.1 (20210621 release) segger J-link gdb server v7.52b All my PCs run Fedora 34 with latest updates, apart from hardware, they are almost identical.
I think most likely the gdb version and jlink gdb server version mismatch. I will try installing an older version of arm-none-eabi-gdb and post the results!
2 года назад
I have just changed the arm gdb version and it looks like the newest version (10.3.1) has a problem.
Thank you for making this seires!! It realy help me a lot~ But I run into some problem when executing arm-none-eabi-gdb, and I cannot find any valid answer online. So I'm wondeing maybe I can ask here. When I execute arm-none-eabi-gdb, it has the following error: Could not find platform independent libraries Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] Fatal Python error: Py_Initialize: Unable to get the locale encoding ModuleNotFoundError: No module named 'encodings' Current thread 0x00007f75639ddc00 (most recent call first): Aborted (core dumped) And I've checked that I install python & python3 correctly. Have your ever ran into this kind of bug? Thank you very much~
2 года назад+1
I haven't seen this error, looks like vscode/plugin related. Some suggest reinstalling python2 and python3 and all the packages you use. Some suggest less drastic changes: stackoverflow.com/questions/38132755/importerror-no-module-named-encodings When in doubt and out of ideas, reinstall all the tools.
@ Thank you for your advice ~ I took your advice and reinstall my os but it still doesn't work. Then I thought maybe build from source will solve the dependency problem. And the target built from source work!! But the one download directly sitll not working. But I guess it doesn't matter anymore~~
The timing of this video was perfect. This is something I was just looking into and then you came along. You are doing good work here!
Thank you so much for such an easy to understand and informative video. I've wanted to learn how to use GDB with VS Code for my bare-metal work for quite some time and now I finally can! I really appreciate you taking the time to do this!!
you sir, are a saint!
Great and useful videos. Thank You, Matej
Thanks. These was one of the few videos i watched that was worth it . Keep up the good work !!!!.
This helped me a lot in setting up my VSCode for a Zephyr project on a ST Nucleo board.
I am trying the same right now. Up to this moment doesn't work yet. It seems to me that some keys used above in the video has been changed to something else, therefore the current Cortex-Debug plugin doesn't get configured properly.
Bro, your videos are awesome, keep up the great work!
great videos! thanks super nice to use visual code and stm32 this way
Amazing video, so useful!
Another fantastic tutorial thank you!
Thanks for your great work! It would be nice if you could enable subtitles, they're good help when english is not first language and there are certain fine subtleties in the speech
Thank you for the comment. I'm aware that I might pronounce some words badly, but I try to speak as clearly as possible. I see that there are no auto generated subtitles, but other videos have them. I'll see what I can do.
@ Thanks for your response. Not badly, just some homophones issues :)
I just noticed that: some of your other videos have subtitles
By the way:
Do you have any experience with bare metal programming of STM32 CAN peripheral? I'm trying to build a RIOT socketcan driver and I'm having some trouble getting it to work.
I will be learning can this year for a project, but It's on an fpga and it might be late for you. I'm then going to try on stm as well and maybe make a video.
@ Great. By then maybe I can contribute something if needed
I finished yesterday the config according to your video. I added some details like ${cwd} for make and modified $PATH
Thanks again for your excellent tutorial
Thanks a lot for the video, I have a JLink up running without any problems. Sadly Cortex-Debug still doesnt support SWO for ST-Link.
受益良多, 感谢
the update to j-link on the firmware V2.J36.S7 and V2.J37.S7 doesnt work, downgrade doesnt work :(
in ST-Link Reflash ive got ERROR: Unsupported ST-LINK firmware
how to fix that?
EDIT:
it working on nucleo, doesn't working on original st link v2
great videos!
A small warning regarding the optimization levels -O0 because i spent a few hours because of this. On specific models (32F4, 32F3 and probably others) usart, character received interrupt breaks. The RXNE bit fails to reset..
Also debugger breakpoints sometimes make the uart to break until the device is power cycled
I have not heard of this problem and I will try to replicate it. Were you using reading RX with interrupts or dma or polling?
I have experienced a well known bug with trasmitting with dma and it's a problem when the peripheral will transmit only once and never again. Problem is solved by enabling UART interrupts so that when the transmit is finished, interrupt is called and HAL will clear bussy flag inside interrupt routine.
Link for references: community.st.com/s/question/0D50X00009XkgtY/dma-uart-with-hal-remain-busy-bug
@ sorry, i missed the original relly. I was using a char received interrupt. actually the problem was the debugger after all, but it was very hard to pin it down. What i notished is that i have to avoid, under all circumstances, to have a breakpoint in the interrupt, or else the interrupt will not rearm. My theory is that the required bit was expected to update with a clock edge that its missed because of the breakpoint. After that and resuming the normal execution, no interrupt will be trigger again which doesnt change even if i press the reset button. The only solution was to power cycle the board. If you want me i can retrace my steps in an email. With that being said, i just started working with Arm so i have about a week of experience overall. I may be doing something completely stupid somewhere.
Interrupts represent great solutions, but come with a mountain of potential problems, that you will have.
First I would suggest to read up on the UART - interrupt receive workflow. I just took a look into HAL api and it looks like HAL_UART_Receive_IT will store 'Size' amount of character into a buffer and it will call Receive Complete Callback to let you know. You can use that interrupt function to catch that event. After you parse your data and you are redy to receive more, then just call HAL_UART_Receive_IT again. This will ensure that if you put your breakpoint to where the peripheral is finished receiving, you should not have any more problems.
I will be making a video on interrupt safety in the future :)
@ thank you for your response. Sadly i know, i do have mcu experience, just not with arm yet. i did a glance at HAL library and went directly on register programming. Partly because i like to hurt myself, but most importantly because i found Hal to be severely lacking. Messages that i have are of arbitary length and CLCR terminated so i couldnt know how many chars i would receive beforehand to set the hal interrupts, so i did the byte by byte approach, saving the complete message on a queue to be processed later. Unfortunately i dont know all the traps for this architecture yet, and here we are. ;). With that being said, cant wait for your next videos
i understand your concern. I have (currently as well) worked with parsing messages of arbitrary length.
In short: I used a large buffer, that it could hold a few times the maximum length Then from main with a function I have a static index that holds the last position in buffer that I have checked. I also read current DMA pointer location/index to know, where the last received character is placed. Then I just use another function that checks for a potential message between those two locations. At the end I update the last position index. I rely on the fact that I parse messages from main faster than the messages are comming. This is not very timing accurate, but plenty fast enaugh.
I hope this gives you an idea. This implementation, at least, does not need interrupts and that's one problem generator less. Cheers.
Thank you so much for this video! I got my stutil based debug running however it works only once. When I hit stop and try to hit run again later, I get the below error (I am using a Mac). If I force-close “st-util” and re-run, it works again! What am I missing ?
SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session connected
libusb: warning [darwin_open] USBDeviceOpen: another process has device opened for exclusive access
libusb: warning [darwin_open] USBDeviceOpen: another process has device opened for exclusive access
libusb: error [darwin_claim_interface] USBInterfaceOpen: another process has device opened for exclusive access
st-util
2021-10-19T20:20:04 WARN usb.c: Stlink usb device found, but unable to claim (probably already in use?)
2021-10-19T20:20:04 DEBUG common.c: *** stlink_close ***
I will test this on the latest versions that I can get on my system and report back to you.
I have anpplication that has a bootloader and a main application ,2 bin files and one dfu file, i see the previous developer generated elf file for bootloader... when i try to debug I only get disassembly view and not C code... any clue how to go about getting it to show me the C code when stepping through
I haven't worked much with dual binaries, but I would assume that either elf file has not been compiled with debug symbols (-g3, -ggdb) or that you don'h have the source code, there fore it cannot step it. Also, the fact that you have two main functions for bootloader and the application might confuse vscode, but I'm not sure.
@ it confuses gdb for sure when i put a break at main it sets it in bootloader main and application main. Either way since this application is RTOS based, steppig through code is sometimes pointless since the very next line is not guaranteed to be what you expect
That's an interesting problem. I haven't had a need for a custom bootloader, but I might take a look. I have worked with freertos in classes, but not in work, only bare metal event loops and interrupts.
Hi sorry for asking again. I run into another problem and I hope it is ok to ask again.
Now I can run the debugger using st-util and arm-none-eabi-gdb on VSCode, but it will not stop at the beginning(main).
It seems that it will run first and after a random amount of cycles then pause, in the while(1) loop. Below is my "launch.json file", I do add the "runToEntryPoint" tag:
"configurations": [
{
"name": "ST-Link Debug",
"cwd": "${workspaceFolder}",
"executable": "./build/CPP_Test.elf",
"device": "STM32F407VE",
"request": "launch",
"type": "cortex-debug",
"runToEntryPoint": "main",
"servertype": "stutil",
"interface": "swd"
}
and here is the debug output:
```
Reading symbols from /home/ben/stm32_tools/abe_build/builds/destdir/x86_64-pc-linux-gnu/bin/arm-none-eabi-objdump --syms -C -h -w /home/ben/stm32_ws/CPP_Test/build/CPP_Test.elf
Reading symbols from /home/ben/stm32_tools/abe_build/builds/destdir/x86_64-pc-linux-gnu/bin/arm-none-eabi-nm --defined-only -S -l -C -p /home/ben/stm32_ws/CPP_Test/build/CPP_Test.elf
Launching GDB: /home/ben/stm32_tools/abe_build/builds/destdir/x86_64-pc-linux-gnu/bin/arm-none-eabi-gdb -q --interpreter=mi2 /home/ben/stm32_ws/CPP_Test/build/CPP_Test.elf
Set "showDevDebugOutput": true in your "launch.json" to see verbose GDB transactions here. Helpful to debug issues or report problems
Launching gdb-server: /usr/local/bin/st-util -p 50000 --no-reset
Please check TERMINAL tab (gdb-server) for output from /usr/local/bin/st-util
Finished reading symbols from objdump: Time: 35 ms
Finished reading symbols from nm: Time: 41 ms
Reading symbols from /home/ben/stm32_ws/CPP_Test/build/CPP_Test.elf...
Warning: 'set target-async', an alias for the command 'set mi-async', is deprecated.
Use 'set mi-async'.
0x08004250 in main () at Core/Src/main.cpp:98
98 n++;
Program stopped, probably due to a reset and/or halt issued by debugger
Note: automatically using hardware breakpoints for read-only addresses.
Run to 'main' timed out. Trying to pause program
```
I'm not suire if it has something to do with the 5th line when launching gdb-server it use the "--no-reset
" flag. Thank you very much !!
I'm late, but let me give my thoughts. I hade some weird errors with debugging and most of the time it came from st-util. It works mostly fine, but sometimes a strange version just sends it.
I've been using a workaround: cortex-debug supports stlink as well, debugger used by STM32CubeIDE. You can give the debug plugin the path to the debugger:
Install CubeIDE somewhere, I have a folder in $HOME for this sort of stuff: ~/Software/STM32CubeIDE-1.8.0
You can find the debugger in there:
cortex-debug.stlinkPath": "/home/matej/Software/STM32CubeIDE-1.8.0/plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_2.0.100.202109301221/tools/bin/ST-LINK_gdbserver"
Also, before you throw away st-util, make sure that you have a path in settings.json!
I met exactly the same problem as you describe. jlink works fine, but stutil never stops before while(1) loop
Thank you for your time.. But still I'm not able to run my debugging and I don't get why, I cofigured everything like in your video and also tried everything else... doesn't work
Sometimes plugins have unstable update. You should use debug logger (one of the tabs on the bottom) and terminal/gdb output to determine which part is not working. You have target gdb server -> arm-gdb -> cortex debug.
Anyone know how to get live expressions working with this method?
The plugin supports st-link that comes with Stm32CubeIde. Maybe give that a try. I'll test it sometime in the future.
Hi, not sure if you're still answering these questions, but I'll try anyway. I was able to configure debugging with st-util and it's nice as it can be targeted correctly by specifying serial numbers, as I often work with multiple devices connected to my PC. On the other hand, I can't get Live Watch to work with stutil, that's why I have another openocd configuration that manages to display Live Watch. The thing is that openocd doesn't target specific board even though I use serial number in the configuration. Any idea how I can get everything working on one debug server?
Actually, i just switched servertype from "stutil" to "stlink" and now everything works like a charm
@@herantd thank you for sharing, I was getting stuck with 'Failed to launch GDB: protocol error with Rcmd'. This change got me up and running.
Thanks for this. I have a couple questions if you’re open to GI ring a couple answers. I have several Nucleo, Discovery, blue pill, and black pill (stm32f411 version) .
1) What are the differences between Jlink and STlink features?
2) There is a new STLink V3. Can you update a V2.0 or 2.1, or black pill to V3?
tldr: For basic download and debug it doesn't matter. Try both for yourself and your use case. Stlink is cheaper and comes with dev boards, but can be limiting in debugging.
The most important difference is that stlink is only for stm32 and jlink is universal. If we talk about the independant devices, which both companies sell, that is the difference. Jlink by Segger is a product of a company that is focused on debuggers and all the software for debugging and testing therefore it's much more powerfull and the fact that they support all OS platforms with frequent updates is great.
Stlink is also provided as on-board debugger for the dev boards. It does everything you need as far as downloading code, debugging, basic swo trace, etc. It is somewhat limited to official CubeProgrammer and I rely on open source tools to use on linux and in development environment.
As far as stlink v3 goes I have no experience with it. It looks as un update to v2, hardware as well so probably not upgradable from v2, as I have also seen it on some newer dev boards as well, but it's also sold separate. It hase more gpio, it's faster and more expandable, but still just for stm32.
I use for my development and learning the jlink edu which has cost me 50e. It is great, software works very fast and never had an issue, unlike stlink. I kind of forgive stlink as I see it more as a startup tool to get prototyping and learning as fast as possible without worrying about debuggers. Software support is very rich both the company and other plugins, like vscode.
@ Wow, best and most complete answer I have ever gotten from asking anyone a question on RUclips. Thank you! I may buy a "SEGGER J-Link EDU Mini " I ran across. It's only $20 and and official product not a knockoff.
Hello I loved the video, but I am in a bit of a problem. I can get the debugger working both in windows and linux. But on both systems it is really slow, especialy compared to your video. It takes a long time for visual studio to know where it reached a break point even though the debugger reports it nearly instantly. Do you have any idea what it could be. On windows it even goes as far where gdb completely crashes after stepping a couple times.
After the breakpoint is reached the gdb server will start reading register addresses which take about 10+ seconds. If the breakpoint is hit multiple times it will work fast, but a new breakpoint again is very slow. Do you by any chance know what the problem could be?
I have also seen this on one of my computers. My main pc work fine. I will check what could be the probem, I could only think vscode or cortex debug, jlink gdb or arm gdb.
So my main pc that works fine has these versions:
vscode: 1.60.2
cortex-debug plugin: 0.4.6 preview,
gcc-arm-none-eabi package: 10.2.1 (20201103 release)
segger J-link gdb server v7.52c
My other one that has that issue:
vscode: 1.60.2
cortex-debug plugin: 0.4.6 preview,
gcc-arm-none-eabi package: 10.3.1 (20210621 release)
segger J-link gdb server v7.52b
All my PCs run Fedora 34 with latest updates, apart from hardware, they are almost identical.
I think most likely the gdb version and jlink gdb server version mismatch. I will try installing an older version of arm-none-eabi-gdb and post the results!
I have just changed the arm gdb version and it looks like the newest version (10.3.1) has a problem.
@ Yes I can confirm this now. Jlink also definitely works a bit faster than st-util. Thanks for all your effort!
HI does this work for clone stm32 chip?
I haven't worked with a clone, not that I would be aware of. I have a kind of clone from giga devices, gd32f3 something, but I haven't used it yet.
Da li drzis casove stm32 programiranja?
如果能配上字幕就更好了, 英文听起来,太费劲
Thank you for making this seires!! It realy help me a lot~
But I run into some problem when executing arm-none-eabi-gdb, and I cannot find any valid answer online. So I'm wondeing maybe I can ask here.
When I execute arm-none-eabi-gdb, it has the following error:
Could not find platform independent libraries
Could not find platform dependent libraries
Consider setting $PYTHONHOME to [:]
Fatal Python error: Py_Initialize: Unable to get the locale encoding
ModuleNotFoundError: No module named 'encodings'
Current thread 0x00007f75639ddc00 (most recent call first):
Aborted (core dumped)
And I've checked that I install python & python3 correctly. Have your ever ran into this kind of bug? Thank you very much~
I haven't seen this error, looks like vscode/plugin related. Some suggest reinstalling python2 and python3 and all the packages you use.
Some suggest less drastic changes:
stackoverflow.com/questions/38132755/importerror-no-module-named-encodings
When in doubt and out of ideas, reinstall all the tools.
@ Thank you for your advice ~ I took your advice and reinstall my os but it still doesn't work. Then I thought maybe build from source will solve the dependency problem. And the target built from source work!! But the one download directly sitll not working. But I guess it doesn't matter anymore~~
Hello Can you please give us your email , ???
I'm currently not doing work outside of this youtube channel. If you have a question regarding a video's topic, please post it there and I'll respond.
lol, what are you kidding? He's not your personal tech support guy.