This is my first post. I am very much a newbie but an EE/ASIC/FPGA designer by education, career and hobby. I've used Arduinos only for a short time and my high level programming skills are very much limited.
I am running into an interesting problem which I can work around but I haven't seen it posted here so I thought I would ask.
I am only trying to write to the EEPROM in the Arduino Nano Every in the simplest way I know. I've doubled checked variable types and some other things. In the following very simple code:
#include <EEPROM.h>
int address;
byte value;
int a;
void setup() {
Serial.begin(9600);
while (!Serial) {
; // wait for serial port to connect. Needed for native USB port only
}
// EEPROM.write(0x00FF, 0x10);
EEPROM.write(0x0000, 0x11);
EEPROM.write(0x0001, 0x12);
EEPROM.write(0x0002, 0x13);
EEPROM.write(0x0003, 0x14);
Serial.print("\t");
}
void loop() {
for (a=0; a<4; a++) {
value = EEPROM.read(a);
Serial.print(a);
Serial.print("\t");
Serial.print(value, DEC);
Serial.println();
}
delay(500);
}
I run it and I can successfully see the 4 bytes that I wrote echoed to the screen - no problems whatsoever. So naturally, I comment out the EEPROM.write's and expect to see the same data echoed to the screen in a new compile. But what I find is that the first byte written in the previous compile is always written as a 0xFF (255). As long as the EEPROM.write's are in the current compile things work as expected. Very weird.
After spending way too much time trying to debug this, I finally noticed that if I write to a location that I don't intend on using first, everything works as expected. I can comment out all writes and I can successfully read back the intended data that I wrote. I verified that the first write was still 0xFFs but it doesn't matter for my application.
So, I decided to try the same test on an Arduino Uno. This device works as expected. No dummy write to another location is necessary. I can power it down and then read back what I wrote without rewriting it.
Am I doing something wrong? (Or worst yet, has this already been reported and I didn't find it and I am wasting everyone's time?).
I moved your topic to an appropriate forum category @trolley_car.
In the future, please take some time to pick the forum category that best suits the subject of your topic. There is an "About the _____ category" topic at the top of each category that explains its purpose.
Hi - runaway_pancake. Thank you for your reply. Can you please elaborate? I have tested what I wrote about. I can power down the Nano Every and I can read back the data I wrote (less the first byte that was written) without rewriting it.
I got the exact same result. The first write (to 0x0001) seems to have been written as an 0xFF, instead of a 0x11. Now what is weird is that as long as I keep the writes in the code, everything works fine, including the first write.
As soon as I take away the writes, the first byte read returns 0xFF but the other bytes are read properly.
The back of Uno box (official) notes its 1K of EEPROM.
The back of my NanoEvery box (official) does not call out any EEPROM, but the Docs does note it (256B).
Since it's 256B, its addresses are byte-size (0x00 - 0xff), not int-size -- if that makes a difference (??).
There is something about the serial port opening which is messing with the eeprom writes. If you add a small delay after opening the connection to the monitor, the eeprom behaves as expected with the first cell written returning the value that was placed there when the code is executed without any writes and only the reading.
while (!Serial) {
; // wait for serial port to connect. Needed for native USB port only
}
delay(500);
I've tried the code with MegaCoreX and get the same result. Adding the 500ms delay fixes it.
I have a project that uses EEPROM on a 4809, I occasionally noticed a problem with the data from EEPROM but never really investigated the cause. I've not noticed it recently but @trolley_car you have given me something to think about, thank you.
For those not familiar with MegaCoreX have a look here:
There is actually 256B + 64B of EEPROM, with the additional 64B having the ability to be written by the UPDI programmer when the lock bits are active. This 64B page of EEPROM does not appear to be accessible when using Arduino megaAVR, but is accessible using MegaCoreX.
I'm using the Arduino Nano Every on a project and had the same results you had.
I found that using EEPROM.update instead of EEPROM.write appears to work correctly.
Are you saying that .update() does not require the delay after opening the serial port.
If so, can you post some simple code you have used to demonstrate this. Are you clear that the cell does not have the value before you first use the .update() or .write().
I actually moved the EEPROM.write() before opening the serial port to eliminate the serial port as a contributing factor. However, a delay was still required before the first EEPROM.write(). Two ms was the minimum delay to make the first write successful. I tried using EEPROM.update just for kicks and tested it without a delay before the first statement. Here's a code sample. First run it with the EEPROM.update section. then comment-out all the updates and rerun to verify that the first value was saved correctly.
#include <EEPROM.h>
#include <LibPrintf.h>
void setup() {
//* update doesn't have the first write problem
EEPROM.update(0, 1);
EEPROM.update(1, 2);
EEPROM.update(2, 3);
EEPROM.update(3, 4);
//*/
Serial.begin(115200);
for (int i=0; i<10; i++) {
printf("EEPROM address %u = %u\r\n",i, EEPROM.read(i));
}
}
void loop() {
delay(100);
}
Indeed you have found some thing new and there does seem to be a difference between .write() and .update(). Time to study the eeprom library closely.
You have also found that it is not the Serial.begin() and serial monitor which is causing the issue. A delay() initially after setup() will also work to see correct eeprom writes and reads when .write() is used.
Here is the original test sketch with the eeprom moved before the serial.
#include <EEPROM.h>
int address;
byte value;
int a;
void setup() {
//delay(50) fixes the FF issue on first .write(), not required for.update()
//EEPROM.write(0x0000, 0x22);
//EEPROM.write(0x0001, 0x44);
//EEPROM.write(0x0002, 0x66);
//EEPROM.write(0x0003, 0x88);
//EEPROM.update(0x0000, 0x11);
//EEPROM.update(0x0001, 0x33);
//EEPROM.update(0x0002, 0x55);
//EEPROM.update(0x0003, 0x77);
Serial.begin(9600);
while (!Serial) {
; // wait for serial port to connect. Needed for native USB port only
}
}
void loop() {
for (a = 0; a < 4; a++) {
value = EEPROM.read(a);
Serial.print(a);
Serial.print("\t");
Serial.print(value, HEX);
Serial.println();
}
delay(1000);
}
It might be useful to try this test with the array accessor, EEPROM[] to see if it has the same issue. The Arduino documentation doesn't say if the array accessor uses .write() or .update(). I don't have a Nano Every at home, but will try it at work next week.
