> Il 16/08/2016 09:43, David Brown ha scritto:
>> On 15/08/16 16:02, pozz wrote:
>>> Il 15/08/2016 10:21, David Brown ha scritto:
>>>
>>>> Another solution that can be useful in some systems is to have either a
>>>> small battery, or a large capacitor to give you some extra
>>>> microcontroller time after power is disconnected. Then you can keep
>>>> your parameters in ram, and only save them to flash on power failure.
>>>> If you already have a battery for an RTC, then this might be a good
>>>> solution.
>>>
>>> What about watchdog that triggers automatically a reset?
>>
>> What about it? I don't see the connection.
>
> When the watchdog triggers, it automatically reset the microcontroller
> without saving the persistent parameters.
>
If your watchdog ever triggers, your system is broken. The watchdog is
there to limit how bad the breakage is, but it is not something that
should normally occur.
But as noted before, there are some types of parameters that are so
important that you would not want to risk losing them if your watchdog
/did/ trigger for some reason.
Reply by pozz●August 17, 20162016-08-17
Il 15/08/2016 16:37, raimond.dragomir@gmail.com ha scritto:
> luni, 15 august 2016, 16:50:45 UTC+3, pozz a scris:
>> Il 15/08/2016 05:51, raimond.dragomir@gmail.com ha scritto:
>>>> Is this exactly the goal to have a RWWEE additional Flash memory on this
>>>> microcontrollers?
>>>
>>> Yes.
>>>
>>> OTOH, I can't purchase C21 micros from anywhere. Can you?
>>
>> Yes, you can purchase a few pieces them from Digikey, but even Arrow
>> distributor (in Italy) gave me a quote, without problems for delivering.
>>
>> http://www.digikey.it/product-search/it/integrated-circuits-ics/embedded-microcontrollers/2556109?k=&pkeyword=&FV=ffeccb1e%2Cfff40027%2Cfff800cd&mnonly=0&newproducts=0&ColumnSort=0&page=1&stock=1&quantity=0&ptm=0&fid=0&pageSize=25
>
> Thank you,
>
> I didn't bother to check Digikey, I checked Mouser and Farnell with 0 results.
> OTOH, the prices are quite high, at least compared to Kinetis E family
> (also 5V). However, the prices for the C21 are for the big 256K parts.
> It would be interesting to find prices for the 32K and 64K chips.
I think now Microchip is pushing up the prices of Atmel products.
Reply by pozz●August 17, 20162016-08-17
Il 16/08/2016 09:43, David Brown ha scritto:
> On 15/08/16 16:02, pozz wrote:
>> Il 15/08/2016 10:21, David Brown ha scritto:
>>
>>> Another solution that can be useful in some systems is to have either a
>>> small battery, or a large capacitor to give you some extra
>>> microcontroller time after power is disconnected. Then you can keep
>>> your parameters in ram, and only save them to flash on power failure.
>>> If you already have a battery for an RTC, then this might be a good
>>> solution.
>>
>> What about watchdog that triggers automatically a reset?
>
> What about it? I don't see the connection.
When the watchdog triggers, it automatically reset the microcontroller
without saving the persistent parameters.
>> Usually the RTC battery supplies only the RTC and not the entire
>> microcontroller, so that battery can't be used to "give extra
>> microcontroller time".
>
> That all depends on how you lay out your board. With a few external
> components, you could use your RTC battery to power the microcontroller,
> but not the rest of the board, when external power fails. Once you have
> saved the necessary state in flash, you can either disconnect the
> battery from the microcontroller's main supply, or you could even simply
> put the microcontroller into very low power-down mode. It will use a
> little more battery power than the RTC alone (a switch here would have
> leakage, and even the very low power modes take /some/ current), but
> maybe it will be small enough - I would guess that a 2 cm coin cell
> could easily last a decade.
>
>>
>> Sincerely I will be worried to keep many persistent variables in RAM for
>> days or months without saving them to a non-volatile memory, with the
>> hope that they will be saved at the next power failure.
>>
>
> It all depends on the application, and the importance of the data. If
> the data is the result of a time-consuming calibration process, then you
> definitely don't want to risk it. But if it is the user's last choice
> of radio channel, then there is no problem.
>
> This was not a recommendation for your application - it's just another
> idea for a different way to handle such issues.
Yes, it is a possibility. Thank you for the hint.
Reply by David Brown●August 16, 20162016-08-16
On 15/08/16 16:02, pozz wrote:
> Il 15/08/2016 10:21, David Brown ha scritto:
>
>> Another solution that can be useful in some systems is to have either a
>> small battery, or a large capacitor to give you some extra
>> microcontroller time after power is disconnected. Then you can keep
>> your parameters in ram, and only save them to flash on power failure.
>> If you already have a battery for an RTC, then this might be a good
>> solution.
>
> What about watchdog that triggers automatically a reset?
What about it? I don't see the connection.
>
> Usually the RTC battery supplies only the RTC and not the entire
> microcontroller, so that battery can't be used to "give extra
> microcontroller time".
That all depends on how you lay out your board. With a few external
components, you could use your RTC battery to power the microcontroller,
but not the rest of the board, when external power fails. Once you have
saved the necessary state in flash, you can either disconnect the
battery from the microcontroller's main supply, or you could even simply
put the microcontroller into very low power-down mode. It will use a
little more battery power than the RTC alone (a switch here would have
leakage, and even the very low power modes take /some/ current), but
maybe it will be small enough - I would guess that a 2 cm coin cell
could easily last a decade.
>
> Sincerely I will be worried to keep many persistent variables in RAM for
> days or months without saving them to a non-volatile memory, with the
> hope that they will be saved at the next power failure.
>
It all depends on the application, and the importance of the data. If
the data is the result of a time-consuming calibration process, then you
definitely don't want to risk it. But if it is the user's last choice
of radio channel, then there is no problem.
This was not a recommendation for your application - it's just another
idea for a different way to handle such issues.
Reply by ●August 15, 20162016-08-15
luni, 15 august 2016, 16:50:45 UTC+3, pozz a scris:
Thank you,
I didn't bother to check Digikey, I checked Mouser and Farnell with 0 results.
OTOH, the prices are quite high, at least compared to Kinetis E family
(also 5V). However, the prices for the C21 are for the big 256K parts.
It would be interesting to find prices for the 32K and 64K chips.
Reply by pozz●August 15, 20162016-08-15
Il 15/08/2016 10:21, David Brown ha scritto:
> Another solution that can be useful in some systems is to have either a
> small battery, or a large capacitor to give you some extra
> microcontroller time after power is disconnected. Then you can keep
> your parameters in ram, and only save them to flash on power failure.
> If you already have a battery for an RTC, then this might be a good
> solution.
What about watchdog that triggers automatically a reset?
Usually the RTC battery supplies only the RTC and not the entire
microcontroller, so that battery can't be used to "give extra
microcontroller time".
Sincerely I will be worried to keep many persistent variables in RAM for
days or months without saving them to a non-volatile memory, with the
hope that they will be saved at the next power failure.
Reply by pozz●August 15, 20162016-08-15
Il 15/08/2016 05:51, raimond.dragomir@gmail.com ha scritto:
>> Is this exactly the goal to have a RWWEE additional Flash memory on this
>> microcontrollers?
>
> Yes.
>
> OTOH, I can't purchase C21 micros from anywhere. Can you?
> Linked to my previous post, here I'd like to discuss another topic
> related to persistent variables.
>
> Some years ago I used microcontrollers with internal EEPROM memory or I
> used external serial I2C EEPROM to save persistent variables. It seems
> to me the scenario has recently changed.
One thing hasn't changed - you can still use an external I�C eeprom if
you want. They are very small and cheap. Of course, on some projects
even this is too big or expensive.
>
> With new Cortex-M microcontrollers, internal EEPROM is typically absent,
> but the manufacturer explains in every details (with source code too)
> how to use internal Flash for data storage (EEPROM emulation).
> This saves some cost and PCB area (and I think it saves some cost to the
> manufacturer too... maybe the process to integrate a real EEPROM is high).
The issue here is probably that a good eeprom ideally needs different
process parameters (such as number of layers, size of features, silicon
doping, etc.) than the rest of the microcontroller. Often you can make
compromises, but you might find that to put an eeprom and a Cortex
microcontroller on the same die means sub-optimal setup of layers for
the rest of device (more power, more cost, lower speed, etc.).
>
> Atmel SAM D20 Cortex-M0+ has an internal Flash memory that can be
> splitted in two sections: one for application and one for EEPROM
> emulation. Application Note AT03265 explains how to use it [1].
>
Some micrcontrollers (such as Kinetis) even have hardware to help this
process, though it is the same basic principle.
> I think there's an obscure issue when using internal Flash memory for
> data storage. It is the page (Atmel names it row) erase time that could
> be some milliseconds (6ms for SAM D20).
> If the application needs 4 rows (4*256 byte=1kB) to save all persistent
> data, the sabing process will take about 24ms.
That is not an obscure issue - it can be quite a relevant issue. It
means that the timings for your flash-based data writes can vary
significantly.
>
> I don't know what do you think about it, but I try to split the actions
> in pieces that doesn't block, so the firmware can be more responsive to
> asyncronous events (pushing of buttons, commands from UARTs, ...)
> Blocking the firmware for 24ms seems to me a very *long* period.
>
> I don't think there is a solution. You can't decompose the saving
> process in a state-machine, because you can't continue executing the
> application from Flash memory during erasing process of some rows in the
> *same* Flash memory. Right? You are forced to wait for the erase (and
> write) process end.
That's sometimes true - but some flash systems are more sophisticated.
Some devices have flash systems constructed from multiple (or at least
two!) planes, so that you can have read operations on one plane while
doing an erase or a write on the other plane. And some have "erase
suspend" so that you can pause an erase operation and read from the same
flash plane (but a separate erase block), then continue the erase. Some
even have a "write suspend", though I don't think I've seen that on a
microcontroller flash. It should even be possible to automate such
suspension - in combination with an instruction cache, you could make
the flash erase and write operations almost unobtrusive (again, I don't
think I have seen that on any real microcontrollers - but I believe it
should be possible).
>
> Now I'm studying the datasheet of new Atmel SAM C21 Cortex-M0+
> microcontroller. It works with a 5V power supply and this is not common
> for this type of micros. Moreover I noticed the presence of an
> additional section of internal Flash memory that is named RWWEE
> (Read-While-Write EEPROM).
>
> "It is not possible to read the RWWEE area while the NVM main array
> is being written or erased, whereas the RWWEE area can be written
> or erased while the main array is being read."
>
> In this case, is it possible to continue executing of "normal"
> application that resides in the main memory during the saving process
> (erasing and writing of rows in the RWEE memory)?
It sounds like the device has two flash planes, and lets you read the
main program area while the data area is being erased or written. It
won't let you do the reverse - that's just to simplify the flash
controller, since it is unlikely that accessing data flash would be
useful while the program flash is inaccessible.
> If it is possible, I could decompose the saving process in a
> state-machine in such a way there isn't any blocking point. I can stay
> in the "ERASING" state until the erasing operation finished. Of course,
> the state-machine stay in "ERASING" state, but the main execution
> process isn't blocked.
>
> Is this exactly the goal to have a RWWEE additional Flash memory on this
> microcontrollers?
>
Yes, that's it exactly.
Another solution that can be useful in some systems is to have either a
small battery, or a large capacitor to give you some extra
microcontroller time after power is disconnected. Then you can keep
your parameters in ram, and only save them to flash on power failure.
If you already have a battery for an RTC, then this might be a good
solution.
Reply by ●August 15, 20162016-08-15
> Is this exactly the goal to have a RWWEE additional Flash memory on this
> microcontrollers?
Yes.
OTOH, I can't purchase C21 micros from anywhere. Can you?
Reply by pozz●August 14, 20162016-08-14
Linked to my previous post, here I'd like to discuss another topic
related to persistent variables.
Some years ago I used microcontrollers with internal EEPROM memory or I
used external serial I2C EEPROM to save persistent variables. It seems
to me the scenario has recently changed.
With new Cortex-M microcontrollers, internal EEPROM is typically absent,
but the manufacturer explains in every details (with source code too)
how to use internal Flash for data storage (EEPROM emulation).
This saves some cost and PCB area (and I think it saves some cost to the
manufacturer too... maybe the process to integrate a real EEPROM is high).
Atmel SAM D20 Cortex-M0+ has an internal Flash memory that can be
splitted in two sections: one for application and one for EEPROM
emulation. Application Note AT03265 explains how to use it [1].
I think there's an obscure issue when using internal Flash memory for
data storage. It is the page (Atmel names it row) erase time that could
be some milliseconds (6ms for SAM D20).
If the application needs 4 rows (4*256 byte=1kB) to save all persistent
data, the sabing process will take about 24ms.
I don't know what do you think about it, but I try to split the actions
in pieces that doesn't block, so the firmware can be more responsive to
asyncronous events (pushing of buttons, commands from UARTs, ...)
Blocking the firmware for 24ms seems to me a very *long* period.
I don't think there is a solution. You can't decompose the saving
process in a state-machine, because you can't continue executing the
application from Flash memory during erasing process of some rows in the
*same* Flash memory. Right? You are forced to wait for the erase (and
write) process end.
Now I'm studying the datasheet of new Atmel SAM C21 Cortex-M0+
microcontroller. It works with a 5V power supply and this is not common
for this type of micros. Moreover I noticed the presence of an
additional section of internal Flash memory that is named RWWEE
(Read-While-Write EEPROM).
"It is not possible to read the RWWEE area while the NVM main array
is being written or erased, whereas the RWWEE area can be written
or erased while the main array is being read."
In this case, is it possible to continue executing of "normal"
application that resides in the main memory during the saving process
(erasing and writing of rows in the RWEE memory)?
If it is possible, I could decompose the saving process in a
state-machine in such a way there isn't any blocking point. I can stay
in the "ERASING" state until the erasing operation finished. Of course,
the state-machine stay in "ERASING" state, but the main execution
process isn't blocked.
Is this exactly the goal to have a RWWEE additional Flash memory on this
microcontrollers?
[1]
http://www.atmel.com/Images/Atmel-42125-SAM-EEPROM-Emulator-Service-EEPROM_ApplicationNote_AT03265.pdf