STM32L152-EVAL DFU example

aodhancoffey · ‎2015-05-06

Posted on May 06, 2015 at 13:10

Hi All,

I am attempting to update my STM32L152 board over USB using the DFU driver (STM32_USB-FS-Device_Lib_V4.0.0).

I generated a .dfu file using ''DFU file Manager'' and the supplied binary_template project. I left all options as default when creating the image.

I then uploaded the DFU example project to my board. Held the joystick in the up position and reset the board. Windows detects my board as a ''STM Device in DFU mode'' correctly.

I then fired up ''DfuSe Demo'' which detects the dev board and its target memory (i.e. Internal Flash). Again I leave everything at default, choose my .hex image and hit upload. After a couple of seconds I get the message ''Target 00: Upload successful!''. I then click ''Leave DFU mode'' and power cycle my board.

However the image I expected to be loaded (a blinking LED demo) does not start! I have tested this demo separately and it works correctly if flashed using a J-LINK.

Am I missing anything?

Do the boot0 and boot1 switches need to be set in any particular configuration? (I have Boot0 =0 and Boot1 =0 which is correct for User Flash).

Does it matter if the board is powered over USB or external? (I am using external PSU).

Is it important to set the Vendor, Product and Version ID when generating the .dfu image? I have these set as default (Vendor = 0483, Product = 0000, Version = 0000) Target ID = 0, target Name = ST...

Hamid.Wasti · ‎2015-05-09

Posted on May 09, 2015 at 23:45

> .....choose my .hex image and hit upload.

You are supposed to be loading the .dfu file, not the hex file.

The ''Upload'' option is to read data from the device to your computer. This is not what you want.

You need to make sure you click the ''Choose'' button in the ''Upgrade or Verify'' section of the screen then hit ''Upgrade'' to program it in the Flash. To be sure, you can do a ''Verify'' after that.

Assuming all the above in your post is a typo and you are actually Upgrading a DFU file, then consider the following.

When you compile the program and test it using JLINK, are you compiling for Flash or RAM? You have to make sure you use the correct link file to link for programming to Flash. If your file is linked for RAM, DFU will gladly download it to the processor's RAM and report success. But it will be lost when you reboot the processor, since you are most probably booting from Flash and not RAM.

If things are still not working, I would ''Upgrade'' the file using DFU and then instead of rebooting the processor, halt the processor using JLINK and inspect the memory to see if you can get some clues as to what is going on.

Good luck.

aodhancoffey · ‎2015-05-22

Posted on May 22, 2015 at 09:59

Hihwasti,

You are correct, I made a typo in my post. I was attempting to upload the .dfu image, not the hex image. Sorry for the confusion.

Also thank you for clarifying that the upload button is from the perspective of the device not the PC. Personally I find this confusing as the Dfuse software is in fact doing a memory dump

from the device

to the PC, in my mind ''download'' would have made more sense.

I have since compared my flash memory after doing an upgrade, with the original .dfu image. They match perfectly up until the 0x340 byte. After this is a mismatch as the dfuse verify option suggests.

I came across another forum post

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/STM32L1xx%20DFU%20bootloader%20in%20FLASH%20memory%20problems&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06...

which seems to describe the exact same issue. However, their ''fix'' did not work for me.

Thanks for your help! I will keep at it.

Hamid.Wasti · ‎2015-05-22

Posted on May 22, 2015 at 19:06

For a product I designed using the STM32L151, we have been using DFU as the primary means of downloading the firmware. We have programmed well over a thousand devices just this year with no problem. So I know it works.

One issue I found when I first played around with DFU was that the then latest version of the DFUSEDEMO program was extremely unreliable. We had to use an older version: v3.0.2 We have been using version v3.0.2 since with no problems.

You may want to locate this version and give it a try. It may be a software problem on the PC and not an issue on the micro.

Good luck.

Tesla DeLorean · ‎2015-05-22

Posted on May 22, 2015 at 20:52

We have been using version v3.0.2 since with no problems. You may want to locate this version and give it a try.

I'd mirrored a couple of older versions in this thread

[DEAD LINK /public/STe2ecommunities/mcu/Lists/STM32Discovery/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/STM32Discovery/DFU%20File%20Manager%20Unable%20to%20create%20image%20from%20this%20file&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800084C20D8867EAD444A5987D47BE638E0F&currentviews=248]https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/STM32Discovery/DFU%20File%20Manager%20Unable%20to%20create%20image%20from%20this%20file&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800084C20D8867EAD444A5987D47BE638E0F¤tviews=248

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

aodhancoffey · ‎2015-05-26

Posted on May 26, 2015 at 11:48

hwasti,

Thank you for the suggestions. I am already using DFUSEDEMO 3.0.2. I also had serious trouble with newer versions of the tools.

What version of the STM DFU driver are you using? I am using the latest, STM32_USB-FS-Device_Lib_V4.0.0.

Hamid.Wasti · ‎2015-05-26

Posted on May 26, 2015 at 13:28

> What version of the STM DFU driver are you using?

You mean the USB driver on the PC?

According to the ''version.txt'' file, I am using Version 3.0.1 (2009.11.24) which is the WHQL certified version of Version 3.0.0 (2009.07.03) supposedly with no other changes.

The certification report dated 2009.11.23 reports the ''Firmware Version'' as 3.1.0

aodhancoffey · ‎2015-05-27

Posted on May 27, 2015 at 10:38

>You mean the USB driver on the PC?

No, I am referring to the DFU device driver software loaded onto your STM32L152 board. The software that sets up your custom board as a DFU device when it is plugged in over USB to a PC.

I am using the ST

http://www.st.com/web/en/catalog/tools/PF258157

, version 4.0.0. It relies on a flash_if.c file for its flash init/erase/write and read routines. I have a feeling there is an issue with the FLASH_If_Write function.

As I mentioned before. This DFU driver works perfectly with my STM3210E-eval board. However, it is not working for my STM32L152 board. The main difference between the two is in the flash routines described by flash_if.c.

The L152 processors using half page programming where as the F1 uses word programming.

I am wondering what flash write routines you are using?

Hamid.Wasti · ‎2015-05-28

Posted on May 28, 2015 at 11:05

Sorry, can't help you there :( I am using the processor's native DFU code, which is accessed by holding the BOOT0 line high during reset. Once my application is programmed and running, it uses our own downloader to update itself.

aodhancoffey · ‎2015-05-28

Posted on May 28, 2015 at 11:48

hwasti,

No problem. I had my suspicion that you were not using a different approach. At least now I am more certain the issue resides in the flash write code.

Thanks for all your help,