This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ADuC 841 possible EEPROM issue

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.

    Erik

  • 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

    Erik