Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

STM32F303RD: USB: unable to enumerate USB device #15112

Closed
douardda opened this issue Sep 27, 2021 · 8 comments · Fixed by #15132
Closed

STM32F303RD: USB: unable to enumerate USB device #15112

douardda opened this issue Sep 27, 2021 · 8 comments · Fixed by #15132

Comments

@douardda
Copy link
Contributor

douardda commented Sep 27, 2021

Description of defect

I am trying to use the USBSerial on a STM32F303RD based custom board and I cannot make the USB enumerated by the (linux) host.

The USB connection on the PCB seems to be properly done since I'm using it to DFU upload the firmware.
It uses an external 8MHz crystal and runs at 72MHz.

Since there is no official support for the F303RD, I've used the F303RE to inherit from, overloading the rom size.
The board description is

{
  "HP34970_FP_F303RD": {
    "inherits": [
      "MCU_STM32F303xE"
    ],
    "device_has_add": [
      "USBDEVICE"
    ],
    "mbed_rom_size": "0x60000",
    "bootloader_supported": true,
    "device_name": "STM32F303RE"
  }
}

Target(s) affected by this defect ?

STM32F303RD on a custom board.

Toolchain(s) (name and version) displaying this defect ?

I'm using platformio with:

  • framework-mbed 6.60900.210318 (6.9.0)
  • tool-dfuutil 1.9.200310
  • tool-openocd 2.1100.0 (11.0)
  • tool-stm32duino 1.0.1
  • toolchain-gccarmnoneeabi 1.90201.191206 (9.2.1)

What version of Mbed-os are you using (tag or sha) ?

6.9.0

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

n/a

How is this defect reproduced ?

Since the version of mbed shipped wit platformio does not come with latest fixes related to this problem (as described in #14736 and #14763 and other issues), I've added the to missing lines in USBPhy.c:

    __HAL_PCD_ENABLE(&hpcd);      //<!------ added as per #14736 - Does not fix issue on F401
    HAL_PCD_Start(&hpcd);    //<!------ I added this - This makes the USB device work as expected

But still no luck: any simple example code for the USBSerial like:

#include "stdio.h"
#include <mbed.h>
#include <string>
#include "def_hp34970_fp.h"
#include <USBSerial.h>

USBSerial pc2(false);  // PA_11 USB_DM, PA_12 USB_DP (with 1.5k pull-up)

void setup() {
  // tried with or without explicit call to init and connect
  pc2.init();
  pc2.connect();
  pc2.printf("Something\r\n");
}

int main()
{
  setup();
  while(true)
  {
	  ThisThread::sleep_for(500ms);
	  pc2.printf("New loop\r\n");
  }
}

ends up with the host giving:

[3885831.159503] usb 1-2: USB disconnect, device number 34
[3885833.683992] usb 1-2: new full-speed USB device number 35 using xhci_hcd
[3885833.812057] usb 1-2: device descriptor read/64, error -71
[3885834.052036] usb 1-2: device descriptor read/64, error -71
[3885834.288005] usb 1-2: new full-speed USB device number 36 using xhci_hcd
[3885834.420066] usb 1-2: device descriptor read/64, error -71
[3885834.659958] usb 1-2: device descriptor read/64, error -71
[3885834.768007] usb usb1-port2: attempt power cycle
[3885835.184035] usb 1-2: new full-speed USB device number 37 using xhci_hcd
[3885835.184278] usb 1-2: Device not responding to setup address.
[3885835.392149] usb 1-2: Device not responding to setup address.
[3885835.599840] usb 1-2: device not accepting address 37, error -71
[3885835.731923] usb 1-2: new full-speed USB device number 38 using xhci_hcd
[3885835.732120] usb 1-2: Device not responding to setup address.
[3885835.940115] usb 1-2: Device not responding to setup address.
[3885836.147876] usb 1-2: device not accepting address 38, error -71
[3885836.148015] usb usb1-port2: unable to enumerate USB device

PS: this board is a replacement front panel for the HP34790 I'm working on as described here: https://whatever.sdfa3.org/hp-34970a-data-acquisition-unit-part-5.html

@mbedmain
Copy link

@douardda thank you for raising this issue.Please take a look at the following comments:

It would help if you could also specify the versions of any tools you are using?

NOTE: If there are fields which are not applicable then please just add 'n/a' or 'None'. This indicates to us that at least all the fields have been considered.
Please update the issue header with the missing information.

@douardda
Copy link
Contributor Author

In case it helps, I can provide wireshark captures of the usb communications as well as signals captured with a dslogic+ analyzer. (Now I need to watch Ben Eater's videos again to refresh my memory about how USB actually works :-) )

@jeromecoutant
Copy link
Collaborator

H
Could you have a look on #15116 ?
Thx

@douardda
Copy link
Contributor Author

@jeromecoutant yes with great pleasure! I'll do that this evening! Thanks a lot.

@douardda
Copy link
Contributor Author

So there is improvement, the host can now enumerate the USB device and even see the CDC but the USB device immediately is disconnected:

[3981428.512629] usb 1-2: new full-speed USB device number 53 using xhci_hcd
[3981428.640372] usb 1-2: device descriptor read/64, error -71
[3981428.898472] usb 1-2: New USB device found, idVendor=1f00, idProduct=2012, bcdDevice= 1.00
[3981428.898473] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[3981428.898474] usb 1-2: Product: CDC DEVICE
[3981428.898475] usb 1-2: Manufacturer: mbed.org
[3981428.898476] usb 1-2: SerialNumber: 0123456789
[3981428.899981] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[3981429.054280] usb 1-2: USB disconnect, device number 53

I'll probably try to test this using a pure mbed toolchain, from the git master (instead of via platformio), including your PR as is, to see if it helps.

@douardda
Copy link
Contributor Author

douardda commented Oct 3, 2021

Hi @jeromecoutant
I've finally been able to compile my simple test code for my custom board using the current master (4587080) of mbed-os (still using platformio, thanks to this explanation on how to do that).

In the end the result was the same: the usb device is properly enumerated (thanks to your latest PR) but is immediately disconnected.

So looking at the signals (using my dslogic analyzer) I noticed after the handcheck and enumeration, the DP signal went (and stayed) down.

So I gave another look at the code in USBPhy_STM32.cpp, I noticed this piece of code (the part I'm concerned with) in USB_reenumerate():

#else
    // Force USB_DP pin (with external pull up) to 0
    mbed::DigitalOut usb_dp_pin(USB_DP, 0);
    wait_us(10000); // 10ms
#endif
}

While the initial setup code configure the USB_DP pin as a NoPull input pin, this part of the code put it as an output LOW, but do not reset it to it's normal config.

So I've replaced it with:

#else
    // Force USB_DP pin (with external pull up) to 0
    mbed::DigitalOut usb_dp_pin(USB_DP, 0);
    wait_us(10000); // 10ms
    mbed::DigitalIn usb_dp_pin_in(USB_DP, PullNone);
#endif

And now it works! At last!

~/e/hp34970-minimal  lsusb 
[...]
Bus 001 Device 117: ID 1f00:2012 mbed.org CDC DEVICE
Bus 001 Device 096: ID 2a0e:0020 Shenzhen DreamSource Technology Co., Ltd. USB-based Instrument
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Not sure this is the best way of reconfiguring the pin (should probably store its actual config before setting as a LOW output then restore it after, but no idea how to do that.)
I suppose the case USB_PULLUP_CONTROL should be checked also.

@jeromecoutant
Copy link
Collaborator

Thx @douardda
Could you propose a pull request with your working patch?
I will then make few non reg test with several platforms before merging.
Thx

@douardda
Copy link
Contributor Author

douardda commented Oct 7, 2021

@jeromecoutant sorry for the delay, see #15132 for my fix (seems to work for my STM32F303RD).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants