Hello good morning,
I have a serious problem, load my program and when it takes more than 5 days suddenly working perfectly certain data EEPROM is erased and it is as if put to 255 the values I had established in those sites EEPROM. I would like to know at who is due ,for I do not understand why, if necessary hang my code of the eeprom and code flash , since I'm going crazy.
best regards.
The data in the EEPROM inside the microcontroller will keep its data of course.
Can you tell us more ?
Which Arduino board are you using ?
Do you use the EEPROM of the microcontroller or an external EEPROM ?
Can you show us your sketch between code tags ?
It is not a good idea to update the EEPROM every second or faster. How many times do you write to the EEPROM ?
When the Arduino is turned off while it was writing the EEPROM, the data could be badly written. That is why often a checksum is used. If the checksum fails, a set of default settings should be used instead.
Hello,
The microcontroller used is the Arduino Mega 2560.
We use the internal EEPROM.
We do not store in EEPROM every second only in different parts of the code depending on what you do.
I attached a chart for you to see as our logic works, the only problem is that this in Spanish, if not understand what you says, can you tell me and translates to english.
Not let me attached files, the diagram of the operation I have a document.vsd.
Can you tell me how I attached the document?
best regards.
When you click the "REPLY" button there are additional options, as long as the file is not too big.
I would like to see the code of the sketch how the EEPROM is used. I don't know if I can open a *.vsd file.
The ATmega2560 requires 5.0V to run. If you for example run it from USB power and that is only 4.5V, the EEPROM might not be written very well.
Is the Arduino Mega 2560 turned off and on many times ? Perhaps it it turned off while writing. Or perhaps the EEPROM is written directly after power on, perhaps it is better to wait half a second or so.
Perhaps you were given this Arduino Mega 2560 board, and someone else has tested the EEPROM by writing a million times to it. I think that is unlikely.
At this moment I think the problem is in the sketch. It might also be ram overflow that causes the EEPROM functions to be activated, or buffer overflow, or a missing zero-terminator for a string, or bad copy of data, or something like that.
I do not think the microcontroller had used before.
It might have EEPROM saturated at write many times when you run out of battery,where it is installed the battery is not stable.
Of switch-on problem can not be because what I have fed 5 A 12VDC regulated.
Also I attached my program eeprom.
I've found where is attached, thanks.
best regards
EEPROM_16_01325.ino (32.1 KB)
not let me attach files .vsd
not let me attach files .vsd
The Arduino Mega 2560 board has EEPROM of 4k, that is index 0 up to 4095. That is okay.
Your sketch has many writes, that will take some time. If the Arduino is turned off while that is being written, it might go wrong.
Because it takes so long to write them, I would certainly add a checksum, to be sure that the data is still okay.
You could add a delay after Serial.begin().
Serial.begin(115200);
delay(500); // wait for power to be stable
EEPROM.write(0, 'b');
...
The avr library functions might be more useful.
http://nongnu.org/avr-libc/user-manual/group__avr__eeprom.html
For example the "eeprom_update_block()" to write a complete block at once.
How do you connect the regulated 12VDC 5A power supply ? To the power jack ? Did you check the voltage regulator ? If might get to hot, and it might reduce the 5V voltage.
If you put your finger on the voltage regulator and you can't keep it on, then it is too hot.
That is why a voltage regulator of 7.5V (or perhaps 9V) is recommended.
When the ICSP programming header is uses (the 2x3 pins next to the microcontroller), the 'avrdude' can be used to write the EEPROM.
dgelectron:
not let me attach files .vsd
You can try all you want, it will never let you attach such a file. Most of us don't have the software to open it. So save it as something we all CAN look at and is a permitted file type (cough .png/.jpg cough).
Quoted from right underneath the Attachment dialog box:
Allowed file types: doc, gif, jpg, mpg, pdf, png, txt, zip, c, h, cpp, ino, pde
Restrictions: maximum total size 1 MB, maximum individual size 1 MB
Hello,
I could finally spend part of the logic flash diagram to jpeg 
.
The program that you attach before, was the EEPROM.
The flash program as you can see is quite extensive.
thanks a lot.
best regards.
hello,
I may saturate the millis () function as I have written and recorded me wrong EEPROM and do me a flasheo of different parts of the EEPROM.
Deputy code associated with this function.
best regards.
millis.ino (13.4 KB)
That code is very hard to read. I'm sorry, but I don't know what to say about it.
Reading the EEPROM many times is no problem.
You show only a part of the code, that makes it even harder to say something about it.
I noticed there is an enless while-loop in it.
The code is sometimes very long and hard to check. With many things to check, it is easier to put that in a table and use a for-loop to test everything in the table.
You could add a function to dump the contents of the EEPROM to the serial monitor. At the moment something is not okay, then you can dump the EEPROM and check if it was the data in the EEPROM or the sketch that caused the wrong data.
To make the code good, I see no other option than to start all over again. Defining the EEPROM data structure in a better way; Creating a function for moving a blocks; more comments of what is going on; and so on.
Hello,
Thanks a lot peeter,
if you step .ino full file Might lose a few minutes and review it to see where it can be the fault. Is that I'm going crazy, I'm told that the millis function can cause problems.
best regards.
If millis() is used in a certain way, it will not cause a problem.
But I don't know if the variable 'currenttime' is a 'long' or 'unsigned long'.
If it is an 'unsigned long' then the use of millis() in that code is okay, it is a normal timeout and it will not cause a problem.
All time related variables should be unsigned long, keeps the math consistent.
Hello,
This is the part of initialization.
//VARIABLE MODULO TELEFONICA
GSM gsmAccess(true); // include a 'true' parameter for debug enabled
GSM_SMS sms;
char remoteNumber[20]; // Holds the emitting number
char txtMsg[89];
int nmi=0;
int nmy,nmz,nmx;
int ii=0;
char zz;
unsigned long currenttime = 0;
int result = -1;
best regards.
The 'currenttime' is unsigned long. That is good. So the use of millis() in the other code is okay. millis() is not the problem.