Problems with STM32L552 USB-VCP

[GS1]

Is there anybody out there who got the USB running as VCP on a STM32L552 ?

We have problems to get the system running with USB attached to a PC via VCP. We used the MXCube release 5.6.1 and created a small project with USB VCP. The VDD-USB Pin is connected to 3.3V, the system boots, but USB is not detected on the PC side.

We have USB as VCP working on several other processors before (STM32F4, STM32F7, STM32H7) without any issues. But on L552 there must be something different which is not working when using the same firmware handling and hardware layout.

Any comments are very much appreciated.

[TDK]

> USB is not detected on the PC side.

Okay so what happens? Any error messages or does it not detect a device at all?

If no detection at all, check that DP is getting pulled up correctly.

[GS1]

The effect is as follows:

When switching on the system with USB connected to PC, the system boots and the PC reports: USB Device not detected. So it tries to identify the USB device, but fails.

When switching on the system with USB cable not attached to the system, it runs endlessly into the interrupt routine HAL_PCD_IRQHandler(PCD_HandleTypeDef *hpcd) and does not finish the boot process.

[GS1]

Current configuration is:

VDDUSB is connected to VDD 3.3V

We can provide a resistor devider from Bus Power Pin to any I/O Port on the CPU in order to detect an inserted cable (USB Master). Which Software steps have to be done to get this configuration working?

In other words: How can the processor detect that a USB cable is connected?

As it seems, the VDDUSB connection only serves to supply power to the USB circuit, right?

On all other processors PA9 is dedicated to a VBus-Sensing Function. But on this processor this pin is not available for VBus-Sensing.

So the question is: How has Connection detection to be done?

[GS1 · Accepted solution]

We have a working solution for anyone interested:

Hardware condition is:

• VDDUSB pin is connected to 3.3V power supply (fix supply)
• USB-Mode is FS Device only, no OTG, no USB-C

in CubeMX configuration do the following:

• In NVIC configuration activate Interrupt for PVD/PVM1/...
• On the Advanced Settings Page of the Project Manager activate "Not Generate Function Call" for MX_USB_Device_Init
• In USB Setup select "Link Power Management not supported"

1) At power up, after intialisation of GPIOS etc. has been done, call following routine "DoInitUSB" which configures the PVM (Peripheral Voltage Monitoring) interrupt for PVM1 (for USB) as follows:

void DoInitUSB(void)

{

   static int bInit = TRUE;

   PWR_PVMTypeDef sConfigPVM;

   sConfigPVM.PVMType = PWR_PVM_1;

   sConfigPVM.Mode = PVM_MODE_IT | PVM_RISING_EDGE | PVM_FALLING_EDGE;   // Create an interrupt for power detection

   HAL_PWREx_ConfigPVM(&sConfigPVM);

   //Activate Peripheral Voltage Monitoring 

    HAL_PWREx_EnablePVM1();

   // Activate Power for USB

   HAL_PWREx_EnableVddUSB();

   // Wait 2 MS

   ParaDelay(PARA_DELAY_1MS);

   ParaDelay(PARA_DELAY_1MS);

   //Check if USB plug connected:

   if (READ_BIT(PWR->SR2, PWR_SR2_PVMO1) == 0)   // Power is above 1.2 Volt

   {

      HAL_PWREx_EnableVddUSB();

      if (bInit)      

      {

         MX_USB_Device_Init();

         bInit = FALSE;   // Only do once after power on

      }

       bPowerIsOn = TRUE;

   }

   else

   {

      HAL_PWREx_DisableVddUSB();

       bPowerIsOn = FALSE;

   }

}

2) Include following callback fpr PVM Interrupt:

void HAL_PWREx_PVM1Callback()

{

   if (READ_BIT(PWR->SR2, PWR_SR2_PVMO1) == 0)   // Power is above 1.2 Volt

   {

      HAL_PWREx_EnableVddUSB();

       if (bInit)

      {

         MX_USB_Device_Init();

         bInit = FALSE;

      }

      bPowerIsOn = TRUE;

   }

   else            // Power is below 1.2 Volt

   {

      HAL_PWREx_DisableVddUSB();

       bPowerIsOn = FALSE;

   }

}

I hope this setup helps others!

[GWett.1]

We are struggling with basic USB connectivity on STM32L5. When we saw this post we had hoped it would be the solution to our problem but that doesn't seem to be the case.

We are doing a prototype on an STM32L562E-DK discovery board that needs a basic USB-CDC device. We used the demonstration code straight out of the STM32CubeL5 package but haven't been able to get anywhere.

We have a Linux based host PC plugged in with a Type-A->USB-C cable to the USB-C connector on the board. When we issue a board reset or plug the USB-C connection into the board after it is powered up via the ST-LINK USB connection the host detects USB devices, ie:

Jul 20 13:14:15 nuc2 kernel: usb 1-2: new full-speed USB device number 70 using xhci_hcd

Jul 20 13:14:16 nuc2 kernel: usb 1-2: new full-speed USB device number 71 using xhci_hcd

Jul 20 13:14:16 nuc2 kernel: usb usb1-port2: attempt power cycle

Jul 20 13:14:17 nuc2 kernel: usb 1-2: new full-speed USB device number 72 using xhci_hcd

Jul 20 13:14:17 nuc2 kernel: usb 1-2: new full-speed USB device number 73 using xhci_hcd

Unfortunately the following errors are logged when the host OS attempts to properly setup the device:

Jul 20 13:14:15 nuc2 kernel: usb 1-2: device descriptor read/64, error -71

Jul 20 13:14:16 nuc2 last message repeated 3 times

Jul 20 13:14:17 nuc2 kernel: usb 1-2: Device not responding to setup address.

Jul 20 13:14:17 nuc2 kernel: usb 1-2: Device not responding to setup address.

Jul 20 13:14:17 nuc2 kernel: usb 1-2: device not accepting address 72, error -71

Jul 20 13:14:17 nuc2 kernel: usb 1-2: Device not responding to setup address.

Jul 20 13:14:17 nuc2 kernel: usb 1-2: Device not responding to setup address.

Jul 20 13:14:18 nuc2 kernel: usb 1-2: device not accepting address 73, error -71

Jul 20 13:14:18 nuc2 kernel: usb usb1-port2: unable to enumerate USB device

So fairly classic fingerprint, I believe, of the board/MCU not responding to the request by the host controller to enumerate the endpoint(s).

After seeing your post we modified the test harness to implement the custom PVM interrupt handler as well as the modified USB initialization code but the problem remains invariant.

The defines that were used for the PVM mode setup appear to come from C sources in the HAL driver so we used local definitions in our application code that matched the definitions in the C sources. We also used statically scoped definitions for the two flag variables (binit/bPowerIsOn) since it wasn't apparent how the interrupt handler would reference the binit variable since it was scoped in the context of the DoInitUSB() function, the same with the bPowerIsOn variable.

When we flash our standard 'blinky light' test harness onto the board and reset it there is no indication of USB activity on the USB-C port. So it appears that our USB test code is at least triggering device detection by the host PC.

The discovery board comes loaded with a sample application in firmware. Interestingly we see the same behavior on the USB-C port when the board is powered up or reset with that code in its flash. We are are assuming the demonstration code has some type of USB functionality but it appears to be plagued by the same problem that our test code has.

When we plug the board into a Windows-10 host a dialog box is displayed indicating the last USB device plugged in malfunctioned. Presumably Windows is having the same problem with device enumeration that Linux is having.

We've increased the heap size as well and tried various other things we have found in searches for this issue but the problem remains exactly the same with those changes.

Any suggestions or pointers would be deeply appreciated.

Have a good week.

[GS1]

I am not sure if there has more to be done for USB-C? We use the standard USB A/B-type connection.

Concerning the bPowerIsOn variable: It simply has been introduced by me to indicate if USB power is detected or not. It is on the "global" level (static).

The bInit variable (also static) is necessary to identify, if the HAL function for initialising the USB port (MX_USB_Device_Init) has been called already or not. It only has to be called once after powering up the system.

After we included the PCM handling the USB connection worked without any problems.

So I am sorry that there are no other suggestions for you to try. But as the original board software seems to show the same effect I would suggest to first get this working before going further with custom software.

I would check with standard USB connection without the converter to USB-C.

Good luck and have a good week too!

[RDKS]

It's been a year since the original post.

Has there been any progress with this issue ?

I'm still having the same problem with an STM32L562.

USB is working just fine for the system memory DFU bootloader but not for application code generated by CubeMX.

So this seems not to be a hardware or electrical issue, but a problem with the code generated by CubeMX.

This doesn't only concern CDC class code but any code generated with the USB middleware.

It would be great to seen an update to CubeMX that fixes this problem and makes it possible to just use the generated middleware code without having to manually fiddle with initialization code and interrupt handlers.

[GS1]

Please see my post above (selected as best): I could solve the problem by implementing a special handling for the PCM.

Don't know if CubeMX now handles the USB correctly by itself - did not touch it any more after I got my workaround.

[RDKS]

The solution suggested by GS@S didn't solve the problem for me.

Instead i still observed the same behavior as reported by GWett.1

It turns out the issue, in my case, was a faulty clock configuration generated by the Clock Issue Resolver of CubeMX.

This only concerns boards without an external high speed clock source (including STM32L562E-DK).

On a custom board with an external 16MHz oscillator USB, including the CubeMX Middleware examples, worked just fine.

On boards without HSE this is the clock configuration generated by the automatic resolver:

 

The problem in this case is that system clock and USB clock (via PLLSAI1Q) are both driven from MSI which (according to the datasheets) is not accurate enough to drive the USB controller.

After manually changing the configuration to this one everything works just fine:

Here the system clock is driven by HSI and USB is driven by HSI48 which the datasheet explicitly mentions as the only valid clock source for USB apart from an external high speed clock source.