|
|
View previous topic :: View next topic |
Author |
Message |
Fabri
Joined: 22 Aug 2005 Posts: 275
|
EMC dirty some eeprom location |
Posted: Sat Jun 17, 2006 3:09 am |
|
|
Hi Everibody,
With burst noise the sistem dirty some eeprom location used only in reading when work right. The location are software calibration of a/d converter update manually.
My system work so:
1) After power up restore some eeprom location and restore writing some default values.
2) On work it read some location and write other.
In other equipment, based on assembler, after write eeprom i put in EEADR the address 0x00 doesn't used. I had not problem before.
Whats happen when a reset occured during a read or write eeprom ?
Is there anyway to know, at restart, the condiction of writing or reading eeprom ?
Thanks for help,
Regards, |
|
|
Ttelmah Guest
|
|
Posted: Sat Jun 17, 2006 3:49 am |
|
|
Look in the data sheet. The WRERR bit gets set, if a write is interrupted by an MCLR reset, or watchdog reset.
However you cannot detect is a power fail effectively occured.
One solution, would be to write an extra location, with a 'checksum' value. If this does not match the data stored, then something is wrong.
Best Wishes |
|
|
Fabri
Joined: 22 Aug 2005 Posts: 275
|
|
Posted: Mon Jun 19, 2006 12:41 am |
|
|
Hi Ttelmah,
Yes, I know. I also use checksum of eeprom but this doesn't solve my problem. I have over then 180 bytes of eeprom data programmed in first step by PC and I cannot restore all of them during normal work.
The data corrupted are unique, only 4 byte, and are the calibration of two amplifier.
I think to save them in more location than one, so I can verify and restore them in case of problem.
Is there any way to protect special location from write operation ?
In assembler I ever had any problem before, especially because the write routine was unique and I protected with an enable bit.
Have you got anything to suggest me ?
Thanks for help, |
|
|
ajt
Joined: 07 Sep 2003 Posts: 110
|
Off Topic - ttelmah please email me |
Posted: Mon Jun 19, 2006 2:04 pm |
|
|
ttelmah,
I have been trying to email you and apparently the emails are not getting through as I am not getting a response.
Please email me so we can regain communication.
I am making a similar post int he AstroHub group.
Al T (your PIC student)
PS Fabri: I am sorry to barge in on this thread like this but it is urgent for me to get in touch with ttelmah. _________________ Al Testani |
|
|
Ttelmah Guest
|
|
Posted: Mon Jun 19, 2006 2:37 pm |
|
|
Hi Al,
Emailled you off group.
Fabri,
What do you think is actually causing the problem?. Do you think it is just that the address is left 'set' at the last address used, or do you think the code is actually getting 'walked over' by an incorrect 'arrival' at the write code?.
I'd suggest something like this...
Have a 'protected' eeprom write routine, which does something like:
Code: |
//Psuedo code only...
#define PROT_AREA 0xF0
#define UNUSED 0
#define FLAGOK 0xAA
void my_eeprom_put(int8 address, int8 val, int8 flag) {
int8 temp;
if (address<PROT_AREA) write_eeprom(address,val);
else if (flag==FLAGOK) {
write_eeprom(address,val);
read_eeprom(UNUSED);
}
}
|
This then will only execute the actual write to the 'protected' area (in this case the top 16 bytes of the eeprom), if the 'flag' is set to the right value (FLAGOK).
Where you call this, 'trap' in front of the actual call to write this area, and verify the data is intact, before setting the flag value.
Note that this also sets the EEPROM address to '0' after writing any address in the protected area (using this as a 'unused' sacrificial area).
Best Wishes |
|
|
Fabri
Joined: 22 Aug 2005 Posts: 275
|
|
Posted: Tue Jun 20, 2006 12:35 am |
|
|
Hi Ttelmah,
I read every one second the calibration data. In the mode tested, write operation, occured only when some data changed or after restart during restore data from eeprom. I belive the continuos restart, by EMC burst, write the eeprom location were I read before.
Now I'll do more test to understand were's the problem and after I'll try to protect eeprom location by software.
This project is more sensible to EMC immunity I ever designed. Especially with keyboard, were I used KBDD.C for the first time, I have problem.
Thanks for help, |
|
|
Ttelmah Guest
|
|
Posted: Tue Jun 20, 2006 3:12 am |
|
|
I'd suggest then having the 'read' routine, with a final read of a dummy 'sacrificial' location at the end.
Good Luck. :-)
Best Wishes |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|