Fix freezing on SKR-E3-mini-v1.2 board #7078
Conversation
When attached to a BigTreeTech SKR-E3-mini-v1.2 board, Cura+USB seems to reliably hang the printer; sometimes you'll hear an alarm sound, other times the printer will just freeze entirely. The leaveISP() function claims that the serial port is still valid, but as far as I can tell this isn't an actually-valid assumption; it was first introduced in b4df277 but I can't quite track context behind that. This might be true for a bunch of devices but I doubt it's true generally. My hypothesis here is that leaveISP causes the STM32F103RCT6 to reboot, which then wigs out the power-selector circuit (there's now USB power where there wasn't before), and now all of a sudden the chip is in an entirely different state. But that's mostly a guess. It doesn't look like the programmer is necessary, however; it simply connects, loads a register for a READ/WRITE command to use, checks the availability of a checksum byte, and then returns. Since we don't care for that, we can just open individual serial connections as/when they're needed with the various different baud rates. This stops my personal SKR-E3-mini-v.2 board from failing, and since this looks like the same fix as https://www.reddit.com/r/BIGTREETECH/comments/dp6k6r/skr_mini_e3_v12_and_curausb/fbv808j/ I'm going to guess that it works for everyone. I suspect this also fixes issue #6531.
|
Sorry, I don't reckon we can remove this code. As I replied here, it's necessary to upload firmware upgrades via USB cable from Cura. |
|
Hmm, just for the sake of my own sanity -- how does the existence of the (closed) programmer allow one to upload firmware? The serial connection is still established, and AFAICT programming mode is left basically immediately (certainly before any firmware upload takes place); could you perhaps point me to the firmware upload code and I can try to wrap my head around that from there? Cheers~ |
|
The programmer is still active while the baud rate is being detected. If I recall correctly, the presence of the programmer causes Marlin to go into USB printing mode which then allows it to respond to commands for the baud rate detection. But I said that it's necessary for firmware updates because of this commit: 32cbd27 . I trust the commit message more than my memory on this. Maybe @nallath remembers more on why this fix was applied? It refers to CL-541 which is a refactor ticket for the UM3 network connection. |
When attached to a BigTreeTech SKR-E3-mini-v1.2 board, Cura+USB seems to reliably hang the printer; sometimes you'll hear an alarm sound, other times the printer will just freeze entirely.
The leaveISP() function claims that the serial port is still valid, but as far as I can tell this isn't an actually-valid assumption; it was first introduced in b4df277 but I can't quite track context behind that. This might be true for a bunch of devices but I doubt it's true generally.
My hypothesis here is that leaveISP causes the STM32F103RCT6 to reboot, which then wigs out the power-selector circuit (there's now USB power where there wasn't before), and now all of a sudden the chip is in an entirely different state. But that's mostly a guess.
It doesn't look like the programmer is necessary, however; it simply connects, loads a register for a READ/WRITE command to use, checks the availability of a checksum byte, and then returns. Since we don't care for that, we can just open individual serial connections as/when they're needed with the various different baud rates. This stops my personal SKR-E3-mini-v.2 board from failing, and since this looks like the same fix as https://www.reddit.com/r/BIGTREETECH/comments/dp6k6r/skr_mini_e3_v12_and_curausb/fbv808j/ I'm going to guess that it works for everyone with this board, and shouldn't interfere with other printers since, again, all the STK600 communication is mostly noise.
I suspect this also fixes issue #6531.