We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I observed a strange thing when working with ADuC 841 EEPROM - when I access it more intensively, the uP resets itself. The code I am running is quite complex, so I don't want to blame EEPROM right away, but has anybody else experienced similar behavior? Little more about my code, "access it more intensively" meaning about 50 calls of following function in one batch
unsigned char EE_Save_Float_Data(float fdata, unsigned int page) reentrant { FLOAT ee_data; WORD address; ee_data.value = fdata; address.value = page; //normal mode ECON = EE_NORMAL_MODE; EADRH = address.BYTES.high; EADRL = address.BYTES.low; ECON = EE_ERASE_PAGE; EDATA1 = ee_data.BYTES.DATA1; EDATA2 = ee_data.BYTES.DATA2; EDATA3 = ee_data.BYTES.DATA3; EDATA4 = ee_data.BYTES.DATA4; ECON = EE_WRITE; ECON = EE_VERIFY; return (ECON == 0); }
From my further experiments, adding delay after each memory operation seems to be helping, same as disabling interrupts (EA = 0) in the whole EEPROM handling function. None of these are however described as necessary in 841 datasheet.
Thank you for any opinion/advice Petr
ADuC 841 when I access it more intensively, the uP resets itself. does it have a watchdog? when you do not feed it regulatily, it bites
Erik
I am using it, but with period of 2s, all the EEPROM work above takes about 200ms, so I don't think this is such case.
when I access it more intensively from both ISR and main? do you stroke the puppy when the above is called again and again?
spme such EEPROMs - i do not know your chip - comes to a screeching halt when it copies it's internal RAM to it's flash.
Many EEPROMS are actually flash with shadow RAM and function by first access: read flash page to RAM workings uC to RAM internal time expired: erase flash page and write shadow RAM to flash page different flash page to be accessed : erase previous flash page and write shadow ram to previous flash page, then read new flash page to shadow RAM.
I am accessing EEPROM only from main, after a "trigger" received by serial port. I double checked the calling tree and I am pretty sure that watchdog gets his share before EEPROM write is triggered second time. Also I noticed that the reset occurs in the middle of WriteEEPROM function, and it happens in about 1% of WriteEEPROM calls. I also think I can leave the idea of slow EEPROM. The simplified main function is following
void main(void) { if ( trigger ) { WriteEEPROM(); } .....some meaningful work..... FeedWD(); }
and as I wrote in my first comment, problem disappears when I a)disable all interrupts when accessing EEPROM or b)add a delay ( simple blocking "while(i) i--;" ) after each EEPROM operation
If it was by slow EEPROM and therefore WD overrun, then a) wouldn't help, as WD is not affected by EA, and b) wouldn't help either, it would make things even worse as more time would be spent in WriteEEPROM(). But thanks for the idea anyway.
Petr
feed the puppy ikn te EEPROM loop