Coldfire V1 Flash want to write 16bit

[galahad]

Hello,

is it possible to write 16bit words to a coldfire v1 32bit flash this way:

1. write $1234ffff first to a flash cell

2. write $ffff5678 later to the same cell, result is $12345678

Would this reduce the life time of the coldfire flash rom significantly?

Thank you for any suggestions

Joerg 

[kef]

It should work, however it is against what datasheet says

CAUTION

A flash block address must be in the erased state before being programmed.

Cumulative programming of bits within a flash block address is not allowed

except for status field updates required in EEPROM emulation applications.

Sure write $1234FFFF, then $12345678 to the same address (without sector erase between two writes) will reduce the lifetime of flash. But also there's no guarantee that write $1234FFFF, then $FFFF5678 won't reduce the health of flash.

[galahad]

kef, thank you.

"except for status field updates required in EEPROM emulation applications" Unfortunately i found no Coldfire app note for EEPROM enulation that uses something like that.

The datasheet recommends a similar way of programming the flash rom if the power is low:

"Flash memory on MCF51QE128/64/32 must be programmed 32-bits at a time when the low-voltage detect

flag (LVDF) in the system power management status and control 1 register (SPMSC1) is clear. If

SPMSC1[LVDF] is set, the programming sequence must be modified such that odd and even bytes are

written separately. The MCF51QE128/64/32 flash memory is organized as two 16-bit wide blocks

interleaved to yield a 32-bit data path. When programming flash when LVDF is set, alternate bytes must

be set to 0xFF as shown in Table 4-8. Failure to adhere to these guidelines may result in a partially

programmed flash array."

confused...

Joerg

[sebasira]

Hello!

I'm working with MCF51QE and with routines form AN3942 (ColdFire V1 Flash Programming Routines).

I'm able to program an erased sector of flash, but I can not seem to re-program an allready programmed sector.

I mean, I load application to MCU and write 0x12345678 to address 0x2000.... Let's say that later when some event happens, i want to replace that value with 0x00112233... When I go check address 0x2000 the old value is still written.

After the first programming I execute Flash_Erase at address 0x2000 but that sector remains written... I assume that when erased value should be 0xFFFFFFFF.... What could be wrong?

More over, both routines Flash_Erase and Flash_ByteProgram return error code 0, so no error over there...

Any comment would be appreciated! Thanks! 

[imnewbie]

Hello

Did you find a solution  for the problem you were having?

I'm trying to write and read from flash too implementing the AN3942, the debugger does not pass the page_erase section of code.

do you have any pointers about this issue ?

thanks

[galahad]

Hi

we didn't work on the V1 for a while, but a new project with the AC128 just starts so in some weeks i might knew more...

Joerg

[TomE]

> Let's say that later when some event happens, i want to replace that value with 0x00112233...

Then you have to erase the whole flash BLOCK and then rewrite all the data again, together with your changed value.

EEPROM allows byte erase. FLASH is cheaper than EEPROM because it requires the whole block to be erased.

Just because the routine didn't return an error code doesn't mean it didn't get an error, but it may have bugs that mean the errors aren't checked or aren't reported back. The "normal" address for a flash erase command is the base address of the block. Maybe the function you're using doesn't expect the "wrong address" to be passed in and doesn't check for that condition.

If you want to change individual locations, then you need some "EEPROM Emulation" software that provides functions that seem to allow individual reads and writes, but behind the scenes is storing "master" and "diferences" and is handling block erases and data copies.

Someone asked for this here in 2007, and nobody has answered yet:

https://community.freescale.com/thread/36134

Tom