Just trying to build and run / debug the default, unedited STM32 project you get when you open STM32CubeIDE. After telling me I needed the download the ST-Link server for it to work, I did, then updated the board when prompted. It now gives me 'Info : stlinkserver already running, exit' and the program times out.
If it's already running, how can I turn it off? Or have I configured something incorrectly?
Related
We have a new team member trying to get started with our Godot project. VSCode is our standard editor. Everyone is using Fedora Linux. You can find the relevant files here:
https://github.com/redhat-gamedev/srt-godot-server/tree/main/.vscode
On my machine, when trying to run the launch configuration, the build task succeeds, and then the program is launched. Everything works fine.
On the new team member's machine, when trying to run the launch configuration, the build task succeeds, and then nothing happens. There are no errors. There is no output.
We tried running VSCode with an increased log level (debug), but the VScode log files don't show anything meaningful or related. We tried executing the equivalent launch command from the terminal/shell and it works fine. There are no errors, but the resulting built program executes successfully. Interestingly, running code --verbose does produce a ton of output but nothing super specific to the execution of the steps in the launch configuration. Also, code --verbose --log debug does not cause messages spit out of VSCode to be at the DEBUG log level. Everything is still INFO:
[4183395:0112/092541.932947:INFO:CONSOLE(616)] "%cTRACE color: #888 [File Watcher (parcel)] [CHANGED] ...
How can I debug a launch configuration in VSCode to see what's going on? Is there a way to make the launch configuration system of VSCode be more verbose?
I am following Parcel's "Building a web app with Parcel" to learn how to use it. The problem arises after I type in npx parcel src/index.html. The build runs fine and I can see the development server results just fine. The terminal becomes unresponsive afterwards. I can't type, quit, or anything. The only workaround is killing the terminal and restarting...which is very annoying. I've looked for answers, I've updated Node to the latest version, but to no avail. This doesn't happen when I use Webpack or any other time. Here is a screen shot just in case that helps. Could someone please help this unworthy noob out? Screen shot of terminal and VSCode
When you just run npx parcel, it starts a development server that will continue to run until you exit. This development server will watch for changes that you make as you develop and will reload your project, so you don't need to restart/rebuild every time you make changes.
The reason you can't type anything into the terminal (or, at least, that the terminal doesn't respond when you do) is that the development server is still running in that terminal. You have to exit the development server before the terminal prompt will re-appear and you can use it as normal.
To exit any program running in a terminal, you can type Control+C (hold down the Control key and hit the "c" key). This works for any terminal program, not just parcel. This will exit the development server program and you'll get your terminal prompt back.
There are other things you can do with programs (or "jobs") in the terminal window. You can read more about them here and here.
But you should use the development server to your advantage. Keep it running while you work. If you need to use the terminal while it's running, just open up another terminal window.
When you finally want to build your app/site, run parcel build instead.
You can read more about all of this here: https://parceljs.org/getting-started/webapp/
I have a really wired problem (or a bug) on vscode. I can "attach chrome" debugging totally fine usually,
but after some random time connecting to the chrome instance (may be a couple of hours or 8 hours, like I left it connected while I'm sleeping), it automatically disconnect the debugging,
then when I try to re-run attach chrome to reconnect it, for some weird reason it doesn't connect to the instance.
It's not a failed, it's not like "cannot connect to the port 9222", it's infinitely trying to connect showing the left up side blue indicator left to right.
This is my second time to encounter this weird problem. For the first time I even don't know how I solved the issue. maybe I just waited its reconnect for an hour or like that.
The first things I happened to think from the problem is simply its port conflict. So I checked vscode side's (I mean I use vscode in the remote ssh mode from Windows to Linux Ubuntu) port and process, used htop to filter port "9222" or process "chrome", but I didn't find anything stucking there. So I assume in the linux side the debugging process is exiting successfully.
So I did the same on the Windows side, I used resource monitor to check port "9222", no running process. If I re-open a 9222 debugging enable chrome, then it appears. closing, it disappears. It seems there is no problem here as well.
I then checked vscode's version. I was using vscode 1.64.2 so I side-installed 1.65.2 and 1.66.1 (the latest) and tested it. Doesn't work.
"refreshing the window" doesn't work. closing the window and re-open, doesn't work.
So what can I do?
Did you just install some new extensions in Visual Studio Code? I found that I had this exact same behaviour, "infinitely trying to connect showing the left up side blue indicator left to right", after I installed Karma Test Explorer and Test Explorer UI extensions. Once I uninstalled those extensions, debugging started working again.
I need to debug a program on a server and would like to still have its output in GDB.
The following "works" in general:
manual started (terminal) task that opens a ssh connection, does the necessary pre-setup (server-side scripts), then runs gdbserver --multi :12345
GDB debug configuration that runs in attach mode and executes the appropriate command chain "set sysroot remote:", "target extended-remote myserver:12345", "set remote exec-file /path/to/myfile", "run"
I know see the program running and stopping on the breakpoint, see the program's output in the integrated terminal and can toggle to the debugging console. But how can I see both the debugging console and the integrated terminal at once?
If somehow possible I'd like to not use an external window for one of those, as there are multiple vscode instances open - each connecting to a different server - and multiple windows "mgically" belonging to each other would make debugging harder together - the integrated option solves this problem completely.
The Views and Panels (Problems - Terminal - Output - Debug console) can be moved.
Click on the header/Tab of the View/Panel and drag the mouse to the new location.
The mouse pointer will change if it is possible to drop it.
You can restore a panel/view to the original location from the context menu on the top-bar.
I have looked in the doc but could not find any mentioning of this. It was mentioned in one of the Release notes.
I'm using a Nucleo STM32L031 with AC6 STM32 workbench (eclipse).
I write my application and go to debug mode, everthing was working well until I add another function in my application. I notice that when I remove/comment the "new_function", the software can go to debug mode again. However when I add the "new_function" to the code and go to debug, an error occurs and it cannot go to debug mode.
Error: Error in final launch sequence
Failed to execute MI command:
load C:Project_STM32L031K6-Nucleo\\Debug\\Project.elf
Error message from debugger back end:
Error erasing flash with vFlashErase packet
Error erasing flash with vFlashErase packet
This error does not occur only for this specific "new_function", but also for other functions e.g TIM21_Init() generated by STM32Cube.
I tried to search for the solution, but couldn't find it.
Thanks
Bien
In my case (stm32f429) changing this option helped:
This is an OpenOCD issue, not a problem with your code. I got this issue when the debugger command file was referring to a "stlink-v2-1" but what I actually have is an "stlink-v2". I'm using the STM32F0 Discovery board.
I believe the Nucleo board has the "stlink-v2-1" so you might have the opposite problem as me. Check to make sure that the setting under "Run menu > Debug Configurations > Debugger > OpenOCD setup" is set to the correct debugger.
If a debug configuration file is being used (the "use default script" or "use local script" option is selected) open that file and look for a line like:
source [find interface/stlink-v2.cfg]
In my case the project wizard had created a template that was referencing stlink-v2-1. Changing it to the above fixed the problem.
UPDATE:
I also got this problem when Eclipse crashed and left OpenOCD running in the background. Run
$ ps aux | grep openocd
And if you see an instance of OpenOCD running when the debugger is not, kill it.