# When trying to read empty EEPROM hangs the device

**URL:** <https://community.particle.io/t/when-trying-to-read-empty-eeprom-hangs-the-device/49194>\
**Category:** Firmware\
**Tags:** electron\
**Created:** [April 19, 2019, 7:38am UTC](https://community.particle.io/t/when-trying-to-read-empty-eeprom-hangs-the-device/49194 "2019-04-19T07:38:53Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![kyu](https://avatars.discourse-cdn.com/v4/letter/k/b3f665/32.png) [@kyu](https://community.particle.io/u/kyu)\
**Post date:** [April 19, 2019, 7:38am UTC](https://community.particle.io/t/when-trying-to-read-empty-eeprom-hangs-the-device/49194/1 "2019-04-19T07:38:53Z")

</div>

As described in [https://docs.particle.io/reference/device-os/firmware/electron/#get-](https://docs.particle.io/reference/device-os/firmware/electron/#get-)  
I tried to check if EEPROM is empty using both EEPROM.get and EEPROM.read()

```auto
uint16_t val;
  EEPROM.get(add, val);
  if(val==0xFFFF) return "";

```

```auto
uint8_t value = EEPROM.read(int address);
if(value == 0xFF) return "";

```

If there is something written in EEPROM, both works ok but if I tried to access empty space, the device will stop working.  
What is the best way to check if EEPROM at certain address is empty or not.  
Kyu

---

<div class="post-metadata">

**Author:** ![tommy\_boy](https://avatars.discourse-cdn.com/v4/letter/t/d9b06d/32.png) [@tommy\_boy](https://community.particle.io/u/tommy_boy)\
**Post date:** [April 19, 2019, 11:22am UTC](https://community.particle.io/t/when-trying-to-read-empty-eeprom-hangs-the-device/49194/2 "2019-04-19T11:22:58Z")

</div>

I’ve experienced this behavior on many photons. My workaround is to write 0b00000000 values to all the byte addresses during commissioning of a new device. Not elegant, but it worked.

---

<div class="post-metadata">

**Author:** ![ScruffR](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/scruffr/32/6952_2.png) [@ScruffR](https://community.particle.io/u/ScruffR)\
**Post date:** [April 19, 2019, 12:31pm UTC](https://community.particle.io/t/when-trying-to-read-empty-eeprom-hangs-the-device/49194/3 "2019-04-19T12:31:37Z")

</div>

Just out of interest, why would you need to explicitly test for _empty_ EEPROM?  
The common way would be to read your expected data and just treat the special case when you _don’t_ find valid data.  
This would catch the _empty_ case **as well as** corrupted/overwritten data.

To do that reliably it’s good to have both - a magic number and a checksum - in your dataset.

However, hanging should not appear and maybe @rickkas7 could give this a check.  
Meanwhile could you also clarify _which_ device OS version you are running on your Electron?

---

<div class="post-metadata">

**Author:** ![kyu](https://avatars.discourse-cdn.com/v4/letter/k/b3f665/32.png) [@kyu](https://community.particle.io/u/kyu)\
**Post date:** [April 19, 2019, 3:50pm UTC](https://community.particle.io/t/when-trying-to-read-empty-eeprom-hangs-the-device/49194/4 "2019-04-19T15:50:43Z")

</div>

Hello @ScruffR, thanks for advice.  
I was running device os 1.0.1  
My intention was to write certain data if that area is empty.  
Maybe I should have write all eeprom area as ‘\0’ before accessing any address, however even if my solution is not safe, the device should not reset by itself as you mentioned.

Since there is no such thing as ‘try’ and ‘catch exception’, the device atleast should return something.

---

<div class="post-metadata">

**Author:** ![ScruffR](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/scruffr/32/6952_2.png) [@ScruffR](https://community.particle.io/u/ScruffR)\
**Post date:** [April 19, 2019, 4:18pm UTC](https://community.particle.io/t/when-trying-to-read-empty-eeprom-hangs-the-device/49194/5 "2019-04-19T16:18:04Z")

</div>

"Resetting" the cells to 0x00 is not the best approach as it inevitably means that the next write will have to relocate the EEPROM window as there are no bits that can be written to anymore.  
For flash memory bits can only be cleared (set to 0) indidvidually but to set them (1) you'll need a page erase - this is what causes flash wear.

~~I haven't tried it, but~~ what happens when you "initialise" the EEPROM window by writing all 0xFF ("confirm" the value that should be there all along) and then try the code you have above?

With this code my Electron doesn't block

```cpp
uint32_t addr = 0;
uint16_t data;

void setup() {
  Serial.begin();
  Serial.println("init");
  data = 0xFFFF;
  EEPROM.put(addr, data); // optional (remove/comment when run once)
}

void loop() {
  Serial.print("loop ");
  EEPROM.get(addr, data);
  addr += sizeof(data);
  Serial.printlnf("%06d: 0x%04x", addr, data);
  if (addr >= EEPROM.length()) {
      addr = 0;
      delay(1000);
  }
  else
    delay(10);
}

```

See here

> [@EEPROM read/write block size](https://community.particle.io/t/eeprom-read-write-block-size/49186/2):
>
> There is no block size to speak of in EEPROM, and it varies dramatically between Gen 2 and Gen 3. In Gen 2 (Photon, P1, Electron, E Series), there are two sectors of flash memory. These are sector erase NOR flash and individual bytes cannot be erased. There’s a wear-leveling algorithm and essentially the data is a running log of the changes over time. When the sector log is full, the data is swapped to the other sector and the old one erased. In Gen 3 (Argon, Boron, Xenon), the flash emulation…