B-L475E-IOT01A USB DFU is stuck in different states.

[Keyur Thumar]

I am using B-L475E-IOT01A (STM32L475VGTx) dev kit and this article for DFU and I am getting following issue.

Sequence of process I do is as below.

• Erase the whole flash.
• Flash the bootloader created based on above video.
• Make a DFU using DfuSe Tool and It works.

But when I want to upgrade the device again with DfuSe Tool, DFU process stuck or gives me error. Please see below screenshot.

Upgrade file is simple LED blinking application. It works when I do the DFU first time. But for upcoming DFU does not work.

Can anyone please help me out here ?

[Mike_ST]

Hello,

DfuSe Tool is flagged ad NRND on its homepage.

Please use STM32CubeProgrammer instead.

Is BOOT0 Pin tied to 1 ?

[Keyur Thumar]

Thanks @Mike_ST​ for the prompt response.

I have tried with BOOT0 Pin tied to 1 by shorting SB9.

 

By doing that device is able to detect in STM32CubeProgrammer as USB device.

It can flash the firmware but flashed firmware doesn't run properly. i.e. I have flashed led blinking program. LED does not blink. It stays continuously ON.

Another observation is, there are 2 drivers for USB.

By installing first, device is detected in DfuSeTool and by second it detects in STM32CubeProgrammer.

When I install first one, It stays detected in boot mode in DfuSe tool even after I press Leave DFU Mode. This change I observed after BOOT0 pin tied to 1.

In case of STM32CubeProgrammer, when BOOT0 was at 0, device was not able to detect. When I made BOOT0 as 1, device is detected as USB all the time. And upgrade process logs are as below.

 

Also I have observed that UART logs have stopped after BOOT0 pin tied to 1.

Can you please help me further ?

[Mike_ST]

The right driver to use is STM32 Bootloader.

You'll have to keep the BOOT0 pin to 0 as you're doing your own bootloader.

[Keyur Thumar]

Thanks @Mike_ST​ 

I have installed STM32 Bootloader. and kept BOOT0 pin as 0.

But the same result.

Firmware flashed. No uart logs. No led blinking.

One more interseting thing I noticed when I installed STM Device in DFU Mode driver to use with DfuSe Tool.

I can see 3 target here instead of 1.

 

Okay now so you are suggestig to use CubeProgrammer. With that any bootloader source code provided by ST which I can use with Cubeprogrammer? like right now I am using bootloader created with the help of tutorial.

[Mike_ST]

Well I'm not sure what is your setup.

I have a  B-L475E-IOT01A board, so if you feel like, please share your project source (Bootloader project+ LED blinking application).

[Keyur Thumar]

Hey @Mike_ST​ 

Please find the source code from here.

https://drive.google.com/drive/folders/17yAcTbw08RmLOnvRW0Zigvt3q3PYccdR?usp=sharing

[Keyur Thumar]

Hey @Mike_ST​ 

Have you got a chance to check my code ?

[Mike_ST]

Hello,

yes, I compiled and tried it.

But I had to disable the "printLogs" function, I don't know whether you added the "printLogs" calls in the USB stack, but it shouldn't be there, it is messing with USB operations.

printLogs should be called from your app only.

After disabling the printLogs, I used the STM32CubeProgrammer and could upload the led blink app.

Please note that when a valid application is present, the bootloader jumps to that application, you'll need to press the blue button when releasing the reset button in order to jump to the bootloader again.

Hope that helps.

[Keyur Thumar]

Thanks @Mike_ST​ for the checking.

I have tried with printLogs diasbled and it worked as below.

1. With ST-Link Connection, erased the full chip.
2. Flashed the bootloader with ST-Link
3. Connected STM32CubeProgrammer with USB.
4. Flashed LED blink application and it worked.

But now again I have wanted to flash the new application. SO I pressed the User Button (Blue button) when releasing the Reset button. So it went into the DFU mode and can be detected with STM32CubeProgrammer. Now with that I have tried to flash the new LED blink application and it failed. Attached are the STM32 Cube Programmer logs.

[Mike_ST]

That's because the flash is no more empty after you flashed the LED app.

I think the DFU protocol implementation is incomplete.

If you want a quick workaround for your case, just modify the following line in usbd_dfu_if.c,

function MEM_If_Erase_FS(uint32_t Add):

 //eraseinitstruct.NbPages = 1;

eraseinitstruct.NbPages = (FLASH_BANK_SIZE/FLASH_PAGE_SIZE) - GetPage(Add);

That should erase the BANK 1 until the end, instead of the first page only. So the flash operation can succeed again and again.

Please read the AN3156

https://www.st.com/resource/en/application_note/cd00264379-usb-dfu-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdf