[BUG] Enabling both USB MSC and CDC causes unstable connection on GD32F1 (STM32F1) based devices

[blazewicz]

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 or STM32F103RE_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

[blazewicz]

@CRCinAU wrote in #22390 (comment):

@blazewicz I seem to remember a while back, there was issues with having both USB data and serial multiplexed over the one link.

Can you recall where did you learn this? Did this occur on STM devices too?

[tpruvot]

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

[CRCinAU]

Can you recall where did you learn this? Did this occur on STM devices too?

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...

[tpruvot]

SKR mini has no usb host (for usb keys)

[looxonline]

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

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.

[tpruvot]

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

[thinkyhead]

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 SPEAKER the piezo on the LCD will only play generic beeps.

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.

[tpruvot]

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 ...

[Sebazzz]

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 STM32F103RE_btt_USB build:

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.

My board has a real (I suppose) STM32F1 chip though.

[thisiskeithb]

Closing since the GD-based SKR Mini cannot be added here.

[github-actions]

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.