2
\$\begingroup\$

I'm working on a custom board equipped with an STM32F103C8T6 uC. Such device must act as a USB to CAN bridge. The uC seems ok, I can program and debug it, I can periodically toggle an on-board led. Timings seem OK (I have no oscilloscope at hand at the moment, the only measure I can do is blink LED with HAL_Delay(1000) and measure time with a stopwatch).

The problem is, I configured with STM32CubeIde the USB peripheral with the USB CDC and when I plug it to the PC the device manager does not recognize the device, with error "Unknown USB Device (Device descriptor request failed)".

I'm working on a very very "fresh" Win10 installation, so it might be a driver issue, but as stated on ST's website the VCP driver preinstalled with Windows 10 should be the preferred one, and in any case ST provides VCP driver only for Windows 7 and Windows 8.

The same USB cable plugged in a printer works fine, so I'd exclude a cable problem.

Debugging the code, I can say that the whole USB initialization procedure in MX_USB_DEVICE_Init() is completed without errors.

This is the relevant part of the schematic: Schematic, p1

Schematic, p2

And this is the PCB: PCB USB Connector CN1 on the left, DP and DM routed differentially to D301, the TVS diode, and then to the uC pins. R103 is the DP pullup resistor.

Clock and USB configuration (I can share the full .ioc file if necessary): clock configuration

usb config 1

usb config 2 Device Descriptor is the default one.

Code: enter image description here SW is completely generated with CubeIDE, I just added the LED toggle in main function.

Notes:

  • As per AN4879 USBD+ has 1k5 pull-up to VDD (3.3V)
  • VDD (3.3V) comes from a 5V-3.3V LDO (AMS1117-3.3). 5V from USB is regulated to 3.3V and powers the uc
  • D301 is TVS Diode USBLC6-2SCS (Datasheet)

Any suggestion on what's wrong with the design and/or on how to solve the issue?

\$\endgroup\$
5
  • \$\begingroup\$ Why do you pull the USB data line directly to 3.3V? If your code takes a week to boot before USB is initialized, the computer has already given up trying to communicate with the MCU. Your code also does not seem to actively handle any USB comms, but it might happen in the background (USB or timer interrupts). \$\endgroup\$
    – Justme
    Dec 29, 2022 at 19:37
  • \$\begingroup\$ I followed AN4879, in particular section 3.1.2. In the same application note, is said that this uC does not embed the 1k5 pullup resistor, so an external one must be provided \$\endgroup\$ Dec 29, 2022 at 19:46
  • 2
    \$\begingroup\$ Yes, it needs to be pulled up. All I am asking is, how much it makes sense to say to the PC you are ready to enumerate, even if the MCU is not yet ready. Try connecting the resistor after MCU has booted, initialized and ready for enumeration. If it works on other PCs or OSes (Linux, Mac OS, Windows) then that might be the problem. Only provide a pull-up when ready. \$\endgroup\$
    – Justme
    Dec 29, 2022 at 19:56
  • \$\begingroup\$ using a capacitor to delay the pull-up might be a cheap & hacky way. \$\endgroup\$ Dec 29, 2022 at 21:16
  • \$\begingroup\$ In the end the problem was the concurrency of CAN and USB that is not possible on this uC. Once CAN is disabled, USB works ok as far as I can tell. I checked STM32F103 Nucleo reference schematic, if I understand correctly they use a BJT to implement what you suggest, pulling up USBDP only when certain external conditions are met. Thanks for pointing this out, I might borrow the idea in future design! \$\endgroup\$ Dec 29, 2022 at 23:20

1 Answer 1

2
\$\begingroup\$

Answering my own question...the answer lies here:

In low, medium-, high- and XL-density devices, the USB and CAN share a dedicated 512-byte SRAM memory for data transmission and reception, and so they cannot be used concurrently: the shared SRAM is accessed through CAN and USB exclusively. So the USB and CAN can be used in the same application but not at the same time on STM32F1.

If I disable the CAN peripheral everything works as expected, the USB device is recognized and transmission and reception over USB work ok. If I re-enable the CAN peripheral, the problem appears.

The information is probably somewhere on the datasheet but I missed it when selecting the uC.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ This note is burriend in the bxCAN description chapter in the reference manual, 24.2. "In low, medium-, high- and XL-density devices the USB and CAN share a dedicated 512- byte SRAM memory for data transmission and reception, and so they cannot be used concurrently (the shared SRAM is accessed through CAN and USB exclusively). The USB and CAN can be used in the same application but not at the same time" \$\endgroup\$
    – Flexz
    Dec 30, 2022 at 6:45
  • \$\begingroup\$ I surely "should" have found this piece of information, but at least some kind of warning from CubeMX when activating both USB and CAN at the same time would have been much appreciated... \$\endgroup\$ Dec 30, 2022 at 10:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.