Double EEPROM memory entry Atmege 328p

Hello everyone,

I use PlatformIO and an Atmege 328P. In the code I have a simple save operation that should write an area in memory with the value one. This works so far, but the value is entered twice. I suspect that I am doing something wrong with the addressing, do you have an approach for me?

After I have transferred the code, I read the EEPROM with an STK500 via Microchip Studio, which shows the entries twice. Noticeably shifted by 512 addresses?

#include <Arduino.h>
#include <EEPROM.h>

#define startAdr_uplight 0
#define endAdr_uplight   20

uint16_t adress = 0;


void setup() {

}

void loop() {

  adress = startAdr_uplight;
  while(adress < endAdr_uplight ){
    EEPROM.write(adress, 1);
    adress++;
  }
}

here is the result
:1000000001010101010101010101010101010101E0
:1000100001010101FFFFFFFFFFFFFFFFFFFFFFFFE8
:10002000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0
:10003000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD0
:10004000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC0
:10005000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB0
:10006000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA0
:10007000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF90
:10008000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF80
:10009000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF70
:1000A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF60
:1000B000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF50
:1000C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF40
:1000D000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF30
:1000E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF20
:1000F000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF10
:10010000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
:10011000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEF
:10012000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDF
:10013000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCF
:10014000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBF
:10015000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFAF
:10016000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF9F
:10017000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF8F
:10018000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF7F
:10019000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF6F
:1001A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5F
:1001B000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF4F
:1001C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3F
:1001D000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF2F
:1001E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1F
:1001F000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0F
:1002000001010101010101010101010101010101DE
:1002100001010101FFFFFFFFFFFFFFFFFFFFFFFFE6
:10022000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDE
:10023000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCE
:10024000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBE
:10025000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFAE
:10026000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF9E
:10027000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF8E
:10028000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF7E
:10029000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF6E
:1002A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5E
:1002B000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF4E
:1002C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3E
:1002D000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF2E
:1002E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1E
:1002F000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0E
:10030000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD
:10031000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFED
:10032000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDD
:10033000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCD
:10034000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBD
:10035000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFAD
:10036000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF9D
:10037000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF8D
:10038000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF7D
:10039000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF6D
:1003A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D
:1003B000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF4D
:1003C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3D
:1003D000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF2D
:1003E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1D
:1003F000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0D
:00000001FF

would be great if someone could help me, thanks

I haven't an answer to your issue, but take the note...
The code below has a great chance to ruin an EEPROM in very short time, because you write the EEPROM unconditionally in endless loop.

how did you print this out?

+1 on ruining your EEPROM super fast... don't keep this code running.. put the code in the setup at least so that it only runs once

#include <EEPROM.h>
void setup() {
  for (int i = 0; i < 20; i++) EEPROM.write(i, 1);
}

void loop() {}

Thanks for the hint, you are right. Fortunately, I only created the code briefly to show you the problem separately from my program, where it is only run once initially. For the result I only had voltage on the chip for a short time.


I have saved the result of "Read" and opened it with the editor

if your run this

#include <EEPROM.h>
void setup() {
  Serial.begin(115200);
  for (int i = 0; i < 20; i++) EEPROM.write(i, i);
  for (int i = 0; i < 20; i++) Serial.println(EEPROM.read(i), BIN);
}

void loop() {}

what do you see in the Serial monitor set at 115200 bauds ?

I am confused to read the above line when my understanding is this that a byte-type (8-bit) data is written into an int-type (address) memory location. In the above line, i (second argument of write() method) is an int-type (16-bit) data item.

Your confusion is not sufficient reason to hijack this thread, @GolamMostafa. Read the documentation for Arduino's EEPROM.write fn, which clearly states a single byte will be written. Even in their example, they may pass an int, but a byte gets written:
https://docs.arduino.cc/learn/built-in-libraries/eeprom/

I am silently out from this thread!

1 Like

I disagree and don't see that as an hijacking. I think it's a fair question given it's not obvious what happens as the doc states

value: the value to write, from 0 to 255 (byte)

and I'm not using a byte but an int type. Good opportunity to discuss promotions.

I think we had a recent discussion where I explained about implicit promotions (the float being truncated into an integer). Here it's the same thing, the write() function expects a byte so C++ will apply an int to byte implicit conversion which basically takes the least significant byte of the variable as is (bit for bit) and that's what makes it to the write() function. as my index does not go over 255 nor goes negative, it's the exact index value that gets written in EEPROM

1 Like

I guess when I see

write()

Description

Write a byte to the EEPROM.

Syntax

COPY

1EEPROM.write(address, value)

Parameters

address: the location to write to, starting from 0 (int)

value: the value to write, from 0 to 255 (byte)

I tend to take it at face value; I don't hand it an int and expect an int to be written. It's going to write a byte. Whether you give it an int, or a double, it's going to write a byte.

Want to write something other than a byte, explore EEPROM.put(). But beware, there are still limitations.

Meh. More off-topic wander. The OP is asking us why two different location blocks are being written, and we've wandered off on a discussion of whether a byte is really a byte. I'm out.

[digression on]

don't you think it's a fair question for newbie/non C++ experts to ask by which magical trick an int a float or a double would become a byte to be written? because indeed I'm not (and there example is not either) following their own specification.

[digression off]

I first had to establish an interface with a seriall to usb so that I could do the test. I got the following result:

Start
1
10
11
100
101
110
111
1000
1001
1010
1011
1100
1101
1110
1111
10000
10001
10010
10011

it was recorded with the Serial Monitor from PlatformIO

so it seems that's writing into the 20 first EEPROM bytes works fine (assuming you missed a 0 in the first line)

Correct, that was a copying error

I changed it a bit and saved a number and then had the entire memory output, with the result that everything is displayed correctly, all entries except for the first area are blank

Start
1
255
255
.
.
.
.
255
255

but reading the EEPROM via Microchip Studio/STK500 still shows a duplicate entry. It seems to be due to a setting of the tool ?

:1000000001FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE
.
.
.
.
:1002000001FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC
.
.
.
.

I don’t use that - sorry can’t say

Why don't you simply read it back with a small sketch? That can tell you if it is the tool or if is indeed wrong.

that's what I did now and it all seems to work correctly, it's just that I didn't use a ready-made board with all possible interfaces already built in, but a custom design. That's why I didn't have an I2C to USB or other interface to test my code, hence the way I read out the memory, which I could easily read out via the ISP interface and stumbled across the error. Now I have returned the values via the I2C and a serial to USB converter, so it is probably due to the Microchip Studio. I have not yet been able to find any options for setting the memory size, for example.

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