Unable to write to flash memory

[sue]

Posted on August 06, 2010 at 04:00

Unable to write to flash memory

[swhite2]

Posted on May 17, 2011 at 14:01

Susan,

I just tried the link in my post and its working fine. ST's library is written in C but you could call it from assembler if you want to. Or you could just rewrite the functions you need in assembler. PS: I didn't think anyone still coded in assembler. I wrote a LOT of it in years past but these days there's rarely a need unless you're trying to squeeze every ounce of performance from the processor.

[daviddavid94]

Posted on May 17, 2011 at 14:01

Flash is not like RAM.

''Erase'' means to fill a range of locations with byte-value 0xFF. ''Write'' means to change some of those 1's to 0's. In some systems, you can write a location more than once, as long as you're not trying to change a 0 to a 1. So, in some systems, you could write 0xFE, then 0x7E, etc etc. It sounds like your system is not one of these, and once you write (say) 0xFE to a location, you can't re-write that location, without an erase operation (for the whole page/sector/whatever). Hope that helps clarify things a bit.

[sue]

Posted on May 17, 2011 at 14:01

Brian and Stuart, thankyou for your posts.

Can you confirm what I think I have gleaned from all this. (by the way I am using the STM32F103ZE-SK board). 1. You can write something to a location in flash memory but you can't write to that   location again unless you erase the ENTIRE PAGE first. 2. You can only turn bits off, not on. 3. If, for example, you are receiving bytes of a message via the USART, you cannot store the message in flash memory because you have to erase the page for every byte that comes in, therefore you only ever end up with the last bye received. If all this is correct, what is the point of flash memory? Also Stuart, we have to use assembler, and I did find the library with the stuff that came with the board but haven't yet had a chance to try to decipher it.  Thanks.

[swhite2]

Posted on May 17, 2011 at 14:01

Flash is useful because it is non-volatile unlike RAM. However it is not a good choice when the data changes frequently and/or rapidly.

Flash life is in the order of 10,000-100,000 writes. That may or may not be sufficient for a given application. As a designer you must estimate the frequency of writes vs the lifetime of the product. There are other technologies but they may have other issues (cost, size, complexity etc). Also because flash requires erasure (can only program bits from 1 to 0) and that is relatively slow (as is programming) using it for buffers (as in your example) often doesn't work well. The bottom line is that flash is easy and (relatively) cheap for semiconductor manufacturers to include on-chip. RAM takes more silicon. Other technologies (e.g. EEPROM) are also ''expensive''. I have used uP's in the past that allowed the internal SRAM to be battery backed but ST doesn't provide that option. Perhaps you could describe what you're trying to accomplish and we can advise.

[daviddavid94]

Posted on May 17, 2011 at 14:01

1. Yes.

2. It's not ''you can only turn bits on''. It's ''you can only change 1's to 0's when you write''. 3. You *could* do this, IF your UART traffic was very very slow, and you had a RAM buffer between the two. So, no, not really. Flash is good for write-once, read-many situations. For example, a serial data logger is a good fit - you write data once, read it whenever, and erase it ONLY when you need to reclaim the log space. There's something you're not getting yet, and I'm not sure why (sorry). Maybe it's because you're thinking of what you would need to do, to treat Flash like RAM - so just don't do that. You only need to erase when you want to re-write. If you don't need to do that, you can write the entire Flash area before you do any erase operations.

[stforum2]

Posted on May 17, 2011 at 14:01

''Crossware, thanks for your reply.

What you are saying seems to be the opposite of what Stuart said, which was you can only change flash memory bits from 1 to zero.  I am getting more confused!'' I presume that you are happy now that it is not a contradiction but an extra contraint. ''Looks like I will have to use battery-backed RAM.'' If you have a battery, then maybe you have the option of putting the microcontroller into STOP mode instead of powering it down.  SRAM contents are preserved in STOP mode.

[sue]

Posted on May 17, 2011 at 14:01

Brian and Stuart,

Ahhhhh!!!  I've got it!  And, yes, I was treating it like ram.  However the programming manual does not say that you have to erase the whole page if you want to re-write a half-word it says you can clear it, then re-write it.  This is obviously wrong and misleading for newbies, and frustrating when it doesn't work. My project involves receiving messages and storing them somewhere where they won't be lost if the power goes off.  This involves writing over old messages when it runs out of room.  So it is obviously not going to work.  Looks like I will have to use battery-backed RAM. Many many thanks to all for your patience in explaining this to me.  Sorry to have been so thick! Cheers

[jpeacock23]

Posted on May 17, 2011 at 14:01

Internal flash isn't a good choice for storing transient data.  You might want to look at ferro-electric RAM (FRAM) as an alternative to flash.  It doesn't require erase cycles and has a fast completion time for writes, plus it's non-volatile when power is removed.  I use RAMTRON FRAMs connected to ST processors via the SPI serial bus.  There are parallel versions if you use the FSMC external bus on the STM32.

  Jack Peacock

[swhite2]

Posted on May 17, 2011 at 14:01

I used (parallel) FRAM's some years ago. They worked great but weren't cheap!

[raptorhal2]

Posted on May 17, 2011 at 14:01

Perhaps I can add some clarification that will salvage the design.

Flash memory is good for nonvolatile storage of messages, but you have to use it the right way. You can even use the STM32's flash memory, as long as you have the extra memory, and don't mind messages being erased during reprogramming. The first step is to erase the page (or pages) you need for the next message. Then write the message bytes in successive flash memory locations. Keep track of where the message ends in a battery powered backup register. You will need a battery anyway if you are using the RTC to time/date tag the messages. Continue erasing pages as needed for successive messages. When the end of memory is reached, cycle back to the start with the erase and write message operations. Used this way, the memory will probably last the life of the application, but do the math to be sure. I have a data capture application that writes 28 bytes at a time to flash memory, and it works well. Cheers, Hal