#586 (comment) explains what is being done in this PR as well.

There is progress on the SD card initialization. I've changed it so that the default MSC handler pretends to be busy, and in my marlin implementation the sd card continues to not be ready until a valid capacity can be read. This means that despite the incorrect behaviour of marlin to initialise the SD card first, it is possible to exchange the MSC handler and still use the SD card. Unfortunately it is not possible to do the same for the logical unit numbers. I also found a bad bug in the STM32 MSC SCSI implementation, which seems fixed in later versions.

I have been using this feature to perform firmware upgrades on my board by uploading to the SD card and I have to say that it seems to work nicely :)

Is there a way to disable / change the AStyle check forusbd_ep_conf.h? It currently wants to remove indentation and I find the behavior horrible. Sure it might be readable in an editor supporting highlighting, but without I find it just isn't nice to read.

Is there a way to disable / change the AStyle check forusbd_ep_conf.h? It currently wants to remove indentation and I find the behavior horrible. Sure it might be readable in an editor supporting highlighting, but without I find it just isn't nice to read.

No, the rule is the same for all the repo.

I also found a bad bug in the STM32 MSC SCSI implementation, which seems fixed in later versions.

I will update soon the USB middleware, it is in the pipe, see#1027

I have now added a newUSBMscHandler abstract class, which can be used for implementing the interface. Unlike the other interface, it contains default implementations forIsReady /WriteProtection /Init and to simplify the interface it is one handler per LUN.

The following is a simple example of what a handler can look like:

  class MyUSBMscHandler : public USBMscHandler {    public:      bool GetCapacity(uint32_t *pBlockNum, uint16_t *pBlockSize) {        *pBlockNum = // ...        *pBlockSize = // ...        return true;      }      bool Write(uint8_t *pBuf, uint32_t blkAddr, uint16_t blkLen) {        // ...      }      bool Read(uint8_t *pBuf, uint32_t blkAddr, uint16_t blkLen) {        // ...      }  };

The user can then use either of these methods onUSBDevice to initialize one or many handlers:

    void registerMscHandler(USBMscHandler &pHandler);    void registerMscHandlers(uint8_t count, USBMscHandler **pHandlers, uint8_t *pInquiryData);

@fpistm As the MSC handler has been duplicated because alterations were necessary, an update to the USB middleware is not urgently required yet.

@fpistm As the MSC handler has been duplicated because alterations were necessary, an update to the USB middleware is not urgently required yet.

In fact I will merge it soon as I'm currently validate it.

@rudihorn
for Astyle issue you can use the python script in CI/astyle/, it requires you have astyle installed.

Is there a reason why

yes, IIWR the goal is to init the USB as soon as possible.
The fact it is also called inbegin() is to allow to init it again after aend() call.

I've added aSerialUSB.begin() call to the hw_init function again so that the old behaviour is restored and it compiles. I've also added back the other descriptor speeds. The CI check also passes now. As far as I can tell the most important things should be done.

For the two remaining unchecked points: I can't think of a better way to handle the USB/USBSerial/... so I would suggest we just leave it like this. I've looked over the endpoint buffer configuration code and I think it should produce the same behavior as before, but I'm not entirely sure why there is this number of eps * 8 base offset and I don't have devices to test it.

As such I think I am happy for this code to be reviewed / merged, and if there is anything else I can do for this PR to be merged in let me know.

Although some behaviour does still seem a bit odd, so I will try syncing the MSC and CDC class code to the latest version and will wait until#1027 is merged in.

@rudihorn
I see no change in the boards.txt.
I guess you use PIO and define the correct definition is your config?
Anyway, we should be able to select the config via the Arduino menu.

Could you also share some use case example ?

@rudihorn
I've merged the new USB device middleware thanks#1027
Could you rebase and update accordingly?
Thanks in advance

@fpistm Are there any updates on this and what more is required to get this merged?

Hi@rudihorn
currently not. what is missing is time. I've several stuff in the pipe so I do my best but it is hard to handle all the flow at the same time. This PR is not small and requires some times to properly review it and test.

Status?

Currently not sorry.

@fpistm It would be nice do join this work with mine, in#1196.

@fpistm It would be nice do join this work with mine, in#1196.

Yes. I will probably focus on USB stuff after the 2.0.0 release.

@rudihorn is there any standard for theUSB class? If not, maybe we can follow lib maple interface, asUSBCompositeSerial andUSBMassStorage.

I'm gettingframework-arduinoststm32/system/Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal_rcc_ex.h:2023:41: error: 'UNUSED' was not declared in this scope if a include"usbh_core.h" or justUSB.h.
I need to manually include a header that definesUNUSED before includingusbh_core.h, but it didn't happen before testing this PR.

Any update on if this is going to be added? Or is the PR dead? I did not test it yet but it seems to be a great addition to the core to be able to use Serial and mass storage over USB.

Any update on if this is going to be added? Or is the PR dead? I did not test it yet but it seems to be a great addition to the core to be able to use Serial and mass storage over USB.

We are actively using it on Marlin for some boards, together with#1196.
It seems pretty stable. Just waiting for the merge.

I tried it today and it indeed worked! I adapted the example to use the SDIO interface and the SD library write/read function in STM32SD.h. It is slow in writing (probably because of the 512 byte blocks) but it works. This example worked in PIO using the black development boards of STM32F407

Ow and for who ever want to try with PIO don forget to put the "-DUSBD_USE_CDC_MSC" in your build_flags

Only thing i noticed is the wait until it connects to Serial USB is not working the way it did before. Its not waiting for any connection on my system anymore? Not sure why. It just continues.

Another question, is it possible to de-initialize the usb mass storage from software? I want to be able to enable/disable the USB mass storage function from software on some triggers inside the use code. Then the user code can take control of the SD card again to log data to it.

#include <STM32SD.h>#include <USB.h>#include <USBMscHandler.h>#define BLOCK_SIZE 512#define LED_PIN PA1class Sd2CardUSBMscHandler : public USBMscHandler {  public:    bool GetCapacity(uint32_t *pBlockNum, uint16_t *pBlockSize) {      BSP_SD_CardInfo CardInfo;      BSP_SD_GetCardInfo(&CardInfo);      *pBlockNum = CardInfo.LogBlockNbr;      *pBlockSize = CardInfo.LogBlockSize;      return true;    }    bool Write(uint8_t *pBuf, uint32_t blkAddr, uint16_t blkLen) {      digitalWrite(LED_PIN, LOW);      bool res = false;        if(BSP_SD_WriteBlocks((uint32_t*)pBuf,(uint32_t)(blkAddr),blkLen, 5000) == MSD_OK)        {          /* wait until the Write operation is finished */          while(BSP_SD_GetCardState() != MSD_OK){}          res = true;         }      digitalWrite(LED_PIN, HIGH);      return res;    }    bool Read(uint8_t *pBuf, uint32_t blkAddr, uint16_t blkLen) {      digitalWrite(LED_PIN, LOW);      bool res = false;      if(BSP_SD_ReadBlocks((uint32_t*)pBuf,(uint32_t)(blkAddr),blkLen, 5000) == MSD_OK)      {        /* wait until the read operation is finished */        while(BSP_SD_GetCardState()!= MSD_OK){}        res = true;      }      digitalWrite(LED_PIN, HIGH);      return res;    }    bool IsReady() {            return true;    }  private:};Sd2CardUSBMscHandler usbMscHandler;void setup() {  //Set led pin to output for visual feedback on write/read actions  pinMode(LED_PIN, OUTPUT);  // Open serial communications and wait for port to open:  Serial.begin(9600);  while (!Serial) {    ; // wait for serial port to connect. Needed for native USB port only  }  Serial.print("Initializing SD card...");  // initialise sd card  if (BSP_SD_Init()!=MSD_OK) {    Serial.println("initialization failed!");    while (1);  }  Serial.println("initialization done.");  USBDevice.registerMscHandler(usbMscHandler);}void loop() {  // nothing happens after setup}

Today I found an issue with this PR, when using with a F1 board.

This PR add a class called USB... but, we have this on F1:

#define USB                 ((USB_TypeDef *)USB_BASE)

File: system/Drivers/CMSIS/Device/ST/STM32F1xx/Include/stm32f103xe.h

So we need a new class name...

What about rename theUSB class toUSBComposite?

Is this dead?

I can help here too.

This branch have this PR +#1196 working together:https://github.com/rhapsodyv/Arduino_Core_STM32/tree/usb-host-msc-cdc-msc-2, with the USB class name fixed. Yet for 1.9.x.

It is not dead. I need some free time to review it carefully. I do my best... 😕

Should it be possible with this PR to connect a G3 Dongle to the USB port of a STM32F4 BlickPill running stm32dunio and open a serial connection to send AT commends etc? Or am I barking up the wrong tree?

The dongle presents itself on Linux as a GSM modem /dev/ttyUSB0 and I confirm it responds OK to AT command. It also presents 3 other GSM devices and a mass storage device that is not actually needed.

I guess the STM32 would need to enumerate them to get the the correct CDC?

Is there an example of this somewhere please? I see examples above of using the MSC but not so much for the CDC.

I tried it today and it indeed worked! I adapted the example to use the SDIO interface and the SD library write/read function in STM32SD.h. It is slow in writing (probably because of the 512 byte blocks) but it works. This example worked in PIO using the black development boards of STM32F407

Ow and for who ever want to try with PIO don forget to put the "-DUSBD_USE_CDC_MSC" in your build_flags

Only thing i noticed is the wait until it connects to Serial USB is not working the way it did before. Its not waiting for any connection on my system anymore? Not sure why. It just continues.

Another question, is it possible to de-initialize the usb mass storage from software? I want to be able to enable/disable the USB mass storage function from software on some triggers inside the use code. Then the user code can take control of the SD card again to log data to it.

#include <STM32SD.h>#include <USB.h>#include <USBMscHandler.h>#define BLOCK_SIZE 512#define LED_PIN PA1class Sd2CardUSBMscHandler : public USBMscHandler {  public:    bool GetCapacity(uint32_t *pBlockNum, uint16_t *pBlockSize) {      BSP_SD_CardInfo CardInfo;      BSP_SD_GetCardInfo(&CardInfo);      *pBlockNum = CardInfo.LogBlockNbr;      *pBlockSize = CardInfo.LogBlockSize;      return true;    }    bool Write(uint8_t *pBuf, uint32_t blkAddr, uint16_t blkLen) {      digitalWrite(LED_PIN, LOW);      bool res = false;        if(BSP_SD_WriteBlocks((uint32_t*)pBuf,(uint32_t)(blkAddr),blkLen, 5000) == MSD_OK)        {          /* wait until the Write operation is finished */          while(BSP_SD_GetCardState() != MSD_OK){}          res = true;         }      digitalWrite(LED_PIN, HIGH);      return res;    }    bool Read(uint8_t *pBuf, uint32_t blkAddr, uint16_t blkLen) {      digitalWrite(LED_PIN, LOW);      bool res = false;      if(BSP_SD_ReadBlocks((uint32_t*)pBuf,(uint32_t)(blkAddr),blkLen, 5000) == MSD_OK)      {        /* wait until the read operation is finished */        while(BSP_SD_GetCardState()!= MSD_OK){}        res = true;      }      digitalWrite(LED_PIN, HIGH);      return res;    }    bool IsReady() {            return true;    }  private:};Sd2CardUSBMscHandler usbMscHandler;void setup() {  //Set led pin to output for visual feedback on write/read actions  pinMode(LED_PIN, OUTPUT);  // Open serial communications and wait for port to open:  Serial.begin(9600);  while (!Serial) {    ; // wait for serial port to connect. Needed for native USB port only  }  Serial.print("Initializing SD card...");  // initialise sd card  if (BSP_SD_Init()!=MSD_OK) {    Serial.println("initialization failed!");    while (1);  }  Serial.println("initialization done.");  USBDevice.registerMscHandler(usbMscHandler);}void loop() {  // nothing happens after setup}

Hi
I am new to this field , can you help me how to make it work ? i am working on small project ,where i am logging data in SD card (working ) . I want to access SD card from computer on usb port . i am using stm32duino official core verion 2.1.0 and Arduino IDE 1.8.16. when i try to compile it gives error of USB.h etc file missing , i think it is still not updated on main core , please guide how did you make it work . Thanks

When is the merge release??
Thanks in advance.

This branch have this PR +#1196 working together:https://github.com/rhapsodyv/Arduino_Core_STM32/tree/usb-host-msc-cdc-msc-2, with the USB class name fixed. Yet for 1.9.x.

@rhapsodyv Sir what files need to be copied and updated to the current version to get CDC/ MSC device working for STM32F1.

If anyone could share an example project implementing the CDC+MSC composite I would appreciate seeing it all put together. I'm using a STMF4. I can get both working one at a time but struggling with the composite. I like this approach of leaving the classes separate though as i'm currently trying to vector them and it's ugly.

Apparently this is not compatible with the latest ArduinoSTM32 (4.20200.221104)

https://github.com/rhapsodyv/Arduino_Core_STM32/tree/usb-host-msc-cdc-msc-3

…so it cannot yet be used with STM32H743 and others. How hard is that to port over to the latest?

It is not dead. I need some free time to review it carefully. I do my best... 😕

@fpistm Seems like discussion of this trailed off a few years back. Wondering if the functionality provided by this PR (CDC+MSC composite) was rolled into the core somewhere along the way? As the previous comment mentioned,https://github.com/rhapsodyv/Arduino_Core_STM32/tree/usb-host-msc-cdc-msc-3 doesn't seem t be working any longer, and I haven't had any success, too :(