-
-
Notifications
You must be signed in to change notification settings - Fork 19.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
[BUG] Enabling both USB MSC and CDC causes unstable connection on GD32F1 (STM32F1) based devices #22431
Comments
@CRCinAU wrote in #22390 (comment):
Can you recall where did you learn this? Did this occur on STM devices too? |
Yes, imo GT devices are just recycled chips.. maybe the chips are just STM ones not passing some quality level... but tested ok. There was a lot of "bug report" about USB stability (boards randomly crashing, and more often when octoprint is used). Seen here myself on a SKR mini |
It was somewhere in the issue tracker here - and was to do with the USB Host drivers. There was some issue with how often and where in the Marlin code that the handler for the USB Host was called, and it caused problems if called in various areas, and iirc, if it was only called in the Marlin idle loop. I'm not 100% on the details, but I think it was all STM chips... |
SKR mini has no usb host (for usb keys) |
This is not the case. GD chips use a fully licensed ARM core with GD purchasing the licenses directly from ARM. They have designed the peripherals around that core to match the STM specifications in terms of voltage and current and then they went a step further and made them register compatible. Finally, they leveraged their expertise in flash memory to embed an internal SPI flash alongside a much larger cache than can be found within the STM equivalent. This is the reason why the GD can run at 108MHz without wait states while the STM can only go to 72MHz without wait states. |
Yea, or maybe you were lucky, even on real STM chips.. quality can vary... and tuning clocks can cause problem on any subdevice then... SD/SPI/Serial etc but its another problem... Maybe this brand is legit, but there was also noname clones, hard to know if they are fakes or recycled devices... about clocks tpruvot@69da9d2 |
I've got the SRK Mini E3 V2.0 with a GD32F103RET6 and I've just used the standard RET6 + USB build environment to build the firmware. So far testing is inconclusive. Sometimes I have to disconnect and reconnect the USB cable before the serial port will appear. Maybe that indicates poor soldering on the USB port, but I don't want to wiggle it too much to check. Once the connection is stablished the serial console connection is robust and the SD card can be mounted in macOS for read and write. With the single-cable Creality Stock LCD from a CR-10S I had to increase the SPI delays to get rid of screen glitches, which is not unusual. Occasionally the screen becomes very sluggish, both in drawing and in response to the encoder knob. I've tried running G-code, printing lots of output to the serial console, and running G-code that plays tones from the SD card, and only the tone G-code had a noticeable slowing effect on the UI. Although I enabled To test the robustness of the USB connection, I could set it up to receive G-code over USB and send over G-code to move the X motor back and forth for several hours until it fails. |
Tested the oc ok here on the STM32F103VE with STM32 HAL... but beware to set F_CPU correctly tpruvot@d06d85d (may need part of my previous F1 commit for the elapsed time) and this doesnt include HW SPI changes ... |
For what it is worth (I need to do more testing), this didn't happen in Marlin 2.0.8 on my BTT SKR CR-6 board (maple build). I have similar behaviour like the below on the non-maple
My board has a real (I suppose) STM32F1 chip though. |
Closing since the GD-based SKR Mini cannot be added here. |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Did you test the latest
bugfix-2.0.x
code?Yes, and the problem still exists.
Bug Description
Running both CDC (Communication Device Class, serial-over-USB) and MSC (Mass Storage Class) on same USB port of GD32F103 may cause unstable connection. Its not immediate, in my case connection broke usually after 1-2h of running a job from Octopi.
I tested it on GD32F103RET6 a STM32F103RET6 compatible chip from GigaDevice. I don't know if same issue occurs on genuine ST chips.
Affected environments:
STM32F103RC_btt_USB
STM32F103RE_btt_USB
Changing evironment to either
STM32F103RC_btt
orSTM32F103RE_btt
solves the issue.Bug Timeline
probably since migration to Arduino framework
Expected behavior
No response
Actual behavior
No response
Steps to Reproduce
No response
Version of Marlin Firmware
bugfix-2.0.x
Printer model
doesn't matter
Electronics
any board with GD32F103Rx chip
Add-ons
No response
Your Slicer
No response
Host Software
No response
Additional information & file uploads
No response
The text was updated successfully, but these errors were encountered: