EEPROM.put(): is it best practice to call System.disableUpdates() before?

Firmware
,
1

Hi,

I have a firmware that does this:

        System.disableReset();
        System.disableUpdates();
        EEPROM.put(address, data);
        System.enableReset();
        System.enableUpdates();

I wonder if I can refactor this code into:

        EEPROM.put(address, data);

Or are there any conditions that I would want to play it safe and keep the code?

I read the docs here and this AN35 too but could not find any suggestion in this regard.

Any tips are welcome!
Thanks a bunch,
Gustavo.

EDIT: I originally mentioned this:
This code is executed in the constructor of a global class and that causes an SOS Hard fault, as described here.
but I removed it to get to the point of the question and not mislead readers. Thanks!

2

I’m pretty sure that most libraries should do hardware initialization outside of the constructor.

Could you refactor the EEPROM writing into a begin() method that you would then call in setup()?

1 Like
3

Hey Nathan, yes we agree. It's one of the options on the table. Thank you.

Now, what I would like to find out here is if there is a requirement for safeguarding the EEPROM.put() with disableUpdates(), no matter where it gets called, even later in the program.

I will update my initial post to reflect this.
Thanks!

1 Like
4

You definitely do not want to disable updates that frequently. It sends an event to the cloud each time you turn it on and off. It’s an internal event, so it does not count as a data operation, but it will use cellular data.

I presume your intention of disabling reset is to prevent resetting while updating the EEPROM. However it’s actually a more general problem because the EEPROM on Gen 3 is just a file on the file system, so if it were possible to corrupt the file system that way, it could happen also when updating the DCT or using other file system commands. The design of LittleFS is supposed to prevent the filesystem from being damaged regardless of when the power is turned off, but I’d have to check later to see if there’s anything else in Device OS, sort of like a Linux sync before reset.

2 Likes
5

Thank you! Looking forward to your findings of this.
Gustavo.

6

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.