cancel
Showing results for 
Search instead for 
Did you mean: 

USB Issue when porting from STM32F072 to STM32L072

PGump.1
Senior

Hi all,

I'm porting a project from a F072 (Nulceo-F072) to a custom PCB with a STM32L072.

The board is going well, except when I try to use the USB (CDC mode).

When I plug it into my PC, the OS can see it -

         Bus 006 Device 072: ID 0483:5740 STMicroelectronics Virtual COM Port

but I can't connect to it. I can put it into Boot mode - again the OS sees it -

         Bus 006 Device 071: ID 0483:df11 STMicroelectronics STM Device in DFU Mode

But STM32CubeProgrammer can't see it...

The hardware design is the same as the Necleo-F072, however, I have added a USBLC6-2SC6 for protection.

I have placed various breakpoints around the USB CDC module to find out where it's going wrong, but I haven't found a trigger point yet.

Has anyone got any leads?

Kind regards
Pedro

 

AI = Artificial Intelligence, NI = No Intelligence, RI = Real Intelligence.
1 ACCEPTED SOLUTION

Accepted Solutions

Thank you for your reply.

I'm using the 48 pin package - separate USB power pins.

I think I've worked it out - given that neither my app nor the Bootloader DFU would work, I was convinced I had a hardware issue.

But it turns out that because I configured the RCC for LL (not HAL) - it seems that the LL_RCC_INIT() does something weird to the MSI48MHz that remains modal. I accidentally discovered that running HAL_RCC_INIT() fixes it...

I'm a bit behind on this project now, so, I'll look into this deeper soon...

Kind regards
Pedro

AI = Artificial Intelligence, NI = No Intelligence, RI = Real Intelligence.

View solution in original post

7 REPLIES 7
Uwe Bonnes
Principal III

This seems to be a problem with the STM32CubeProgrammer. Check version, check setting, check permissions of the device.

PGump.1
Senior

Thanks for your reply.

However, it also fails when a terminal program like PuTTY. Sometimes PuTTY connects but fails to exchange data, other times it errors saying it could not connect.

Any other hints?

Kind regards
Pedro

AI = Artificial Intelligence, NI = No Intelligence, RI = Real Intelligence.

Hi @PGump.1 ,

Can you please try to change the USB port on Your PC connected to the board and if you have a full speed HUB to try to put it in between and try again . I have suspected hypothesis the following, check the minimum APB frequency that is  16MHz .

IMG_8982.jpeg

F0 runs at 48MHz and L0 at 32MHz this may impact the migration and processing of the transactions speed .

let us know . 
Ciao

STOne-32

Thanks for the reply.

I had read the Errata notes. I did see that. Initially my APB frequency was 16MHz, I changed it to 32MHz to see if that was the problem, but it made no difference.

I had tried it directly to PC ports, through Hubs, Windows and Linux...

Linux lists it with 'lsusb' command, but PuTTY won't connect to it.

Windows states the driver for the device did not install correctly or, Unknown device.

I have built up a second board - it's doing the same thing...

I have removed the USBLC6-2SC6 on one of the boards, it's still not working.

Any other clues?

Kind regards
Pedro

AI = Artificial Intelligence, NI = No Intelligence, RI = Real Intelligence.

I still can't get the USB going!

I have tried increasing decoupling caps. Examined and tested grounding. My Oscilloscope shows the 3.3V VCC as very stable. I have increased the cap and pullup on the NRST pin - very stable...

I created a USB test project. main() simply turn a LED Off/ On from an input pin.

When I run this program, it locks-up in MX_USB_DEVICE_Init();

If step trough it, line-by-line, with Debug it works, and my LED follows the input.

I have captured RCC->CSR -

uint32_t p = RCC->CSR; the value is 0x14000000

RCC->CSR |= RCC_CSR_RMVF;

 

It appears that the MX_USB_DEVICE_Init() function is generating a Software reset...

 

Can anyone put some light on this?

 

Kind regards
Pedro

AI = Artificial Intelligence, NI = No Intelligence, RI = Real Intelligence.

Hi @PGump.1 

  1. Which STM32L072xx package are you using? UFQFP32 features a VDD_USB pin while LQPF32 does not. On packages without VDD_USB pin, VDD_USB voltage is internally connected to VDD voltage. If it has this pin, make sure that it is above 3.0V.
  2. Could you check your clock configuration and ensure that the USB clock source is correctly set to 48 MHz.

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Thank you for your reply.

I'm using the 48 pin package - separate USB power pins.

I think I've worked it out - given that neither my app nor the Bootloader DFU would work, I was convinced I had a hardware issue.

But it turns out that because I configured the RCC for LL (not HAL) - it seems that the LL_RCC_INIT() does something weird to the MSI48MHz that remains modal. I accidentally discovered that running HAL_RCC_INIT() fixes it...

I'm a bit behind on this project now, so, I'll look into this deeper soon...

Kind regards
Pedro

AI = Artificial Intelligence, NI = No Intelligence, RI = Real Intelligence.