MCU hotplug - Stlink can't recover from MCU hotplug
poglazov opened this issue · comments
- Programmer/board type: Stlink/v2
- Programmer firmware version: don't know how to get it
- Operating system: Ubuntu 16.04.1 LTS 4.4.0-31-generic #50-Ubuntu SMP
- Stlink tools version and/or git commit hash: a781594
- Stlink commandline tool name:
st-info,st-flash, probably any - Target chip (and optional board): STM32F030C6T6
Steps to reproduce:
- Connected my device using STM32F030C6T6 to Stlink/v2 programmer.
- Flashed it succesfully.
- Disconnected my device from programmer, DON'T disconnect programmer from laptop's USB.
- Connected the device to programmer again.
- Tried to flash it with the same command or even just got any information and get error.
Output:
pavel@pavel-UX31A:~/stlink$ ./st-flash --reset write ../Desktop/WB-MSW_2.0.1.bin 0x8000000
2016-07-26T13:27:41 INFO src/stlink-common.c: Loading device parameters....
2016-07-26T13:27:41 INFO src/stlink-common.c: Device connected is: F0 small device, id 0x10006444
2016-07-26T13:27:41 INFO src/stlink-common.c: SRAM size: 0x1000 bytes (4 KiB), Flash: 0x8000 bytes (32 KiB) in pages of 1024 bytes
2016-07-26T13:27:42 INFO src/stlink-common.c: Attempting to write 19860 (0x4d94) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08004c00 erased
2016-07-26T13:27:42 INFO src/stlink-common.c: Finished erasing 20 pages of 1024 (0x400) bytes
2016-07-26T13:27:42 INFO src/stlink-common.c: Starting Flash write for VL/F0/F3 core id
2016-07-26T13:27:42 INFO src/stlink-common.c: Successfully loaded flash loader in sram
19/19 pages written
2016-07-26T13:27:43 INFO src/stlink-common.c: Starting verification of write complete
2016-07-26T13:27:44 INFO src/stlink-common.c: Flash written and verified! jolly good!
pavel@pavel-UX31A:~/stlink$ ./st-flash --reset write ../Desktop/WB-MSW_2.0.1.bin 0x8000000
[!] send_recv
[!] send_recv
[!] send_recv
[!] send_recv
[!] send_recv
2016-07-26T13:28:18 INFO src/stlink-common.c: Loading device parameters....
[!] send_recv
2016-07-26T13:28:18 ERROR src/stlink-common.c: Failed to read core_id
[!] send_recv
2016-07-26T13:28:18 WARN src/stlink-common.c: unknown chip id! 0x19c6010
pavel@pavel-UX31A:~/stlink$ ./st-info --descr
[!] send_recv
[!] send_recv
[!] send_recv
[!] send_recv
[!] send_recv
[!] send_recv
[!] send_recv
Expected/description:
If disconnect programmer from USB and connect again error goes away. Now I use special script from here to reset USB port before flashing: http://askubuntu.com/questions/645/how-do-you-reset-a-usb-device-from-the-command-line
I think this has something todo with the programmer firmware itself, as it is in a state where it has the old target remembered and you hot-plug your target. Currently the tools can not recover from this, as the programmer needs probably a jtag reset. Normaly when this occurs the tools should try to recover and reset the programmer into a know state. I have seen this kind of behaviour.
When you reset the usb port with a script it reinitialized the programmer and the stlink tools then run from a clean state.
This is related to the older issue #244.
Thank you for your answer.
- Is it correct that only some programmers are subjected to this error, and some are not?
- Do you know if it can be resolved with programmer reflashing?
- Though the solution I use isn't fully correct, may it be helpful for other users? Certainly it's platform-dependent but should be short and simple on each.
- I think this is applicable to all programmers with all firmwares (but better try if it remains after upgrade)
- I think a firmware upgrade will not resolve the issue
- It is not platform-dependent, but a special use-case which not many users have. Still the tooling should be able to recover from this.
Ok.
So what do you think? If USB reset functionality should be included in Stlink Tools or not?
I'm not 100% how the reset will behave with the programmer when calling libusb_reset_device. The tools/library need to rescan after programmer reset and create a new context and is currently not supported. Doing a USB reset is also a workaround instead of a real fix.
I don't know how often typical Stlink Tools user deals with this bug, but for me it happens dozens of times every day and takes tens minutes daily.
Also I still don't understand if it possible to create real fix (not workaround) without complete rewrite of programmers firmware (which looks almost impossible).
You could try to patch and add libusb_reset_device and then rescan all devices or exit/rerun the tool. And see if it works for you. It is currently difficult to implement a reset mechanism so the library/tools pick-up again on the same serial number (programmer) after a USB reset. As there are two backends (mass-storage and raw usb) and alot of code duplication in the usb.c backend.
I'm not sure where in the flow we should place the reset currently.
Not many people use it this way, and it is not a very easy fix. I will close it for now. If somebody feels like to implement this feature feel free and I will reopen this issue. Thanks for reporting!
Reopening this "lost" request.
This issue is now closed due to inactivity.
Please also note that any version prior to v1.7.0 is unsupported according to our #Security Policy.
Should the problem persist, please retry with the latest version in the develop branch.
If this is the case, one should then open a new ticket.