We used the STM32CubeMX program to generate a USB Custom HID. The program works and we can leave the application and enter the bootloader. The BOOT0 pin is high and the BOOT1 pin is low so it always runs the bootloader from reset. We then tell it to leave DFU to run our HID. The bootloader works and we can reprogram with a new DFU file. Sometimes when we leave DFU to return to HID or leave HID to enter DFU, it fails to enumerate. When we use the debugger to determine where it is, it is stuck in a loop at address 0x1FF0162C to 0x1FF01632.
0x1FF0162C 601A STR r2, [r3, #0x00]
0x1FF0162E 6804 LDR r4, [r0, #0x00]
0x1FF01630 428C CMP r4, r1
0x1FF01632 D0FB BEQ 0x1FF012C
R0 holds 0x200000B0
R1 holds 0x00000AAA
R2 holds 0x0000AAAA
R3 holds 0x40003000
R4 holds 0x00000000 when it works
R4 holds 0x0000AAAA when it locks up
It looks like the code is writing a 0x0000AAAA to 0x40003000 (IWDG_KR) to restart the watchdog and reading the SRAM at address 0x200000B0 until it does not equal 0x0000AAAA.
We can go back and forth between DFU and HID mode many times until the lockup occurs. Probing the D+ line it is stuck high. If we manually set the program counter to one instruction after the BEQ instruction which is a POP, it continues running and enumerates. We can modify the R4 contents to 0x0000000 at the CMP instruction to get it to run again. If we reset the CPU and start running again it still does not work, but if we unplug the USB cable, reset the CPU and start running again, then plug the USB back in, it enumerates in DFU mode. The target is designed to be in an embedded system where the USB cannot physically be unplugged and plugged in without disassembly, which does not resolve the problem while bench testing and connected to the PC unless we power cycle or reset the board in between. We can power cycle it to get back to DFU mode with the debugger removed. The STM32 is self powered and attached to an onboard 4-port USB 3.0 hub. The onboard hub is self powered and connected to a 4-port USB 3.0 hub attached to a Windows 10 PC.
Environment information.
We are debugging in Keil uVision v5.20 with an STLINK V2 using SDIO on a Windows 10 PC. The C compiler is v5.06 update 2 (build 183).
The STM32CubeMX version is 5.6.1.
The STM32CubeMX MCU package is STM32L1 Series v1.9.0.
Could this be a bug in the bootloader, or could this be an issue with the USB hardware?
If any more information would be helpful, let me know.
