-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[feature] MCU hotplug - Changing targets. #244
Comments
That is certainly a bug. I would say that it should either do as you say, and look for devices on GDB connect, or simply detect the device disconnect and exit. It isn't exactly a solution to your problem, but my typical workflow is to use a Bash function that will automatically start st-util and gdb, allowing me to start debugging with one command, without having st-util running continuously in the background.
https://github.com/prattmic/dotfiles/blob/master/aliases#L23 |
This behaviour is nice to have, but OpenOCD will also never support this. A more advanced mechanism needs to be designed and implemented to support this. There are two cases which the stlink library (and tools) are unable to detect (currently):
|
I'm closing this due to inactivity of the original issuer, and because it is not a common use-case. |
Calling me inactive?? Liar! :-) Ah well. Yeah I know I'm weird... |
Hahaha, I know you are alive you wizard 👍 I appreciate your feedback but there needs to be moved alot of work to have hot-plugging working cross-platform. As stated in libusb documentation it is supported on some platforms: http://libusb.sourceforge.net/api-1.0/hotplug.html. And for swd-only hotplug there needs to be some retrying as done in openocd. |
I would think that: "when GDB connects, check the CPU that is connected" is not very difficult and platform independent. If the CPU is not the one we expect, reinitialize the "what CPU do we have" part.... The "hotplug the STLINK" is probably more difficult. |
It has nothing todo with gdb, because st-util needs to attach/reattach to the (new)CPU. |
If "reconnect" is really necessary, then st-util already does that: I can change the attached CPU on the fly and st-util won't notice. The problem is that if I change to a different CPU, st-util will use the wrong flashing algorithm. So verifying the CPUID register at each gdb-connect would make st-util aware of the changed CPU. The easiest "fix" would be to just say: "whoa CPU changed, error, exiting". |
I leave "st-util -m" running in a corner and then "develop" stuff for my STM32 boards.
Sometimes I swap targets. disconnect the cable to one SWD connetor, connect the next target board.
st-util then doesn't notice the change. It never notices that a different processor is now connected. I'm not sure when would be appropriate to check the connected hardware. How about when gdb connects? I have to switch directories and compiler settings, and will quit and restart gdb in the new directory when starting to work on the other project.
The text was updated successfully, but these errors were encountered: