2024-07-17 04:33 PM
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
Solved! Go to Solution.
2024-07-23 07:39 AM
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
2024-07-18 01:10 AM
This seems to be a problem with the STM32CubeProgrammer. Check version, check setting, check permissions of the device.
2024-07-18 06:35 AM
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
2024-07-18 03:10 PM
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 .
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
2024-07-18 09:23 PM
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
2024-07-22 04:07 AM - edited 2024-07-22 04:09 AM
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
2024-07-22 10:27 AM
Hi @PGump.1
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.
2024-07-23 07:39 AM
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