2009-05-08 07:46 AM
Possible DFU bug for NOR flash memory when using
2011-05-17 04:11 AM
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 Petter2011-05-17 04:11 AM
Hi Petter,
Great Thanks for the your detailed report, much appreciated. I will escalate the fix, So it will be corrected. Cheers, STOne-32.