cancel
Showing results for 
Search instead for 
Did you mean: 

Possible DFU bug for NOR flash memory when using

petter
Associate
Posted on May 08, 2009 at 16:46

Possible DFU bug for NOR flash memory when using

2 REPLIES 2
petter
Associate
Posted on May 17, 2011 at 13:11

Hi!

I am new on the STM32 and the eval board but I however

think found a bug in the DFU firmware code for NOR memories.

I tried updating the STM3210E-EVAL demo firmware to the latest.

I used the DfuSeDemo application to do this and used these files:

STM3210E-EVAL_Demo_NORFlash_V2.0.0.dfu

STM3210E-EVAL_Demo_V2.0.0.dfu

The NORFlash dfu file repeatedly failed verification phase,

on address 0x6407FFFF. File data is FF while actual value is 8D.

As instructed the ''Optimize Upgrade Duration (Remove some FFs)''

was checked during upgrade operation.

I finally found out what seems to be going wrong and when I do not

check the ''Optimize...'' checkbox programing and verification succeeds!

By testing using the STDFU Tester program I realized that when the last

byte in a sector is FF the Length of the upgrade data sent to the device

becomes odd. As the NOR memory is 16 bit it will always write 16 bits,

hence the last byte that should be FF becomes something else.

I also think that I can pinpoint the location of the bug, which can be

fount in the USB library for the DFU Firmware example, see below.

This code adjust for odd data lengths but do not append FF to the

MAL_Buffer!

nor_if.c

--------------

uint16_t NOR_If_Write(uint32_t Address, uint32_t DataLength)

{

if ((DataLength & 1) == 1)

{

DataLength += 1;

}

FSMC_NOR_WriteBuffer((uint16_t *)MAL_Buffer, (Address&0x00FFFFFF), DataLength >> 1);

return MAL_OK;

}

--------

The flash_if.c and spi_if.c seems to handle this correctly since they add

FFs to the MAL_Buffer in these cases.

regards Petter

16-32micros
Associate III
Posted on May 17, 2011 at 13:11

Hi Petter,

Great Thanks for the your detailed report, much appreciated. I will escalate the fix, So it will be corrected.

Cheers,

STOne-32.