[FR] STM32 USB CDC + MSC Composite

[rudihorn]

Description

One feature that the STM32F1 library has is the ability to have direct access to the SD card as a mass storage device in addition to serial commands over USB. Currently the HAL does not support this, but there is a PR stm32duino/Arduino_Core_STM32#586. I would suggest those interested help to review the feature and get it ready to be merged in any way possible.

I'm creating this issue as this had been mentioned by @AnHardt in #18095.

Additional Information

• PR for this feature in HAL: Add composite MSC CDC USB device stm32duino/Arduino_Core_STM32#586

[rudihorn]

I've submitted a further PR for stm32duino stm32duino/Arduino_Core_STM32#1088, which works with an experimental branch of mine with Marlin https://github.com/rudihorn/Marlin/tree/usb-core.

To compile it:

• Clone https://github.com/rudihorn/Marlin/tree/usb-core to C:\<path>
• Set the platform package to platform_packages = framework-arduinoststm32@C:\<path>
• Copy the CMSIS and variants/<your_board> from ~/.platformio/packages/framework_arduinoststm32/ to C:\<path>.
• Set platformio platform_packages = framework-arduinoststm32@C:\Programs\Arduino_Core_STM32 to your board
• Add compile flags https://github.com/rudihorn/Marlin/tree/usb-core

[jmz52]

HAL STM32 already has experimental support CDC + MSC Composite.
#17222
It requires code from PR you've linked - stm32duino/Arduino_Core_STM32#586.

[Bob-the-Kuhn]

stm32duino PR 582 is stuck in a black hole.

I'm hoping the code in this PR and stm32duino 1088 is a better way to go. I'm hoping to start playing with it this weekend.

[rudihorn]

Yeah so the current status of the work I've been doing is it seems to work, and the USB side of things seem reliable. However somehow enabling MSC is interfering with Marlin itself.

With MSC enabled, doing actions like setting the heating on works, but it completely breaks any actions requiring stepper motors. You can sometimes hear the steppers start or power up, but then they stop moving and the printer retains a busy state. It seems that the busy state actually works, as it sends out periodic busy notifications and I think it still controls the temperature as intended. It just seems stuck in the planner loop, if I had to guess what is going on. I'm not sure if it is somehow a timeout or something, but this also happens when the 3d printer is not doing busy work. I'm also a bit uncertain I'll be able to actually figure out what is going on without debugging this.

If anyone with more experience with Marlin itself could even give me a glimpse of what is going on then I can try to fix this. I'm guessing it might somehow be related to either stepper or timer interrupts, but I'm not even sure which part of what code causes the planner to advance, and I'm unsure how this could be affected by the USB stack.

[AnHardt]

The usual suspects:

• Disabling/enabling interrupts globally.
• Interrupt priorities (relative to each other)
• Busy waits
• Long lasting interrupts
• Double use of timers
• ...

[rudihorn]

@AnHardt I'm not directly making any changes to interrupt settings. However as far as I can tell the USB framework runs within an interrupt, and expects the SD card operations to be performed within that long running interrupt. So it likely that interrupt priorities are an issue, and I'll need to look into this some more.

[rudihorn]

So indeed this seeems to probably have been a priority issue. As mentioned stm32duino/Arduino_Core_STM32#1088 (comment), setting the flag -DUSBD_IRQ_PRIO=9 seems to solve the issue for me. I still need to run some active prints though, and will maybe try this later.

[Bob-the-Kuhn]

Please post a copy of your platformio.ini.

I wasn't able to get a working USB interface. It enumerates without errors as a composite CDC device (3 endpoints) and MSC device (two endpoints) and shows up in my serial port list. Repetier Host can't connect to it and the virtual drive never appears. The generic Microsoft driver and the generic 3DPrinter driver both give the same result.

It's probably because I don't understand how to implement this portion of your compile instructions:

• Add compile flags https://github.com/rudihorn/Marlin/tree/usb-core

[rudihorn]

I just committed the version I am currently working with, though it should be mostly identical.

The configuration I'm using is the following, but the most important changes are using the flags:
-DUSBD_IRQ_PRIO=9 -DUSBCON -DUSBD_USE_CDC_MSC -DUSBD_PID=0x5740. I'm connecting it to a raspberry pi using out of the box kernel drivers and have not tried it on Windows. I can maybe try hooking to up on Windows tomorrow though.

If there are issues with it not working with either of the other drivers, it is probably just a matter of changing the USB interface descriptor. Depending on the driver it might also be worth changing PID/VID.

Also if you downloaded an older version of my patched arduineststm32, do make sure to remove the cached version with platformio.exe platform update.

[env:BIGTREE_SKR_PRO]
platform          = ststm32
platform_packages = framework-arduinoststm32@https://github.com/rudihorn/Arduino_Core_STM32.git#usb_msc_cdc
board             = BigTree_SKR_Pro
build_flags       = ${common.build_flags}
  -DUSBD_IRQ_PRIO=9 -DUSBCON -DUSBD_USE_CDC_MSC -DUSBD_PID=0x5740 -DUSBD_VID=0x0483 -DUSB_PRODUCT=\"STM32F407ZG\"
  -DTARGET_STM32F4 -DSTM32F407_5ZX -DVECT_TAB_OFFSET=0x8000
  -IMarlin/src/HAL/STM32
build_unflags     = -std=gnu++11
extra_scripts     = pre:buildroot/share/PlatformIO/scripts/generic_create_variant.py
lib_ignore        = SoftwareSerial, SoftwareSerialM
src_filter        = ${common.default_src_filter} +<src/HAL/STM32>
#upload_protocol   = stlink
#upload_command    = "$PROJECT_PACKAGES_DIR/tool-stm32duino/stlink/ST-LINK_CLI.exe" -c SWD -P "$BUILD_DIR/firmware.bin" 0x8008000 -Rst -Run
debug_tool        = stlink
debug_init_break  =

[rudihorn]

@Bob-the-Kuhn So I just had a more in-depth look and as guessed it was just a matter of changing the descriptors. In particular, setting the protocol to CDC_PROTOCOL_V25TER for the device descriptor seemed to do the trick. I've just committed this to the repo, if you could please try again and make sure it works for you.

[Bob-the-Kuhn]

IT WORKS!!

I've tested it on the SKR_PRO and on a Black STM32F407.

Thanks

Code changes:

Marlin - file msc_sd.cpp - need to keep this file from being compiled when doing USB without MSC. I suggest:

• changing #if SD_CONNECTION_IS(ONBOARD) to #if defined(USBD_USE_CDC_MSC) && SD_CONNECTION_IS(ONBOARD)
• Moving #if defined(USBD_USE_CDC_MSC) && SD_CONNECTION_IS(ONBOARD) to between #include "../../inc/MarlinConfig.h" and #include "msc_sd.h"
• Moving #endif from just before void MSC_SD_Init() { to the end of the file.

---

Strange behavior

Black - takes 1-2 minutes before the mapped drive appears.
SKR_PRO - once, the mapped drive didn't appear for several minutes. I did some SD card mounts and unmounts via Repetier Host during the down time. I can't reproduce this issue.

[Bob-the-Kuhn]

Is there a strong reason to enable SDIO access to the onboard SD card?

Marlin isn't SD intensive so the speed advantage of SDIO isn't a big item.

I'm liking the idea of keeping the default as SPI because some composite capable controllers only have SPI access to the SD card.

---

I'm also thinking that we shouldn't restrict SD access to the onboard SD card. With SPI access this requirement goes away.

[rudihorn]

Is there a strong reason to enable SDIO access to the onboard SD card?

No, the Marlin bit is only something like a proof of concept, and I do not know the intricate details of when what makes sense. However until the PR for STM32duino has been merged in and made its way into a release, it is probably not worth overinvesting time in it.

It would probably be good to have both options available.

[Bob-the-Kuhn]

I was able to modify msc_sd.cpp and Sd2Card_sdio_stm32duino.cpp to use SDIO for the onboard SD card.

May I add your software to the Marlin code base?

Is the standard Marlin license OK or would you like another added to it?

How would you like to be credited? I'll definitely say in the PR something like "All new files courtesy of @rudihorn ." I can also add to the files something like "Based on work done by rudihorn".

[rudihorn]

May I add your software to the Marlin code base?

Yes happily, I was going to submit a PR as soon as the stm32duino thing was pulled in any case.

Is the standard Marlin license OK or would you like another added to it?

Yeah whatever is fine.

How would you like to be credited? I'll definitely say in the PR something like "All new files courtesy of @rudihorn ." I can also add to the files something like "Based on work done by rudihorn".

One of the two would be nice, whichever is more appropriate.

[Bob-the-Kuhn]

You are right about waiting on doing the Marlin changes. Changing platformio.ini before Marlin switches to the new stm32duino would result in no USB ports until the switch happens.

I'm sure that you'll know long before I do when the new platformio stm32duino package is available. I think its best if you initiate the Marlin PR.

Here's the two modified files you'll need for the Marlin PR.
modified.zip

[Bob-the-Kuhn]

The changes I've made are:

• msc_sd.cpp - added a class that uses the SDIO routines in Sd2Card_sdio_stm32duino.cpp
• Sd2Card_sdio_stm32duino.cpp - removed the composite section so that the SDIO drivers always come from this file.

[Bob-the-Kuhn]

I tried to implement the CDC_MSC in the latest bugfix. I'm getting timer function definition errors.

There has been a lot of STM32 platform work recently.

I'm definitely not understanding how the new settings work.

Looks like I need to wait for you to get back to this when the new stm32duino is released.

[jeno007]

I just want to report, that I got my SKR PRO v1.1 onboard SD card USB access working on Marlin 2.0.7.2 by using stm32duino/Arduino_Core_STM32#1088 and applying the few changes from @rudihorn 's usb-core rudihorn/Marlin/tree/usb-core branch.
The only interesting thing is that the USB SD card access works only when the card is mounted by Marlin as well. When it is released by Marlin, it also disappears from the USB host.
EDIT:
The acces speed from the host is quite low, about 40kB/s due to the onboard SD card using software SPI I assume.

[Loafdude]

Hi I am building bugfix-2.0.x against a SKR Mini E3 v1.2 (STM32F103RC)
I am having major issues with SD card speed, and USB reliability.
I believe this may be related to the work above

I'm building against STM32F103RC_btt_USB

• Listing SD card on the LCD is horrifically slow.
• USB is unusable at boot, if devices do appear in windows they are unusable
• After unplug/replug USB works but is unstable
• Serial Connection drops periodically due to USB instability
• Upon replug VendorID:0483 ProductID:5740 "USB Composite Device" "STMicroelectronics" "GENERICSTM32F103RE CDC in FS Mode" "48DB83593032" "GENERICSTM32F103RE CDC in FS Mode" "GENERICSTM32F103RE CDC Interface" "GENERICSTM32F103RE CDC Interface" "GENERICSTM32F103RE CDC Interface"

I have also been testing against maple.
STM32F103RC_btt_maple does not experience the SD card slowdowns though the USB version does not present a mass storage device.
Marlin 2.0.5.3 (my old fw version) did not experience these issues and USB / Serial co-existed

The build flags presented in the stm32f1.ini file are

                    -DUSE_USB_FS
                    -DUSBD_IRQ_PRIO=5
                    -DUSBD_IRQ_SUBPRIO=6
                    -DUSBD_USE_CDC_MSC

I have tried a combination of your flags as well

                    -DUSE_USB_FS
                    -DUSBD_IRQ_PRIO=9
                    -DUSBD_IRQ_SUBPRIO=6
                    -DUSBD_USE_CDC_MSC
                    -DCDC_PROTOCOL_V25TER
                    -DUSBD_PID=0x5740
                    -DUSBCON
                    -DUSBD_VID=0x0483
                    -DUSB_PRODUCT=\"STM32F407ZG\"