Reset of the MCU doesn't cause USB device re-enumeration
kzyapkov opened this issue · comments
Maybe I'm doing something wrong, but while toying with the project I noticed that if I hit the reset button on the pill the host doesn't notice anything has happened. I have to pull the USB cable out to see the "USB disconnect" event in the kernel log. I don't have an STLink or other power source connected, bluepill is powered over the USB connector.
This is on linux 5.13.6. Everything else works fine otherwise.
73 de LZ1CK
Hi,
I haven't implemented forcing USB re-enumeration in this firmware. I thought this functionality was not critical for everyday device operation. However, it does seem a convenient feature for development purposes. Also, people seem to expect it to behave this way, so it should be implemented, I guess.
@kzyapkov Please test the linked PR.
I can confirm the proposed patch works as expected -- as soon as the micro is reset the ports are re-enumerated, any active screen sessions get terminated.
A possibly unrelated glitch, also present without the re-enumeration patch: after the reset, in a fresh screen session it seems some garbage gets sent to UART1, which I keep as a control console by permanently grounding PB5. An example:
od
Error, unknown command, use "help" to get the list of available commands.
>
>verde cm
Error, unknown command, use "help" to get the list of available commands.
>
>Er
Also, strangely, flashing the micro via SWD doesn't cause re-enumeration. The newly flashed program seems to run, but the host doesn't get the memo.
A possibly unrelated glitch, also present without the re-enumeration patch ...
Looks like I should open a separate issue and investigate this.
Also, strangely, flashing the micro via SWD doesn't cause re-enumeration
That is odd. I actually tested this and it re-enumerates just fine after flashing at least with my PC running Win10. I will double check this with my MacBook and Linux (virtualized, VirtualBox). I am using a cheat st-link v2 clone. I just connect SWCLK, SWDIO, 3.3v, and GND. What's your setup?
What's your setup?
Exactly the same: STLink clone with the 4 pins connected to one side of the bluepill; a USB-micro cable on the other side.. Both the STLink clone and the USB interface of bluepill are connected to the same powered USB 2.0 hub. I don't have Windows, will try to test on wife's Mac.
My test sequence: open a screen session on /dev/ttyACM0, run make flash which succeeds; observe the screen becomes non-operational, but doesn't detach. Kernel log doesn't notify about USB disconnect events. Hitting the reset button causes the disconnect and screen dies as a result.
I re-tested on Linux, Mac, and PC again and everything works as expected. The device re-enumerates after flashing the MCU. If you programming (st-link) setup is equivalent to mine, probably the boards a little bit different. As far as I know, there are a few variations of stm32f103c8t6 bluepill boards out there. Particularly, I am interested in how PA12 (USB D+) is pulled up on your board. Mine goes to the 3.3 V line via a 1.5k resistor. This is exactly as it should be. Can you test yours? Also, if you have schematics for your version of the board, it will help a lot.
Also, what version of st-flash do you use? Mine is:
>> st-flash --version
v1.6.1-1-gbaab8ca
Also, this could be related to your host USB hardware. The thing is, as far as I know, the re-enumeration method I use does not strictly confirm to the USB specs. But this is the best I can do anyways. That's why it would be great if you can test it on multiple different hosts so that we can figure our if this is a problem with a particular host or your board behalves the same with multiple different hosts.
One more thing. Сan you play with the timing? Please try 0xFFFF or 0xFFF (usb_io.c:60) to see if it changes anything.
PA12 is pulled to 3.3V with a 1.5kOhm resistor which I replaced myself years ago when I got the boards. I tested on 2 different bluepills (most likely from the same batch, but can't remember exactly) -- both did not re-enumerate when accessed with st-flash / st-util. I then tested connecting to the target with openocd -- when I execute reset via openocd the board does re-enumerate, just like when I hit the reset button.
I then attached one of those ultra-cheap logic analyzers to PA12 -- no reset hold while flashing -- the MCU just doesn't go through reset! Finally, my st-flash --version: v1.7.0-88-g9605d21. It turns out they've added the --connect-under-reset option, and when I add it to the flash command the board does re-enumerate.
Normality restored.
Does this mean the issue you experienced is st-flash related and does not require any fixes in the PR? Or am I missing something?
Does this mean the issue you experienced is st-flash related and does not require any fixes in the PR? Or am I missing something?
The issue seems to be st-flash related, yes. With the newer version, after st-flash is done the target MCU doesn't go through reset unless --connect-under-reset is used.
Sorry for the delay. I’ll get back in Monday and do more tests with the newest version of st-flash. If it doesn’t do any reset at all, I think I’m just going to merge this PR because it otherwise works.
@kzyapkov I upgraded my st-flash to v1.7.0 and got the same experience that you did. Then I figured out that you don't really have to use the "connect-under-reset" option. Simple "reset" is fine as well. So I think, I just need to add the "--reset" flag to the Makefile and finally merge this PR.
@kzyapkov pushed the update. Please re-test when you have time and let me know if you are OK with merging this PR.
Using the --reset option instead of --connect-under-reset yields the desired effect, OK to merge. Thanks!