hi
i decided to use my stm32f4 flash to save some parameters , this parameters need to be change , so i need to erase 1 sector(128kb) each time to erase just 1kb .(it's flash and i can not rewrite without erasing).
because it's real time, it's not possible to wait for erasing sectors.
so i decided to external EEPROM, but there is still some question i didn't know
1- can eeprom be erase ?? how erase implement?(should i erase whole page ?)
2- for writing new data should i erase it fist ? or it will be rewrite on existing data ?
thanks in advance
MA
EEPROM ,Worcking
Moderator: RoccoMarco
-
Giovanni
- Site Admin
- Posts: 14892
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: EEPROM ,Worcking
EEPROM requires no erase, you can write at byte level repeatedly, the erase operation is done transparently on most devices.
Giovanni
Giovanni
-
ulikoehler
- Posts: 71
- Joined: Tue Mar 17, 2015 2:32 am
- Been thanked: 3 times
Re: EEPROM ,Worcking
Note that some EEPROMs only support page-aligned writes, e.g. 24LC512 (http://ww1.microchip.com/downloads/en/DeviceDoc/21754M.pdf).
The page size depends on the exact EEPROM in use.
I recommend to use some of the open source ChibiOS drivers, e.g. this one:
https://github.com/barthess/24aa
I have also written a 24AA/24LC driver which is optimized for my particular purpose and currently only supports page aligned writes, not arbitrary writes. I will publish it as public domain, I just haven't gotten around to it yet. As far as I remember, I required a non-GPL code for EEPROMs for one of my projects.
Best regards
The page size depends on the exact EEPROM in use.
I recommend to use some of the open source ChibiOS drivers, e.g. this one:
https://github.com/barthess/24aa
I have also written a 24AA/24LC driver which is optimized for my particular purpose and currently only supports page aligned writes, not arbitrary writes. I will publish it as public domain, I just haven't gotten around to it yet. As far as I remember, I required a non-GPL code for EEPROMs for one of my projects.
Best regards
Re: EEPROM ,Worcking
Main issue with EEPROM is that you have to wait after each write - typically a few msec. You can usually write up to one complete page of data (16-32 bytes, IIRC) in one write period, and that data has to be aligned on a page boundary.
If hardware cost isn't a big problem have a look at FRAM - you can read and write that as fast as you like.
If hardware cost isn't a big problem have a look at FRAM - you can read and write that as fast as you like.
-
ulikoehler
- Posts: 71
- Joined: Tue Mar 17, 2015 2:32 am
- Been thanked: 3 times
Re: EEPROM ,Worcking
@steved
While you are right about the basic issue, FRAM is not that simple. EEPROM/Flash has limited writes, FRAM has limited writes/reads, although these limits are extremely high, see:
http://electronics.stackexchange.com/a/58304
http://e2e.ti.com/support/microcontrollers/msp430/f/166/t/132022
I would not go as far as generally recommending FRAM if only cost is not an issue. Absolute density might as well be an issue. You can get large EEPROMs and huge flashs but only small FRAMs in a single chip
Board space is sometimes more relevant than overall cost.
Additionally, these FRAMs:
http://www.fujitsu.com/downloads/MICRO/fsa/pdf/products/memory/fram/MB85RS64V-DS501-00015-4v0-E.pdf
have 1.5mA/10uA (active/standby) current. Very small EEPROMs like 24LC32 have 3mA/150uA/1uA (write/read/standby) peak current at 6.0V (i.e. in practice these would usually be lower). Especially for read/idle-heavy workloads EEPROMs might be significantly better (think of battery-powered applications) although you would have to check the individual models first.
Waiting a few msecs is often not an issue for the application at all. Especially if you use ChibiOS and DMA in a somewhat intelligent manner, writes are performed in the background (DMAish) and if you use an EEPROM with a large pages, e.g. 24LC1024 with 256 byte pages, this is very rarely an issue at all.
If you are concerned about R/W cycles, battery backupped SRAM would also be an option.
@deadlyboy:
I'd like to add that your point about EEPROM emulation is AFAIK wrong. It depends on how you implement it. I recommend using the "official" ST STM32 eeprom emulation, which is tested and does not have those problems. I have used it quite successfully in a multitude of projects.
Just read the appnote:
http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/DM00036065.pdf
It hides all the complex stuff from you and does not erase a full block when writing a single variable.
Best regards
While you are right about the basic issue, FRAM is not that simple. EEPROM/Flash has limited writes, FRAM has limited writes/reads, although these limits are extremely high, see:
http://electronics.stackexchange.com/a/58304
http://e2e.ti.com/support/microcontrollers/msp430/f/166/t/132022
I would not go as far as generally recommending FRAM if only cost is not an issue. Absolute density might as well be an issue. You can get large EEPROMs and huge flashs but only small FRAMs in a single chip
Board space is sometimes more relevant than overall cost.
Additionally, these FRAMs:
http://www.fujitsu.com/downloads/MICRO/fsa/pdf/products/memory/fram/MB85RS64V-DS501-00015-4v0-E.pdf
have 1.5mA/10uA (active/standby) current. Very small EEPROMs like 24LC32 have 3mA/150uA/1uA (write/read/standby) peak current at 6.0V (i.e. in practice these would usually be lower). Especially for read/idle-heavy workloads EEPROMs might be significantly better (think of battery-powered applications) although you would have to check the individual models first.
Waiting a few msecs is often not an issue for the application at all. Especially if you use ChibiOS and DMA in a somewhat intelligent manner, writes are performed in the background (DMAish) and if you use an EEPROM with a large pages, e.g. 24LC1024 with 256 byte pages, this is very rarely an issue at all.
If you are concerned about R/W cycles, battery backupped SRAM would also be an option.
@deadlyboy:
I'd like to add that your point about EEPROM emulation is AFAIK wrong. It depends on how you implement it. I recommend using the "official" ST STM32 eeprom emulation, which is tested and does not have those problems. I have used it quite successfully in a multitude of projects.
Just read the appnote:
http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/DM00036065.pdf
It hides all the complex stuff from you and does not erase a full block when writing a single variable.
Best regards
Re: EEPROM ,Working
thanks a lot for fast response
Giovanni- ulikoehler and steved
now i think i'm in better situation with your helps.
F-Ram s are good offer but Expensive . EEPROMs can be reWrite many times but they are somehow Slow.
about on-chip flash and EEPROM Emulator ,because my system is designed for Realtime purposes , i think it's not appropriate way to use on-chip flash as memory, because program should wait for erasing/writing/reading and micro is busy(are you agree ??) .
i also face with another kind of memory in some opensource project that is called DataFlash like :http://www.ecom.cz/open_sheet/sheet_name=D05014
how about this? is it works like on-chip flash in writing(erasing) or reading??
At present i have sd card on my board which is connected to my micro(stm32f4vgt6) as:
PC8 : SDIO_D0
PC9 : SDIO_D1
PC10: SDIO_D2
PC11: SDIO_D3
PC12: SDIO_CK
PD2: SDIO_CMD
here i have two questions : 1- what is advantages and disadvantages of using SD card ? if i use sd card it has more advantage for me because i can use it as data logger too. but what is the constraint about sd card ? because somewhere i heard about it's sensitivity about supplying power.
2: i want to handle it with SDC driver . is it connected to the correct pins ? now i want to use 8 GB sd card , is there any constraint for it's capacity ?
thanks in advance
MA
Giovanni- ulikoehler and steved
now i think i'm in better situation with your helps.
F-Ram s are good offer but Expensive . EEPROMs can be reWrite many times but they are somehow Slow.
about on-chip flash and EEPROM Emulator ,because my system is designed for Realtime purposes , i think it's not appropriate way to use on-chip flash as memory, because program should wait for erasing/writing/reading and micro is busy(are you agree ??) .
i also face with another kind of memory in some opensource project that is called DataFlash like :http://www.ecom.cz/open_sheet/sheet_name=D05014
how about this? is it works like on-chip flash in writing(erasing) or reading??
At present i have sd card on my board which is connected to my micro(stm32f4vgt6) as:
PC8 : SDIO_D0
PC9 : SDIO_D1
PC10: SDIO_D2
PC11: SDIO_D3
PC12: SDIO_CK
PD2: SDIO_CMD
here i have two questions : 1- what is advantages and disadvantages of using SD card ? if i use sd card it has more advantage for me because i can use it as data logger too. but what is the constraint about sd card ? because somewhere i heard about it's sensitivity about supplying power.
2: i want to handle it with SDC driver . is it connected to the correct pins ? now i want to use 8 GB sd card , is there any constraint for it's capacity ?
thanks in advance
MA
-
Giovanni
- Site Admin
- Posts: 14892
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: EEPROM ,Worcking
The CPU will be stopped for long times while operations are performed on flash, it is the same controller.
BTW, there are STM32 devices with incorporated EEPROM, L1 and L0 if I remember well.
Giovanni
BTW, there are STM32 devices with incorporated EEPROM, L1 and L0 if I remember well.
Giovanni
-
ulikoehler
- Posts: 71
- Joined: Tue Mar 17, 2015 2:32 am
- Been thanked: 3 times
Re: EEPROM ,Worcking
@deadlyboy
Yep, if you have realtime constraints, you usually can't accept flash erase times even if they are rare.
Do you need to store data in realtime in the EEPROM? How much storage do you require and how fast does it need to be?
AFAIK DataFlash ist just a normal flash with additional circuitry that adds some more features, i.e. it is easier to use.
Generally serially attached external flash, be it DataFlash or not, do not stall the CPU as Giovanni said. Only the on-chip flash does but I would only use it for things like configuration data.
Question 1:
SD cards are quite inexpensive and you can get 32 Gigabytes or memory for < 100$. However the cheaper ones are susceptible to power failure and might get defects. The wear levelling algorithms are quite intransparent to you and do vary from model to model (even individual cards may vary, especially cheap ones).
Even if the SD card is immune-ish to power failures, beware of FatFS. I have had quite significant problems with FatFS being absolutely unable to mount an SD card after sudden poweroff events. The linux driver can usually mount them without any issues. If in doubt, just write raw blocks to the card if possible.
You could also get eMMC which is like an SD card as a solderable IC. I have not used them yet, but I believe the interface (SDIO) is the same.
There are other NVRAM technologies besides FRAM but they are not any less expensive (if you can find a <30$ @1k 16GiB NVRAM, tell me!)
You can also buy a "raw" NAND flash and attach it to the FSMC controller (which consumes a lot of pins), but you have to implement wear levelling and other low-level stuff by yourself. FSMC is quite a complex unit, but you can get it to work with some fiddling around.
If you got 1k hours or so of time to spare, you could try to get the STM32 USB host library with MSC to work and attach an USB SSD/HDD or whatever. I am currently working on it and even with ChibiOS 3.0 it is horrific.
Generally, more complex memory is more likely to fail. SRAM is quite simple. Raw NAND MLC flash is simple too but has the block-erase / wear levelling problematic. EEPOM ist more complex (AFAIK it works like flash internally) but if it is fast enough and large enough it usually makes sense. SD cards are complex beasts and if you don't hate them you just haven't used them enough. Still, they are often the way of least resistance for many projects.
DRAM is quite complex to connect, too. If you've got a lot of spare time, you could get an FPGA, use some DDR3 IP core and attach it via SPI. However, you can get gigabytes of pretty fast memory for relatively few dollars. It is volatile, however
Question 2:
I suggest taking a look at the Olimex E407 schematic (microSD card): [url]olimex.com/Products/ARM/ST/STM32-E407/resources/STM32-E407_sch.pdf[/url]. If you got the same circuitry, it probably works. If not, triple-check everything. I don't know which controller you are using, so I can't say anything about the pins.
Note that SDIO has fairly high frequency. You should have *some* amount of length matching between the traces.
Everything up to 32 GiB should work (SDHC size limit). I don't know about SDXC cards.
Given that I have no information about your exact requirements, these are the only advices I can give you.
Best regards
Yep, if you have realtime constraints, you usually can't accept flash erase times even if they are rare.
Do you need to store data in realtime in the EEPROM? How much storage do you require and how fast does it need to be?
AFAIK DataFlash ist just a normal flash with additional circuitry that adds some more features, i.e. it is easier to use.
Generally serially attached external flash, be it DataFlash or not, do not stall the CPU as Giovanni said. Only the on-chip flash does but I would only use it for things like configuration data.
Question 1:
SD cards are quite inexpensive and you can get 32 Gigabytes or memory for < 100$. However the cheaper ones are susceptible to power failure and might get defects. The wear levelling algorithms are quite intransparent to you and do vary from model to model (even individual cards may vary, especially cheap ones).
Even if the SD card is immune-ish to power failures, beware of FatFS. I have had quite significant problems with FatFS being absolutely unable to mount an SD card after sudden poweroff events. The linux driver can usually mount them without any issues. If in doubt, just write raw blocks to the card if possible.
You could also get eMMC which is like an SD card as a solderable IC. I have not used them yet, but I believe the interface (SDIO) is the same.
There are other NVRAM technologies besides FRAM but they are not any less expensive (if you can find a <30$ @1k 16GiB NVRAM, tell me!)
You can also buy a "raw" NAND flash and attach it to the FSMC controller (which consumes a lot of pins), but you have to implement wear levelling and other low-level stuff by yourself. FSMC is quite a complex unit, but you can get it to work with some fiddling around.
If you got 1k hours or so of time to spare, you could try to get the STM32 USB host library with MSC to work and attach an USB SSD/HDD or whatever. I am currently working on it and even with ChibiOS 3.0 it is horrific.
Generally, more complex memory is more likely to fail. SRAM is quite simple. Raw NAND MLC flash is simple too but has the block-erase / wear levelling problematic. EEPOM ist more complex (AFAIK it works like flash internally) but if it is fast enough and large enough it usually makes sense. SD cards are complex beasts and if you don't hate them you just haven't used them enough. Still, they are often the way of least resistance for many projects.
DRAM is quite complex to connect, too. If you've got a lot of spare time, you could get an FPGA, use some DDR3 IP core and attach it via SPI. However, you can get gigabytes of pretty fast memory for relatively few dollars. It is volatile, however
Question 2:
I suggest taking a look at the Olimex E407 schematic (microSD card): [url]olimex.com/Products/ARM/ST/STM32-E407/resources/STM32-E407_sch.pdf[/url]. If you got the same circuitry, it probably works. If not, triple-check everything. I don't know which controller you are using, so I can't say anything about the pins.
Note that SDIO has fairly high frequency. You should have *some* amount of length matching between the traces.
Everything up to 32 GiB should work (SDHC size limit). I don't know about SDXC cards.
Given that I have no information about your exact requirements, these are the only advices I can give you.
Best regards
Re: EEPROM ,Worcking
ulikoehler has given you a good summary of the merits of the various types of storage.
It does depend very much on the amount of storage you need, and how often it might change.
If change is relatively infrequent, you can have a background task writing to EEPROM, in which case the delays are less of a problem; however you can't read from EEPROM while you're writing to it. You can reduce delays by only writing if data has really changed - at the expense of greater software complexity.
As you will realise, I personally like FRAM, because my storage needs are not great, and it can be driven just like RAM (apart from the finite limit on access cycles) - simpler software, less to go wrong. Yes, the chips cost more (especially since Cypress bought Ramtron), but if its paid work you save on software development time; not always an issue with personal projects.
Incidentally, EEPROMs have write cycle limitations, just as FRAM does.
Maybe you need battery backed static RAM - but that's not especially cheap, either!
It does depend very much on the amount of storage you need, and how often it might change.
If change is relatively infrequent, you can have a background task writing to EEPROM, in which case the delays are less of a problem; however you can't read from EEPROM while you're writing to it. You can reduce delays by only writing if data has really changed - at the expense of greater software complexity.
As you will realise, I personally like FRAM, because my storage needs are not great, and it can be driven just like RAM (apart from the finite limit on access cycles) - simpler software, less to go wrong. Yes, the chips cost more (especially since Cypress bought Ramtron), but if its paid work you save on software development time; not always an issue with personal projects.
Incidentally, EEPROMs have write cycle limitations, just as FRAM does.
Maybe you need battery backed static RAM - but that's not especially cheap, either!
Re: EEPROM ,Working
thanks again to Giovanni- ulikoehler and steved
you gave me a great knowledge about my grate concern of these days.
about my project , there is 3 kind of parameters that is need to be saved.
first : constant parameters- they are always constant and permanent during program execution( about 1KB)
second : the parameters that user give to program during execution which is about 50 kB
third : the log data.(about 2 megabytes and if it would be great if i can increase it to 5MB).
so there is trade-off between the Cost , Convenience(about codes implementation and the point that i need to Observe for the pcb designing ) and the space of memory that i need .
i decided to use SD cards because , there was example of SDC driver in chibios and i assume that it will be easy to implement (just attach that codes to my code) and cheap while has large space.
but as ulikoehler said : if you don't hate them you just haven't used them enough , now i really fear SD cards .
you also mention to it's high frequency and length matching of SD cards traces , can you reference me an article to explain it the rules and points for my pcb ??
so with these information,from your perspective , what's the best kind of memory for me ?
can you introduce me products ??
thanks in advance
MA
you gave me a great knowledge about my grate concern of these days.
about my project , there is 3 kind of parameters that is need to be saved.
first : constant parameters- they are always constant and permanent during program execution( about 1KB)
second : the parameters that user give to program during execution which is about 50 kB
third : the log data.(about 2 megabytes and if it would be great if i can increase it to 5MB).
so there is trade-off between the Cost , Convenience(about codes implementation and the point that i need to Observe for the pcb designing ) and the space of memory that i need .
i decided to use SD cards because , there was example of SDC driver in chibios and i assume that it will be easy to implement (just attach that codes to my code) and cheap while has large space.
but as ulikoehler said : if you don't hate them you just haven't used them enough , now i really fear SD cards .
you also mention to it's high frequency and length matching of SD cards traces , can you reference me an article to explain it the rules and points for my pcb ??
so with these information,from your perspective , what's the best kind of memory for me ?
can you introduce me products ??
thanks in advance
MA