USB DFU on STM32L432 and STM32L433

[Rob.Riggs]

Posted on March 11, 2017 at 22:51

I'm trying to use USB DFU with our custom boards, one based on STM32L432KC and another on STM32L433CC, and I am having a problem using two DFU programs on Linux:

http://dfu-util.sourceforge.net/

and

https://github.com/plietar/dfuse-tool

(a Python program).  Both of these tools fail to program these MCUs.  I should note that I have a very similar board using an STM32L476 part which does not exhibit this problem.  Also, the USB DFU bootloader on the 432KC Nucleo-32 board exhibits the same behavior, but USB electrical path on the breadboard I rigged up for testing is a little more suspect in that case.

dfuse-tool fails with: usb.core.USBError: [Errno 32] Pipe error

dfu-util fails with: Error during download get_status

I can make dfu-util work by passing in '-t 1024' (or lower) to reduce the transfer size.  During this time I get a number of 'Poll timeout 21 ms' warnings, but it completes successfully.

I do not believe that there is an issue with the MCU or with the USB signal path because the firmware implements a CDC interface and that appears to be working with no issues.

I have read AN2606 and noted the issue with the original bootloader on the STM32L43x parts.  All of the MCUs I have used report bootloader version 0xFF.  Is this a manifestation of that problem?

Are parts with the fixed bootloader (0x10) available from any distributors currently?  The ones I am using in my prototypes were purchased fairly recently in the US from a major distributor.

#bootloader #stm32l433 #stm32l432 #stm32l4 #dfu #usb

[nichtgedacht]

Posted on March 12, 2017 at 14:43

Hi

I'm using DFU in this bootloader:

https://github.com/nichtgedacht/L433CCTx-bootloader

It is important to have the right FLASH_DESC_STR in usbd_dfu_if.c

Transfer size is 1024 but ganularity for dfu-util is 2k. (2k erase, 2k program ...)

See also:

https://community.st.com/0D50X00009Xke9fSAB

Dieter

[Rob.Riggs]

Posted on March 12, 2017 at 22:52

Hi Dieter,

I would much prefer to use the system bootloader.  There are much fewer things that can go wrong, it leaves more flash available, and it's always available.  Having a reliable system bootloader was one of the things that attracted me to the STM32 MCUs.

Maybe I am being naïve relying on the system bootloader.  What are the benefits of using one's own bootloader in this case?  Why did you choose to use this bootloader instead of the system bootloader?

Rob

[nichtgedacht]

Posted on March 13, 2017 at 01:34

Hi

Your questions seems not to target the bootloader in ROM to me at first glance.

Benefits of a user bootloader are:

1. Will be entered after a reset by software.

2. You can control how the device is working and how it's visible while running the bootloader.

Dieter

[Rob.Riggs]

Posted on March 25, 2017 at 17:36

It appears that this issue is due to an change somewhere in the USB stack on Linux, whether in the kernel or libusb, which causes bus stalls to be propagated up as EPIPE errors.  Handling these stalls properly in these tools resolves the issue for me.

[Rob.Riggs]

Posted on March 27, 2017 at 00:24

As I learn more about the details of the DFU protocol, it seems that both versions (0xFF and 0x10) of the STM32L43xx system DFU bootloader return incorrect values from DFU_GETSTATUS requests.

Specifically, the bwPollTimeout values returned after FLASH 'write memory' and 'erase' are incorrect.

For the 0xFF version of the bootloader these are returned as 20ms from both FLASH 'write memory' and 'page erase' commands.  For the 0x10 version of the bootloader it returns 120ms for 

FLASH '

write memory

' and 10ms for 'page erase'.

As Tormod Volden points out

https://sourceforge.net/p/dfu-util/tickets/40/

, the proper value for both is about 25ms based on the datasheet.  Attempts to send the second 

DFU_GETSTATUS

 before the commands are complete result in a USB STALL.