STM32L1xx DFU bootloader in FLASH memory problems

pa2 · ‎2014-04-02

Posted on April 02, 2014 at 16:49

Hello, I have following objective and problems:

I want to have USB bootloader on STM32L1xx devices. My starting point is DfuSe demonstration example on PC side and Device_Firmware_Upgrade from STM32_USB-FS-Device_Lib example on microcontroller side. I want to add some custom features (like encryption etc) to bootloader...

Now the problem is:

I can get ST board (my custom HW) in DFU mode without problem, I can successfully DOWNLOAD *.dfu file to uC, or UPLOAD from uC to PC through DfuSe Demo, but when I run Verify, I get ''Verify successful, but data not matching...'' error which is accompanied by new info window, that is saying ''Matching not good. First difference at address 0x08003110 etc...''

The strange is, that when I UPLOAD firmware from uC to computer and WinMerge it with original dfu file, only few bytes after 0x08003110 address are different from original firmware and rest of the firmware is identical. The firmware is actually working if I upgrade it through DFU, so I really don't understand, where the problem with those few different bytes arise from. (When I do full chip erase, than I write DFU bootloader on uC with ST-Link and than I upgrade firmware through DfuSe Demo, the firmware is working as well, and same bytes are different when I examine uC's content...)

I have tried with DfuSe Demo version 3.0.2 and with 3.0.3 as well. In 3.0.3 version, there the Verify button causes program crash. On uC side I have tried to build bootloader from STM32_USB-FS-Device_Lib V3.3.0 and V4.0.0 as well.

When I try to do the same thing on STM32F4 discovery board with DFU embedded in system memory (from production), the verification works all right.

Only problem, I suspect could arise from fact, that in my custom HW board, I use 26MHz external TCXO, so I run DFU from HSI oscillator, which shouldn't be so. But as I'm getting always same result and identical data differences I thing, this will not be the problem. Actually, it isn't the problem, because I ported project for STM32L discovery board, and the result is same - FW working after DFU upgrade, but few bytes are different, so verification goes wrong. And on STM32L board, there is a correct HSE oscillator.

Could anybody advise me where could be problem? I also noticed, that ST should release new, more stable version of DfuSe Demo, so hopefully, they release corresponding source code for uC as well.

Thanks for reading my long problem description!

#dfu-bootloader-flash-memory

chen · ‎2014-04-04

Posted on April 04, 2014 at 11:51

Hi

''Thanks for reading my long problem description!''

That is why no one has answered till now.

If you have problems with your custom hardware but not with the Eval boards, assume you have a problem with your custom hardware.

Verify there is not a Flash programming issue - how?

Do you have a debugger (ST-Link)? Use this to program the code and then use the DfuSe to verify it again.

Use the ST-Link to verify as well.

With the debugger - you can manual verify by looking at the flash in a memory dump.

pa2 · ‎2014-04-04

Posted on April 04, 2014 at 15:26

Thank you a lot for answer,

I have exactly same problem, when I do the same with STM32L discovery board, so it will not be problem of hardware.

I did similar test as you mention.

1) I do complete uC erase with ST-Link.

2) I put DFU bootloader application on uC with ST-Link.

3) I put final application on uC with ST-Link.

4) I download dfu file from uC to PC through DfuSe demonstrator.

5) Now when I do verification, it works alright.

6) Even when I put again dfu file obtained in this way to uC through DfuSe demonstrator and than do verify, it works alright. Even if in this point I verify with dfu obtained through Dfu File Manager from Hex file, verification works allright (especially this is very strange, because, when I put this dfu file to uC through DfuSe Demonstrator, than verification goes wrong)

There has to be something wrong with Dfu File Manager, which is creating dfu file from hex file.

chen · ‎2014-04-04

Posted on April 04, 2014 at 15:43

Hi

Sounds like Device_Firmware_Upgrade from STM32_USB-FS-Device_Lib example is not working properly.

Is this a demo project for a particular dev board?

Do you have that dev board?

Did you port this to your own borad/processor?

pa2 · ‎2014-04-04

Posted on April 04, 2014 at 17:43

From Description of the USB Device_Firmware_Upgrade Demo

Hardware environment

====================

This example runs these STMicroelectronics evaluation boards and can be easily tailored to any other hardware:

- STM3210B-EVAL

- STM3210E-EVAL

- STM32L152-EVAL

- STM32F373C_EVAL

- STM32F303C_EVAL

- STM32L152D-EVAL

I don't have the board, but all HW related code in DFU on uC side is button reading to enter DFU after power on, so I think, I didn't make a mistake in this. Processor is same as on STM32L152-EVAL board. One thing could be errata Section 2.5.1: Pull-up resistor has a value lower than 1.5 kOhm, which is something I don't have on my board - but I doubt it would cause every time exactly the same error. And as I mentioned in previous post, there is way to get verify working.

Just to remember, the upgraded firmware through DfuSe is working on microprocessor, just few first bytes are modified (I guess I will have to examine, what exactly is changed and where in the process...).

Thank you a lot!

pa2 · ‎2014-12-26

Posted on December 26, 2014 at 16:44

Today I examined the source code for mcu side of DFU more closely and found the error.

In flash_if.c file FLASH_If_Write function this modification has to be made:

// if (malPointer < ((uint32_t *)MAL_Buffer + DataLength))

if (malPointer < ((uint32_t *)MAL_Buffer + DataLength / 4))

othervise it will write erroneous data to FLASH due to wrong copied data from DFU PC application (Instead of zeroes where nothing should be written, some data from previous image are written, so actual image is written with errors on its beginning).

I hope this can help to somebody...