usb_device_f0_custom_hid doesn't work when compiled in debug mode

[janoc]

I have built the usb_device_f0_custom_hid for F042 and I am playing with it on the F042 Nucleo board from ST. I had to disable the PA11/12 remapping, as this board doesn't need it (it has the 32pin TQFP MCU version) but otherwise the code is stock from the example.

When I compile the example in debug mode (scons mode=debug hsi=8000000 float=soft mcu=f042), the device fails to enumerate:
[119724.580187] usb 3-2.1: new full-speed USB device number 111 using xhci_hcd
[119724.679340] usb 3-2.1: device descriptor read/64, error -32
[119724.853323] usb 3-2.1: device descriptor read/64, error -32

Wireshark shows a malformed response, then the host attempts a few more times (reset & re-enumeration) and gives up.

However, when I compile the same code using the small or fast mode, the enumeration works:
(scons mode=small hsi=8000000 float=soft mcu=f042;
scons mode=fast hsi=8000000 float=soft mcu=f042)

[119770.469165] usb 3-2.1: new full-speed USB device number 114 using xhci_hcd
[119770.713545] usb 3-2.1: New USB device found, idVendor=f055, idProduct=7201
[119770.713547] usb 3-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[119770.713548] usb 3-2.1: Product: Custom HID
[119770.713549] usb 3-2.1: Manufacturer: Andy's Workshop
[119770.713549] usb 3-2.1: SerialNumber: 1.0.0
[119770.715005] input: Andy's Workshop Custom HID as /devices/pci0000:00/0000:00:1c.0/0000:03:00.0/usb3/3-2/3-2.1/3-2.1:1.0/0003:F055:7201.0009/input/input68
[119770.715131] hid-generic 0003:F055:7201.0009: input,hidraw6: USB HID v1.11 Device [Andy's Workshop Custom HID] on usb-0000:03:00.0-2.1/input0

I am using this version of GCC:
gcc version 5.2.1 20151202 (release) [ARM/embedded-5-branch revision 231848](GNU Tools for ARM Embedded Processors)

It seems that when optimization is disabled (debug), something is getting miscompiled.

[henrychoi]

Reproduced the problem on my F042, and can work around in Release mode. But I noticed quite another problem: the Linux host I am connecting to reports the following /var/log/messages

usb 1-1-port2: over-current change

This is strange because my Vbus is floating (nothing connected to it)! Is it a crime to not actually draw any current on the Vbus if you declared it as bus powered?

[janoc]

That's strange, have never seen that one before unless the port was getting overloaded and the overcurrent protection has tripped. The kernel just reports that that has happened.

If your VBus is floating (nothing connected to it), I would guess you have a flaky USB hub somewhere (even on a motherboard).

[henrychoi]

Is your host Windows? I am connected straight to my host, which is Linux (Raspian). I measured voltage across a 220 Ohm resistor I put (along with an LED) on the Vbus and GND, and it's essentially reading noise. It's funny that before the DP line is pulled up (by the example FW), the USB supplies current to light up the LED, but this OC condition is flagged after the DP is pulled up (regardless of whether the enumeration succeeds). I just downloaded the Raspberry Pi kernel source to understand what the host is unhappy about.

Did you connect your USB's Vbus to anything, or do you leave it floating? Since I made my own TSSOP20 breakout board (I use STM32F042F6P6 just like Andy, but I had already soldered my chip to the adapter board by the time I learned about Andy's dev board), I don't have the USB ESD protection chip, I am wondering if I damaged the chip somehow. But given that you are using the Nucleo board (which doesn't have D+/- protection either--according to the board schematic), I doubt that theory.

As for the original problem (no enum in debug mode), I chased the problem to the target returning Nak in response to GET_DESCRIPTOR. I am considering non-invasively instrumenting the example with non-invasive write to SPI ( up to 4 bytes) to learn what the difference may be.

[janoc]

This has little to do with the kernel, the kernel just reads the overcurrent flag on the host controller/hub and reports it. That's a flaky hw, IMO. See here:

https://livegrep.com/search/linux?q=over-current%20change&fold_case=auto&regex=false&context=true

It could be also simply inrush current of the target tripping the OC protection. I was doing this with the stock Nucleo, I don't recall how that board is wired. But the schematic is available on ST's website.

My host is Linux, normal desktop x86_64 machine (not RPi).

[henrychoi]

Yes, I found those lines too. But I forgot to tell you: I reproduced the OC messages on another RPi. I still want to understand this problem, because I work with RPi a lot. Might as well understand this sort of problem thoroughly if I am going to continue working with USB.

[janoc]

I would suggest putting a shunt in series with the Vbus line on the USB connector and hooking up a scope there to check whether or not there is any sort of power spike that could trigger this.

[henrychoi]

I already did this. Granted I am only using the Saleae Logic Pro (50 MHz analog sampling) but all I see is noise when I subtract the 2 voltages across 220 Ohm. Besides, I was getting this error even with the Vbus line floating (i.e. absolutely no current through Vbus), so it must be some other problem.

[janoc]

Hmm, i don't know what sort of USB hub the RPi uses but it is possible that it is sensitive to drawing current from the data lines too. Or maybe it isn't decoupled properly and when the VBus line floats on the target side (there should be 5V on it from the host, though), the OC gets tripped by some noise.

I would also suggest using a proper scope - the Saleae logic analyzer may not be able to capture a narrow fast pulse which may be sufficient to trip the host.

[henrychoi]

Chased the problem across different OS, and different eval boards. I found a microscopic strand of the USB cable shield wire shorted to the Vbus by taking a macro picture of my setup. The HW wasn't crazy. All back to working form. Thanks!

[janoc]

Uff, that's a nasty problem to find! Glad you have managed to resolve it.

[henrychoi]

I think now that the problem that stymied me 2 years ago when I tried to get a ST HAL based HID example going on my Nucleo-F042 board is also this problem: that enumeration doesn't work in debug mode. Since tracing is preferred to invasive debugging anyway, I modified stm32plus's lib/include/spi/Spi.h to NOT block for receive and just shove out 2 words back to back (this fits in the SPI FIFO), for a 32-bit trace point visible on logic analyzer, as you can see below.

The example uses the 48HSI to drive everything, so using DIV_2, the SPI is clocked out at 24 MHz, and it takes only ~2 usec to push out the 2 words.

•  if(_direction==SPI_Direction_2Lines_FullDuplex) {
  

•  if(_direction==SPI_Direction_2Lines_FullDuplex && dataReceived != nullptr) {
  

[janoc]

Just to be clear - my original report was about the enumeration failing without a debugger attached. Merely compiling in "debug mode" (= with optimizations disabled, not putting the CPU in debug mode!), makes it fail. So your SPI problem is very likely an unrelated issue (possibly a HAL bug?) or I don't follow your reasoning how it is related.

[henrychoi]

Apologies for the poor explanation.
I don't know yet why the debug code is a problem. Given that I seem to have run into this with ST HAL 2 years ago, maybe the difference is in USBD_LL or PCD code. What I was saying is than invasive debug (halting debug) is not a viable debugging technique with USB anyway (as Andy described in his blog); you have to fall back to non-invasive tracing, which is what my mod to the stm32plus lib's Spi send will do (if you supply no receive buffer--just send send send; since the Spi TX FIFO is 32 bits, you can emit 2 words back to back in just 2 usec, and instrument the code sufficiently to understand what's going on).

[janoc]

That's beside the point - you may want to compile in debug mode (with debugging symbols and optimization disabled) for other reasons, not only to debug USB. The MCU is rarely used to service an USB port only. Also if the bug is in the compiler it is important to track it down. In this case it manifests itself in a very obvious manner by the USB enumeration failing but in other cases the failure could be silent and cause something to mysteriously stop working later.

Re debugging with USB - it is completely fine, the USB link may time out (btw, you can elect to keep USB running even in halt, I believe, by setting some register bits) but you will still be able to debug other parts of the system.

Tracing is an option but debugging a stuck I2C or something like that without the ability to dynamically inspect (and potentially modify) registers is a pain. I am certainly not going to re-implement such feature over SPI.

I don't see how this would be related to ST HAL 2 when I have encountered this problem using Andy's library - which doesn't use it.

Please, I would appreciate if you could keep the debate on topic and not introduce unrelated tangents, in order to keep the discussion focused on the original issue.