Why isn't there any EEPROM in STM32F4 MCUs? [closed]
$begingroup$
Why isn't there any EEPROM in the STM32F4 series MCUs?
Mostly I have Microchip MCUs and they have EEPROM available in them, but I just found out that it is not available in the STM32F4 MCUs... And it looks like not in other families as 'F0, F1, F2 and F3 either.
Is there a way around to save parameter values in the absence of an EEPROM?
microcontroller stm32 stm32f4 eeprom non-volatile-memory
edited Feb 20 at 12:45
Peter Mortensen
1,60031422
asked Feb 19 at 22:14
scico111scico111
368111
$endgroup$
closed as primarily opinion-based by old_timer, Warren Hill, laptop2d, Edgar Brown, Dwayne Reid Feb 23 at 19:18
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
|
show 3 more comments
$begingroup$
Why isn't there any EEPROM in the STM32F4 series MCUs?
Mostly I have Microchip MCUs and they have EEPROM available in them, but I just found out that it is not available in the STM32F4 MCUs... And it looks like not in other families as 'F0, F1, F2 and F3 either.
Is there a way around to save parameter values in the absence of an EEPROM?
microcontroller stm32 stm32f4 eeprom non-volatile-memory
edited Feb 20 at 12:45
Peter Mortensen
1,60031422
asked Feb 19 at 22:14
scico111scico111
368111
$endgroup$
closed as primarily opinion-based by old_timer, Warren Hill, laptop2d, Edgar Brown, Dwayne Reid Feb 23 at 19:18
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
5
$begingroup$
"What could be a good reason?" questions do not fit within the Stack Exchange mission, and "such an important memory area" is very application-determined. Looks like no EEPROM in the STM32L4's either, but the L0's and L1's have it. Or you can add an extra chip if you have a need for which emulation won't work.
$endgroup$
– Chris Stratton
Feb 19 at 22:28
$begingroup$
Is it safe enough to use an emulated eeprom vs external eeprom chip?
$endgroup$
– scico111
Feb 19 at 22:29
7
$begingroup$
That would be entirely application dependent. Since you've said nothing about what you are trying to do for a question which would have to consider the specifics in extreme detail, no one can help you.
$endgroup$
– Chris Stratton
Feb 19 at 22:48
5
$begingroup$
The most likely explanation is that the application(s) for which the chip was initially developed did not require it. Remember, EVERY chip ever developed was designed for a specific large-volumne application, and only later added to the manufacturer's general catalog. The overhead of a new chip design is just too high to allow designing chips speculatively.
$endgroup$
– Dave Tweed♦
Feb 19 at 23:14
5
$begingroup$
"such an important memory area" - important to who? I'm currently working on a project using an STM32F4 device and I would have no use whatsoever for a little bit of internal EEPROM. The extra cost it would add to the device would certainly make a difference though.
$endgroup$
– brhans
Feb 19 at 23:14
|
show 3 more comments
$begingroup$
Why isn't there any EEPROM in the STM32F4 series MCUs?
Mostly I have Microchip MCUs and they have EEPROM available in them, but I just found out that it is not available in the STM32F4 MCUs... And it looks like not in other families as 'F0, F1, F2 and F3 either.
Is there a way around to save parameter values in the absence of an EEPROM?
microcontroller stm32 stm32f4 eeprom non-volatile-memory
edited Feb 20 at 12:45
Peter Mortensen
1,60031422
asked Feb 19 at 22:14
scico111scico111
368111
$endgroup$
Why isn't there any EEPROM in the STM32F4 series MCUs?
Mostly I have Microchip MCUs and they have EEPROM available in them, but I just found out that it is not available in the STM32F4 MCUs... And it looks like not in other families as 'F0, F1, F2 and F3 either.
Is there a way around to save parameter values in the absence of an EEPROM?
microcontroller stm32 stm32f4 eeprom non-volatile-memory
microcontroller stm32 stm32f4 eeprom non-volatile-memory
edited Feb 20 at 12:45
Peter Mortensen
1,60031422
asked Feb 19 at 22:14
scico111scico111
368111
edited Feb 20 at 12:45
Peter Mortensen
1,60031422
asked Feb 19 at 22:14
scico111scico111
368111
edited Feb 20 at 12:45
Peter Mortensen
1,60031422
edited Feb 20 at 12:45
Peter Mortensen
1,60031422
edited Feb 20 at 12:45
Peter Mortensen
1,60031422
1,60031422
asked Feb 19 at 22:14
scico111scico111
368111
asked Feb 19 at 22:14
scico111scico111
368111
asked Feb 19 at 22:14
scico111scico111
368111
368111
closed as primarily opinion-based by old_timer, Warren Hill, laptop2d, Edgar Brown, Dwayne Reid Feb 23 at 19:18
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as primarily opinion-based by old_timer, Warren Hill, laptop2d, Edgar Brown, Dwayne Reid Feb 23 at 19:18
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
5
$begingroup$
"What could be a good reason?" questions do not fit within the Stack Exchange mission, and "such an important memory area" is very application-determined. Looks like no EEPROM in the STM32L4's either, but the L0's and L1's have it. Or you can add an extra chip if you have a need for which emulation won't work.
$endgroup$
– Chris Stratton
Feb 19 at 22:28
$begingroup$
Is it safe enough to use an emulated eeprom vs external eeprom chip?
$endgroup$
– scico111
Feb 19 at 22:29
7
$begingroup$
That would be entirely application dependent. Since you've said nothing about what you are trying to do for a question which would have to consider the specifics in extreme detail, no one can help you.
$endgroup$
– Chris Stratton
Feb 19 at 22:48
5
$begingroup$
The most likely explanation is that the application(s) for which the chip was initially developed did not require it. Remember, EVERY chip ever developed was designed for a specific large-volumne application, and only later added to the manufacturer's general catalog. The overhead of a new chip design is just too high to allow designing chips speculatively.
$endgroup$
– Dave Tweed♦
Feb 19 at 23:14
5
$begingroup$
"such an important memory area" - important to who? I'm currently working on a project using an STM32F4 device and I would have no use whatsoever for a little bit of internal EEPROM. The extra cost it would add to the device would certainly make a difference though.
$endgroup$
– brhans
Feb 19 at 23:14
|
show 3 more comments
5
$begingroup$
"What could be a good reason?" questions do not fit within the Stack Exchange mission, and "such an important memory area" is very application-determined. Looks like no EEPROM in the STM32L4's either, but the L0's and L1's have it. Or you can add an extra chip if you have a need for which emulation won't work.
$endgroup$
– Chris Stratton
Feb 19 at 22:28
$begingroup$
Is it safe enough to use an emulated eeprom vs external eeprom chip?
$endgroup$
– scico111
Feb 19 at 22:29
7
$begingroup$
That would be entirely application dependent. Since you've said nothing about what you are trying to do for a question which would have to consider the specifics in extreme detail, no one can help you.
$endgroup$
– Chris Stratton
Feb 19 at 22:48
5
$begingroup$
The most likely explanation is that the application(s) for which the chip was initially developed did not require it. Remember, EVERY chip ever developed was designed for a specific large-volumne application, and only later added to the manufacturer's general catalog. The overhead of a new chip design is just too high to allow designing chips speculatively.
$endgroup$
– Dave Tweed♦
Feb 19 at 23:14
5
$begingroup$
"such an important memory area" - important to who? I'm currently working on a project using an STM32F4 device and I would have no use whatsoever for a little bit of internal EEPROM. The extra cost it would add to the device would certainly make a difference though.
$endgroup$
– brhans
Feb 19 at 23:14
5
5
$begingroup$
"What could be a good reason?" questions do not fit within the Stack Exchange mission, and "such an important memory area" is very application-determined. Looks like no EEPROM in the STM32L4's either, but the L0's and L1's have it. Or you can add an extra chip if you have a need for which emulation won't work.
$endgroup$
– Chris Stratton
Feb 19 at 22:28
$begingroup$
"What could be a good reason?" questions do not fit within the Stack Exchange mission, and "such an important memory area" is very application-determined. Looks like no EEPROM in the STM32L4's either, but the L0's and L1's have it. Or you can add an extra chip if you have a need for which emulation won't work.
$endgroup$
– Chris Stratton
Feb 19 at 22:28
$begingroup$
Is it safe enough to use an emulated eeprom vs external eeprom chip?
$endgroup$
– scico111
Feb 19 at 22:29
$begingroup$
Is it safe enough to use an emulated eeprom vs external eeprom chip?
$endgroup$
– scico111
Feb 19 at 22:29
7
7
$begingroup$
That would be entirely application dependent. Since you've said nothing about what you are trying to do for a question which would have to consider the specifics in extreme detail, no one can help you.
$endgroup$
– Chris Stratton
Feb 19 at 22:48
$begingroup$
That would be entirely application dependent. Since you've said nothing about what you are trying to do for a question which would have to consider the specifics in extreme detail, no one can help you.
$endgroup$
– Chris Stratton
Feb 19 at 22:48
5
5
$begingroup$
The most likely explanation is that the application(s) for which the chip was initially developed did not require it. Remember, EVERY chip ever developed was designed for a specific large-volumne application, and only later added to the manufacturer's general catalog. The overhead of a new chip design is just too high to allow designing chips speculatively.
$endgroup$
– Dave Tweed♦
Feb 19 at 23:14
$begingroup$
The most likely explanation is that the application(s) for which the chip was initially developed did not require it. Remember, EVERY chip ever developed was designed for a specific large-volumne application, and only later added to the manufacturer's general catalog. The overhead of a new chip design is just too high to allow designing chips speculatively.
$endgroup$
– Dave Tweed♦
Feb 19 at 23:14
5
5
$begingroup$
"such an important memory area" - important to who? I'm currently working on a project using an STM32F4 device and I would have no use whatsoever for a little bit of internal EEPROM. The extra cost it would add to the device would certainly make a difference though.
$endgroup$
– brhans
Feb 19 at 23:14
$begingroup$
"such an important memory area" - important to who? I'm currently working on a project using an STM32F4 device and I would have no use whatsoever for a little bit of internal EEPROM. The extra cost it would add to the device would certainly make a difference though.
$endgroup$
– brhans
Feb 19 at 23:14
|
show 3 more comments
3 Answers
3
active
oldest
votes
$begingroup$
All STM32 MCUs have self-programmable flash memory. If you need to store user settings, you can store them in an area of flash.
ST provides a library to perform EEPROM emulation on the STM32F4. (There are similar libraries for most of their other parts as well.) Even if you don't plan on using that library, their application note explaining how it works may be interesting to read.
answered Feb 19 at 22:20
duskwuffduskwuff
17.9k32753
$endgroup$
7
$begingroup$
This is correct but it is a poor substitute. The CPU cannot execute while the flash is being written or erased, and erasing takes a long time. There are tricks (multi flash banks, ram functions) but none are as tidy as just having an internal eeprom like AVR and PIC.
$endgroup$
– Jon
Feb 19 at 22:33
4
$begingroup$
@Jon of 577 Microchip PIC32 and Atmel 32 bit MCUs currently in production, only 63 have Data EEPROM. microchip.com/ParamChartSearch/…
$endgroup$
– Bruce Abbott
Feb 19 at 23:59
3
$begingroup$
@Jon, Not sure why you believe "The CPU cannot execute while the flash is being written or erased..." I have used this method on an F1 device. If the CPU had stopped during a write to Flash, I think I would have noticed
$endgroup$
– user28910
Feb 20 at 13:26
2
$begingroup$
@user28910 it’s not a matter of opinion. It is in the product documentation. Perhaps you were using a dual bank device (the larger sized ones). These can execute out of one bank while writing to another but this means your need to keep all the relevant code in the correct bank.
$endgroup$
– Jon
Feb 20 at 15:38
1
$begingroup$
@Bruce Abbott interesting point. I knew there were chips without eeprom but didn’t realise it was so extensive.
$endgroup$
– Jon
Feb 20 at 15:39
|
show 2 more comments
$begingroup$
EEPROM is very expensive in terms of cell size (leading to a larger die and hence higher cost). Manufacturers started trying to get rid of EEPROM as soon as the first Flash based controllers were released.
Especially when you consider the varying user requirements for the amount of EEPROM, it makes more sense to emulate in Flash, despite the limitations. As opposed to (for example) having a fixed 512 bytes of EEPROM, when one customer is only using 20 bytes, but paying for 512.
answered Feb 20 at 4:42
elchambroelchambro
1153
$endgroup$
1
$begingroup$
There is however data flash, which behaves quite similar to EEPROM, in terms of write cycles etc. But often requires many bytes to be erased, such as chunks of 8 bytes at a time or so. Whereas program flash will have huge erase sizes.
$endgroup$
– Lundin
Feb 20 at 16:09
add a comment |
$begingroup$
If having non-volatile memory which is programmable and erasable to the byte level is important (as opposed to Flash memory, which must have entire sectors/pages erased), have a look at the STM32L0 and STM32L1 series. They have true data EEPROM embedded on it.
answered Feb 20 at 15:46
JarhmanderJarhmander
35317
$endgroup$
add a comment |
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
All STM32 MCUs have self-programmable flash memory. If you need to store user settings, you can store them in an area of flash.
ST provides a library to perform EEPROM emulation on the STM32F4. (There are similar libraries for most of their other parts as well.) Even if you don't plan on using that library, their application note explaining how it works may be interesting to read.
answered Feb 19 at 22:20
duskwuffduskwuff
17.9k32753
$endgroup$
7
$begingroup$
This is correct but it is a poor substitute. The CPU cannot execute while the flash is being written or erased, and erasing takes a long time. There are tricks (multi flash banks, ram functions) but none are as tidy as just having an internal eeprom like AVR and PIC.
$endgroup$
– Jon
Feb 19 at 22:33
4
$begingroup$
@Jon of 577 Microchip PIC32 and Atmel 32 bit MCUs currently in production, only 63 have Data EEPROM. microchip.com/ParamChartSearch/…
$endgroup$
– Bruce Abbott
Feb 19 at 23:59
3
$begingroup$
@Jon, Not sure why you believe "The CPU cannot execute while the flash is being written or erased..." I have used this method on an F1 device. If the CPU had stopped during a write to Flash, I think I would have noticed
$endgroup$
– user28910
Feb 20 at 13:26
2
$begingroup$
@user28910 it’s not a matter of opinion. It is in the product documentation. Perhaps you were using a dual bank device (the larger sized ones). These can execute out of one bank while writing to another but this means your need to keep all the relevant code in the correct bank.
$endgroup$
– Jon
Feb 20 at 15:38
1
$begingroup$
@Bruce Abbott interesting point. I knew there were chips without eeprom but didn’t realise it was so extensive.
$endgroup$
– Jon
Feb 20 at 15:39
|
show 2 more comments
$begingroup$
All STM32 MCUs have self-programmable flash memory. If you need to store user settings, you can store them in an area of flash.
ST provides a library to perform EEPROM emulation on the STM32F4. (There are similar libraries for most of their other parts as well.) Even if you don't plan on using that library, their application note explaining how it works may be interesting to read.
answered Feb 19 at 22:20
duskwuffduskwuff
17.9k32753
$endgroup$
7
$begingroup$
This is correct but it is a poor substitute. The CPU cannot execute while the flash is being written or erased, and erasing takes a long time. There are tricks (multi flash banks, ram functions) but none are as tidy as just having an internal eeprom like AVR and PIC.
$endgroup$
– Jon
Feb 19 at 22:33
4
$begingroup$
@Jon of 577 Microchip PIC32 and Atmel 32 bit MCUs currently in production, only 63 have Data EEPROM. microchip.com/ParamChartSearch/…
$endgroup$
– Bruce Abbott
Feb 19 at 23:59
3
$begingroup$
@Jon, Not sure why you believe "The CPU cannot execute while the flash is being written or erased..." I have used this method on an F1 device. If the CPU had stopped during a write to Flash, I think I would have noticed
$endgroup$
– user28910
Feb 20 at 13:26
2
$begingroup$
@user28910 it’s not a matter of opinion. It is in the product documentation. Perhaps you were using a dual bank device (the larger sized ones). These can execute out of one bank while writing to another but this means your need to keep all the relevant code in the correct bank.
$endgroup$
– Jon
Feb 20 at 15:38
1
$begingroup$
@Bruce Abbott interesting point. I knew there were chips without eeprom but didn’t realise it was so extensive.
$endgroup$
– Jon
Feb 20 at 15:39
|
show 2 more comments
$begingroup$
All STM32 MCUs have self-programmable flash memory. If you need to store user settings, you can store them in an area of flash.
ST provides a library to perform EEPROM emulation on the STM32F4. (There are similar libraries for most of their other parts as well.) Even if you don't plan on using that library, their application note explaining how it works may be interesting to read.
answered Feb 19 at 22:20
duskwuffduskwuff
17.9k32753
$endgroup$
All STM32 MCUs have self-programmable flash memory. If you need to store user settings, you can store them in an area of flash.
ST provides a library to perform EEPROM emulation on the STM32F4. (There are similar libraries for most of their other parts as well.) Even if you don't plan on using that library, their application note explaining how it works may be interesting to read.
answered Feb 19 at 22:20
duskwuffduskwuff
17.9k32753
edited Feb 19 at 22:51
answered Feb 19 at 22:20
duskwuffduskwuff
17.9k32753
answered Feb 19 at 22:20
duskwuffduskwuff
17.9k32753
answered Feb 19 at 22:20
duskwuffduskwuff
17.9k32753
17.9k32753
7
$begingroup$
This is correct but it is a poor substitute. The CPU cannot execute while the flash is being written or erased, and erasing takes a long time. There are tricks (multi flash banks, ram functions) but none are as tidy as just having an internal eeprom like AVR and PIC.
$endgroup$
– Jon
Feb 19 at 22:33
4
$begingroup$
@Jon of 577 Microchip PIC32 and Atmel 32 bit MCUs currently in production, only 63 have Data EEPROM. microchip.com/ParamChartSearch/…
$endgroup$
– Bruce Abbott
Feb 19 at 23:59
3
$begingroup$
@Jon, Not sure why you believe "The CPU cannot execute while the flash is being written or erased..." I have used this method on an F1 device. If the CPU had stopped during a write to Flash, I think I would have noticed
$endgroup$
– user28910
Feb 20 at 13:26
2
$begingroup$
@user28910 it’s not a matter of opinion. It is in the product documentation. Perhaps you were using a dual bank device (the larger sized ones). These can execute out of one bank while writing to another but this means your need to keep all the relevant code in the correct bank.
$endgroup$
– Jon
Feb 20 at 15:38
1
$begingroup$
@Bruce Abbott interesting point. I knew there were chips without eeprom but didn’t realise it was so extensive.
$endgroup$
– Jon
Feb 20 at 15:39
|
show 2 more comments
7
$begingroup$
This is correct but it is a poor substitute. The CPU cannot execute while the flash is being written or erased, and erasing takes a long time. There are tricks (multi flash banks, ram functions) but none are as tidy as just having an internal eeprom like AVR and PIC.
$endgroup$
– Jon
Feb 19 at 22:33
4
$begingroup$
@Jon of 577 Microchip PIC32 and Atmel 32 bit MCUs currently in production, only 63 have Data EEPROM. microchip.com/ParamChartSearch/…
$endgroup$
– Bruce Abbott
Feb 19 at 23:59
3
$begingroup$
@Jon, Not sure why you believe "The CPU cannot execute while the flash is being written or erased..." I have used this method on an F1 device. If the CPU had stopped during a write to Flash, I think I would have noticed
$endgroup$
– user28910
Feb 20 at 13:26
2
$begingroup$
@user28910 it’s not a matter of opinion. It is in the product documentation. Perhaps you were using a dual bank device (the larger sized ones). These can execute out of one bank while writing to another but this means your need to keep all the relevant code in the correct bank.
$endgroup$
– Jon
Feb 20 at 15:38
1
$begingroup$
@Bruce Abbott interesting point. I knew there were chips without eeprom but didn’t realise it was so extensive.
$endgroup$
– Jon
Feb 20 at 15:39
7
7
$begingroup$
This is correct but it is a poor substitute. The CPU cannot execute while the flash is being written or erased, and erasing takes a long time. There are tricks (multi flash banks, ram functions) but none are as tidy as just having an internal eeprom like AVR and PIC.
$endgroup$
– Jon
Feb 19 at 22:33
$begingroup$
This is correct but it is a poor substitute. The CPU cannot execute while the flash is being written or erased, and erasing takes a long time. There are tricks (multi flash banks, ram functions) but none are as tidy as just having an internal eeprom like AVR and PIC.
$endgroup$
– Jon
Feb 19 at 22:33
4
4
$begingroup$
@Jon of 577 Microchip PIC32 and Atmel 32 bit MCUs currently in production, only 63 have Data EEPROM. microchip.com/ParamChartSearch/…
$endgroup$
– Bruce Abbott
Feb 19 at 23:59
$begingroup$
@Jon of 577 Microchip PIC32 and Atmel 32 bit MCUs currently in production, only 63 have Data EEPROM. microchip.com/ParamChartSearch/…
$endgroup$
– Bruce Abbott
Feb 19 at 23:59
3
3
$begingroup$
@Jon, Not sure why you believe "The CPU cannot execute while the flash is being written or erased..." I have used this method on an F1 device. If the CPU had stopped during a write to Flash, I think I would have noticed
$endgroup$
– user28910
Feb 20 at 13:26
$begingroup$
@Jon, Not sure why you believe "The CPU cannot execute while the flash is being written or erased..." I have used this method on an F1 device. If the CPU had stopped during a write to Flash, I think I would have noticed
$endgroup$
– user28910
Feb 20 at 13:26
2
2
$begingroup$
@user28910 it’s not a matter of opinion. It is in the product documentation. Perhaps you were using a dual bank device (the larger sized ones). These can execute out of one bank while writing to another but this means your need to keep all the relevant code in the correct bank.
$endgroup$
– Jon
Feb 20 at 15:38
$begingroup$
@user28910 it’s not a matter of opinion. It is in the product documentation. Perhaps you were using a dual bank device (the larger sized ones). These can execute out of one bank while writing to another but this means your need to keep all the relevant code in the correct bank.
$endgroup$
– Jon
Feb 20 at 15:38
1
1
$begingroup$
@Bruce Abbott interesting point. I knew there were chips without eeprom but didn’t realise it was so extensive.
$endgroup$
– Jon
Feb 20 at 15:39
$begingroup$
@Bruce Abbott interesting point. I knew there were chips without eeprom but didn’t realise it was so extensive.
$endgroup$
– Jon
Feb 20 at 15:39
|
show 2 more comments
$begingroup$
EEPROM is very expensive in terms of cell size (leading to a larger die and hence higher cost). Manufacturers started trying to get rid of EEPROM as soon as the first Flash based controllers were released.
Especially when you consider the varying user requirements for the amount of EEPROM, it makes more sense to emulate in Flash, despite the limitations. As opposed to (for example) having a fixed 512 bytes of EEPROM, when one customer is only using 20 bytes, but paying for 512.
answered Feb 20 at 4:42
elchambroelchambro
1153
$endgroup$
1
$begingroup$
There is however data flash, which behaves quite similar to EEPROM, in terms of write cycles etc. But often requires many bytes to be erased, such as chunks of 8 bytes at a time or so. Whereas program flash will have huge erase sizes.
$endgroup$
– Lundin
Feb 20 at 16:09
add a comment |
$begingroup$
EEPROM is very expensive in terms of cell size (leading to a larger die and hence higher cost). Manufacturers started trying to get rid of EEPROM as soon as the first Flash based controllers were released.
Especially when you consider the varying user requirements for the amount of EEPROM, it makes more sense to emulate in Flash, despite the limitations. As opposed to (for example) having a fixed 512 bytes of EEPROM, when one customer is only using 20 bytes, but paying for 512.
answered Feb 20 at 4:42
elchambroelchambro
1153
$endgroup$
1
$begingroup$
There is however data flash, which behaves quite similar to EEPROM, in terms of write cycles etc. But often requires many bytes to be erased, such as chunks of 8 bytes at a time or so. Whereas program flash will have huge erase sizes.
$endgroup$
– Lundin
Feb 20 at 16:09
add a comment |
$begingroup$
EEPROM is very expensive in terms of cell size (leading to a larger die and hence higher cost). Manufacturers started trying to get rid of EEPROM as soon as the first Flash based controllers were released.
Especially when you consider the varying user requirements for the amount of EEPROM, it makes more sense to emulate in Flash, despite the limitations. As opposed to (for example) having a fixed 512 bytes of EEPROM, when one customer is only using 20 bytes, but paying for 512.
answered Feb 20 at 4:42
elchambroelchambro
1153
$endgroup$
EEPROM is very expensive in terms of cell size (leading to a larger die and hence higher cost). Manufacturers started trying to get rid of EEPROM as soon as the first Flash based controllers were released.
Especially when you consider the varying user requirements for the amount of EEPROM, it makes more sense to emulate in Flash, despite the limitations. As opposed to (for example) having a fixed 512 bytes of EEPROM, when one customer is only using 20 bytes, but paying for 512.
answered Feb 20 at 4:42
elchambroelchambro
1153
answered Feb 20 at 4:42
elchambroelchambro
1153
answered Feb 20 at 4:42
elchambroelchambro
1153
answered Feb 20 at 4:42
elchambroelchambro
1153
1153
1
$begingroup$
There is however data flash, which behaves quite similar to EEPROM, in terms of write cycles etc. But often requires many bytes to be erased, such as chunks of 8 bytes at a time or so. Whereas program flash will have huge erase sizes.
$endgroup$
– Lundin
Feb 20 at 16:09
add a comment |
1
$begingroup$
There is however data flash, which behaves quite similar to EEPROM, in terms of write cycles etc. But often requires many bytes to be erased, such as chunks of 8 bytes at a time or so. Whereas program flash will have huge erase sizes.
$endgroup$
– Lundin
Feb 20 at 16:09
1
1
$begingroup$
There is however data flash, which behaves quite similar to EEPROM, in terms of write cycles etc. But often requires many bytes to be erased, such as chunks of 8 bytes at a time or so. Whereas program flash will have huge erase sizes.
$endgroup$
– Lundin
Feb 20 at 16:09
$begingroup$
There is however data flash, which behaves quite similar to EEPROM, in terms of write cycles etc. But often requires many bytes to be erased, such as chunks of 8 bytes at a time or so. Whereas program flash will have huge erase sizes.
$endgroup$
– Lundin
Feb 20 at 16:09
add a comment |
$begingroup$
If having non-volatile memory which is programmable and erasable to the byte level is important (as opposed to Flash memory, which must have entire sectors/pages erased), have a look at the STM32L0 and STM32L1 series. They have true data EEPROM embedded on it.
answered Feb 20 at 15:46
JarhmanderJarhmander
35317
$endgroup$
add a comment |
$begingroup$
If having non-volatile memory which is programmable and erasable to the byte level is important (as opposed to Flash memory, which must have entire sectors/pages erased), have a look at the STM32L0 and STM32L1 series. They have true data EEPROM embedded on it.
answered Feb 20 at 15:46
JarhmanderJarhmander
35317
$endgroup$
add a comment |
$begingroup$
If having non-volatile memory which is programmable and erasable to the byte level is important (as opposed to Flash memory, which must have entire sectors/pages erased), have a look at the STM32L0 and STM32L1 series. They have true data EEPROM embedded on it.
answered Feb 20 at 15:46
JarhmanderJarhmander
35317
$endgroup$
If having non-volatile memory which is programmable and erasable to the byte level is important (as opposed to Flash memory, which must have entire sectors/pages erased), have a look at the STM32L0 and STM32L1 series. They have true data EEPROM embedded on it.
answered Feb 20 at 15:46
JarhmanderJarhmander
35317
answered Feb 20 at 15:46
JarhmanderJarhmander
35317
answered Feb 20 at 15:46
JarhmanderJarhmander
35317
answered Feb 20 at 15:46
JarhmanderJarhmander
35317
35317
add a comment |
add a comment |
5
$begingroup$
"What could be a good reason?" questions do not fit within the Stack Exchange mission, and "such an important memory area" is very application-determined. Looks like no EEPROM in the STM32L4's either, but the L0's and L1's have it. Or you can add an extra chip if you have a need for which emulation won't work.
$endgroup$
– Chris Stratton
Feb 19 at 22:28
$begingroup$
Is it safe enough to use an emulated eeprom vs external eeprom chip?
$endgroup$
– scico111
Feb 19 at 22:29
7
$begingroup$
That would be entirely application dependent. Since you've said nothing about what you are trying to do for a question which would have to consider the specifics in extreme detail, no one can help you.
$endgroup$
– Chris Stratton
Feb 19 at 22:48
5
$begingroup$
The most likely explanation is that the application(s) for which the chip was initially developed did not require it. Remember, EVERY chip ever developed was designed for a specific large-volumne application, and only later added to the manufacturer's general catalog. The overhead of a new chip design is just too high to allow designing chips speculatively.
$endgroup$
– Dave Tweed♦
Feb 19 at 23:14
5
$begingroup$
"such an important memory area" - important to who? I'm currently working on a project using an STM32F4 device and I would have no use whatsoever for a little bit of internal EEPROM. The extra cost it would add to the device would certainly make a difference though.
$endgroup$
– brhans
Feb 19 at 23:14