USB related hardfault when connected to Linux but not Windows

[PG.19]

I have a stm32f4 nucleo board. Under Windows, I started a project using CubeMX and did a bunch of development. Everything was working as expected.

I then moved to Linux (Ubuntu 19.04), and the device just started hard faulting constantly:

(gdb) bt
#0  HardFault_Handler ()
    at /home/phil/dev/tros/port/common/mcu_stm32/vendor/ST/CubeProject/Core/Src/stm32f4xx_it.c:42
#1  <signal handler called>
#2  0x00000000 in ?? ()
#3  0x08003fbc in HAL_DMA_Start_IT (hdma=0x0, SrcAddress=<optimized out>, 
    DstAddress=<optimized out>, DataLength=<optimized out>)
    at /home/phil/dev/tros/port/common/mcu_stm32/vendor/ST/CubeProject/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_dma.c:474
#4  0x08005a76 in ah_USBCDCWriteAsync (drv=0x1044, data=<optimized out>, len=0, 
    callback=<optimized out>) at /home/phil/dev/tros/port/common/mcu_stm32/bsp/ah_bspUSB.c:154
#5  0x080059a4 in USBCDCRecvHandler (pdev=0x8006bb5, Buf=<optimized out>, Len=0x20013d58)
    at /home/phil/dev/tros/port/common/mcu_stm32/bsp/ah_bspUSB.c:78
#6  0x08004de8 in USBD_CDC_DataOut (pdev=0x20014d70, epnum=<optimized out>)
    at /home/phil/dev/tros/port/common/mcu_stm32/vendor/ST/CubeProject/Middlewares/ST/STM32_USB_Device_Library/Class/CDC/Src/usbd_cdc.c:722
#7  0x0800450e in USBD_LL_DataOutStage (pdev=0x20014d70, epnum=<optimized out>, 
    pdata=<optimized out>)
    at /home/phil/dev/tros/port/common/mcu_stm32/vendor/ST/CubeProject/Middlewares/ST/STM32_USB_Device_Library/Core/Src/usbd_core.c:342
#8  0x08000c7a in HAL_PCD_DataOutStageCallback (hpcd=<optimized out>, epnum=<optimized out>)
    at /home/phil/dev/tros/port/common/mcu_stm32/vendor/ST/CubeProject/USB_DEVICE/Target/usbd_conf.c:155
#9  0x0800118a in PCD_EP_OutXfrComplete_int (hpcd=hpcd@entry=0x2000149c <hpcd_USB_OTG_FS>, 
    epnum=536991708, epnum@entry=1)
    at /home/phil/dev/tros/port/common/mcu_stm32/vendor/ST/CubeProject/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_pcd.c:2143
#10 0x0800138c in HAL_PCD_IRQHandler (hpcd=0x2000149c <hpcd_USB_OTG_FS>)
    at /home/phil/dev/tros/port/common/mcu_stm32/vendor/ST/CubeProject/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_pcd.c:1068
#11 0x08000ab0 in OTG_FS_IRQHandler ()
    at /home/phil/dev/tros/port/common/mcu_stm32/vendor/ST/CubeProject/Core/Src/stm32f4xx_it.c:240

The TLDR:

• I can build / flash on Linux, but the device constantly hard faults
• I can build / flash on Linux, boot into Windows and the device works as expected
• I can build / flash on Windows, and the device works as expected
• I can build / flash on Windows, boot into Linux and the device constantly hard faults

[Tesla DeLorean]

Watch for malloc() / free() usage with the descriptors, and how you handle malloc() returning NULL

Look at what is faulting, look at what it is using as a pointer/memory address, and work that backward.

[PG.19]

Did you not read my post? It's faulting the the USB DMA path, but only when attached to a Linux host

[turboscrew]

I didn't quite get it. Do you mean that the hard faulting seems to depend on whether there is Linux or Windows on the other end of USB?

Or is it about debugger?

[PG.19]

> I didn't quite get it. Do you mean that the hard faulting seems to depend on whether there is Linux or Windows on the other end of USB?

Correct. I'm currently duel booting windows / linux. If I reboot from Windows -> Linux (and change nothing else) I start getting hardfaults. If I reboot back to Windows the hardfaults go away.

[Tesla DeLorean]

>>Did you not read my post? 

You posted a stack dump and posited that Windows works, Linux don't works. No real analysis of anything up the chain in terms of requests and parameter, and how they differ. That kind of reading your post? Got to read between the lines cause you give me ****

1. #2 0x00000000 in ?? ()
2. #3 0x08003fbc in HAL_DMA_Start_IT (hdma=0x0, SrcAddress=<optimized out>,

Something is NULL, figure out why. Instrument your code via SWV/UART so you can see what's going on before it unwinds the stack on you.

Turn the optimizer off so you can see more information. Review the instrumentation of working vs non-working contexts. Add sanity checking so you can flag when if first goes off the rails. You're not going to be able to debug stepping code in the debugger.

Hard Faults are pretty gross failures, not subtle issues that hide.

[Pavel A.]

Yes this is very possible, there is difference between behavior of Windows and Linux host on the other side of USB,

Different timing, different requests and their order. Different programming of the host controller on the PC side.

Get a sniffer and see what causes the error.

Once I had a hard time debugging a device that worked well against various Windows, but failed with some odd IBM Unix box.

-- pa

[turboscrew]

Yep, SOMETHING seems to be NULL...

Good catch, @Community member​ !