Posted on May 07, 2018 at 20:09Hi guys,
It's been a LONG couple of days resolving the issue of the DFU USB boot loader not invoking during normal operation. Tried many things, too numerous to go. The USB analyzer was indicating that the STM32 wasn't even trying to enumerate when switching to DFU mode even though the normal CDC serial would enumerate and work fine.
Bleary eyed I headed home and got some sleep. After coming back in, after sleeping on it and thinking about how the board was operating, I went back through AN2606 AN2606 it states that the bootloader is only autobaud, autoconfig for USART1,2 and 3 and then only after receiving a 0x7F.
In this case, I have a GPS port streaming on UART4. I disconnected the GPS tx/rx from the CPU by removing some debug jumpers and Poof!! the cpu would now BOOT0 into DFU mode and properly enumerate as a DFU device. Apparently it was incorrectly selecting UART4 (or there was some other internal Bootloader issue -- I'd need to see the 0x92 bootloader code to determine that)
Anyway there are two other issues I found (at least with trying to use the STM32CubeProgrammer in DFU mode).
The first is that the default USB driver mapped to the DFU is incorrect. I needed to select/install a different driver using the device manager for it to recognize the enumerated device (currently the libusbk driver though there's more testing to do.
The second is that the download of the bin or elf file over DFU doesn't work correctly. Apparently the 0x92 bootloader is picky about byte alignment as well as padding of the file to a given boundary condition. Since the program download file starts on a proper boundry already it must be the packet size and padding. If that is truly the case then the STM32CubeProgrammer is going to have to adjust those last packets by padding them out to prevent the failure modes taht I've detected.
Comments and observations are welcome. An immediate fix by the STM developers would be better as without out it the STM32CubeProrammer is a boat anchor in DFU mode.
Kent
