• AVR Freaks

Hot![SOLVED] Strange issue on eeprom write on 16f886

Author
schlabs
New Member
  • Total Posts : 22
  • Reward points : 0
  • Joined: 2012/02/09 09:39:07
  • Location: 0
  • Status: offline
2020/01/25 11:25:26 (permalink)
0

[SOLVED] Strange issue on eeprom write on 16f886

Dear All:
I am making my own save routine for this chip (have 256 bytes) I only need save less than 16 bytes but i need reliability about the stored data. To do this i perform 3 copies at write moment, so when i read it i will keep 2/3 good saved.
 
To test i force fail the copy 1 and the system works fine with 100% of copy 1 failed. But if force the fail of copy 2 i get inconsistency.
Is not 100%, I do step by step but i cant find where is the problem:
 
Save routine
void ee_save(unsigned char ee_address, unsigned char ee_data){ //Graba, verifica y reintenta hasta 5 veces
    unsigned char loop=0;
    unsigned char idx =0;
    unsigned char dbg =0;
    irq_disable_global;
    WREN=1;
    for(idx=0;idx<3;idx++){
        loop=0;
        do{
            irq_disable_global;
            dbg=ee_data;
            if(idx==1) dbg=ee_data+127; //force fail to copy 2
            eeprom_write(ee_address+EE_PAGE_SIZE*idx , dbg); // Writing value 0x9 to EEPROM address 0xE5 using the macro
            while(WR);
            irq_enable_global;
            //delay_ms(10);
            loop++;
        }while(ee_data!=eeprom_read(ee_address+EE_PAGE_SIZE*idx) && loop<5 );
    };
    
    WREN=0;
    irq_enable_global;
}

Load routine:
unsigned char ee_read(unsigned char ee_address){
    unsigned char value[3];
    unsigned char fail=0;
    do{
        value[0] = eeprom_read(ee_address);
        value[1] = eeprom_read(ee_address+EE_PAGE_SIZE );
        value[2] = eeprom_read(ee_address+EE_PAGE_SIZE+EE_PAGE_SIZE);
        fail++;
    }while( ( value[0]!=value[1] || value[0]!=value[2] ) && fail<5);
    if(value[0]==value[1] && value[0]==value[2]){
        return value[0];
    }
    if(value[1]==value[2]){
        value[0]=value[1];
    }
    ee_save(ee_address,value[0]);
    return value[0];
}

post edited by schlabs - 2020/01/27 15:12:06
#1

7 Replies Related Threads

    pcbbc
    Super Member
    • Total Posts : 1507
    • Reward points : 0
    • Joined: 2014/03/27 07:04:41
    • Location: 0
    • Status: offline
    Re: Strange issue on eeprom write on 16f886 2020/01/25 12:14:10 (permalink)
    +1 (1)
    I guess because this code...
        if(value[1]==value[2]){
            value[0]=value[1];
        }
        ee_save(ee_address,value[0]);
        return value[0];

    ...only handles the case when value[0] might be bad, and does nothing for the case when value[1] or value [2] might be bad?
     
    In the case were all three values are NOT equal, you need 3 checks to implement a majority vote:
    IF 0=1 THEN copy 0 to 2
    ELSE IF 0=2 THEN copy 0 to 1
    ELSE IF 1=2 THEN copy 1 to 0
    ELSE all three values different -> ERROR
     
    And I’m not entirely sure what the point is reading the EEPROM 5 times is. This is just going to slow your code down and is never going to get you the right answer if an incorrect value has been written.
     
    Also no idea why you‘be chosen this method over implementing a checksum or CRC. Much better way of checking for errors. Have a backup copy if the checksum fails by all means.
    #2
    schlabs
    New Member
    • Total Posts : 22
    • Reward points : 0
    • Joined: 2012/02/09 09:39:07
    • Location: 0
    • Status: offline
    Re: Strange issue on eeprom write on 16f886 2020/01/27 07:25:33 (permalink)
    0
    Dear,
    Thanks for the contribution, the problem still persist.
    There are some reason to try 5 times to get a clean read, and 3 copies. This device start to receive energy when the people do start to the car engine. So the 12 are under 8v and with a lot of noise into the power. I cant delay the start after that because i need open the fuel, i dont open the fuel, the car simply dont start. Because the cars are bi-fuel i need read what was the las fuel used to restore it.
    I am sure about i am doing some wrong, because the assembler version ( in older firmware) work fine.
    So is not eeprom, is not the three copy, is not the chip. Is the firmwaer, but i cant find where is the problem. Thanks for your aproach.
     
    #3
    pcbbc
    Super Member
    • Total Posts : 1507
    • Reward points : 0
    • Joined: 2014/03/27 07:04:41
    • Location: 0
    • Status: offline
    Re: Strange issue on eeprom write on 16f886 2020/01/27 07:56:13 (permalink)
    0
    schlabsThis device start to receive energy when the people do start to the car engine. So the 12 are under 8v and with a lot of noise into the power.

    Filter you power line and use the BOR feature.  There's no reason for the device not to be stable just because you are starting the engine - if you designed it right.  Are these reading 5 times shenanigans in the assembler version too?
     
    If you want more help publish all your code and configuration, not just where you think the problem is.  Oh, and some real world examples of exactly what your "inconsistencies" are wouldn't be a bad idea either.  Simply saying it doesn't work is useless unless you say how it doesn't work.
     
    Minimum necessary for quality help is usually:
    a) Full code exhibiting the problem and circuit diagram
    b) What tests you tried
    c) What you expected to see
    d) What you actually saw
    e) How you tested the above (simulator/real hardware, debugger, multimeter/scope/data-logger, etc)
    #4
    schlabs
    New Member
    • Total Posts : 22
    • Reward points : 0
    • Joined: 2012/02/09 09:39:07
    • Location: 0
    • Status: offline
    Re: Strange issue on eeprom write on 16f886 2020/01/27 11:02:07 (permalink)
    0
    Dear,

    Please note that the routine read UP TO 5 times only when the readed data is inconsistent. if the read is ok only read 1 time.

    I understand your requirement, but cant publish this data. Is a product ( the most selled of my work) with more than 5000pcs selled.

    When i start to sell the product the first 500 pcs was used 2 copys with CRC. After a few customer with problems with aleatory data reset, i switch to 3 copies byte to byte and rewrite the data when one byte is corrupt. After sell 4500 with zero claims i use this as default.

    Now with the migration to C the problem start again.

    I found the problem after read:

    https://www.microchip.com/forums/m938821.aspx

    Furthermore I m not using the macros, I use the pure source code, what Microchip recommended.

     

    So i switch to source manually:

    void ee_save(unsigned char ee_address, unsigned char ee_data){ //Graba, verifica y reintenta hasta 5 veces
        unsigned char loop=0;
        unsigned char idx =0;
        unsigned char dbg =0;
        irq_disable_global;
        for(idx=0;idx<3;idx++){
            loop=0;
            do{
                dbg=ee_data;
                if(idx==2) dbg=ee_data+127; //force failure to test
                EEADR = ee_address+EE_PAGE_SIZE*idx;
                EEDATA = dbg;
                EECON1bits.EEPGD = 0;
                EECON1bits.WREN = 1; // allows writing to Flash/EEPROM
                EECON2 = 0x55; // don't modify catalog data
                EECON2 = 0x0aa; // don't modify catalog data
                EECON1bits.WR = 1; // init write cycle
                while(WR);
                delay_ms(10); //see spec pag 246 param D122
                EECON1bits.WREN = 0; // allows writing to Flash/EEPROM
                loop++;
            }while(ee_data!=eeprom_read(ee_address+EE_PAGE_SIZE*idx) && loop<5 );
        };
        irq_enable_global;
    }



    Steps to found the problem.

    1) Saving data, and reading the EEPROM with a debugger before the firmware read it. I found that the problem was on write routine and not on read routine.
    2) when i was debugging the ee_save() routine the debugger jump to IRQ service when IRQ must be disabled. So seem like eeprom_write() macro perform an unwanted reenable of the irq.
    #5
    pcbbc
    Super Member
    • Total Posts : 1507
    • Reward points : 0
    • Joined: 2014/03/27 07:04:41
    • Location: 0
    • Status: offline
    Re: Strange issue on eeprom write on 16f886 2020/01/27 12:18:48 (permalink)
    -1 (1)
    schlabsPlease note that the routine read UP TO 5 times only when the readed data is inconsistent. if the read is ok only read 1 time.

    Yes, that's my point.  When it's inconsistent it's inconsistent.  Re-reading it isn't going to make it any more consistent.  So you just waste time re-reading it 5 times before trying to "fix" it.
     
    Let's even say one of the cells in the EEPROM has gone faulty.  Now you always have an error reading that cell.  So now your code slows down, finds an error, tries to fix it by writing the majority vote back to that cell, but gets the exact same error reading the next time (because the cell is faulty) and spends another pointless 5 times round the loop...
     
    About the only case where I can thing that re-reading a medium in the hope of getting a "correct" answer is physical media like a hard drive with ECC.  MC PIC16 EEPROM doesn't have ECC.

    I understand your requirement, but cant publish this data. Is a product ( the most selled of my work) with more than 5000pcs selled.

    Sold.
    Then you should post a minimum complete working example program that demonstrates the problem.  Not your product source.  Often in writing such a program you will find the problem yourself.
     
    Anyway glad you found the issue.
    #6
    schlabs
    New Member
    • Total Posts : 22
    • Reward points : 0
    • Joined: 2012/02/09 09:39:07
    • Location: 0
    • Status: offline
    Re: Strange issue on eeprom write on 16f886 2020/01/27 15:06:32 (permalink)
    0
    When it's inconsistent it's inconsistent.

    Dear That is a  wrong assumption. When you sell to cars 20,30,or more years old, when the people take 12v from wrong places, when you have big incoming noise, from ignition wires, the pic can fail to read EEprom module. I know with experience.
    Even you have brownout reset, but the customer only want start, so even with brownout i must open the fuel valve.
    Obviously in 13 years the hardware was improved to avoid this situations, but when you want reliability you must always think the worst scene.
     
    I apreciate your warning about the time, is true you has right, but is covered and there is not a problem in the application.
    Then you should post a minimum complete working example program that demonstrates the problem.

    Is right i do this in the past. Here the problem is focused in a single point, and the solution is clear that was a problem in the macro.
    Best Regards.
    Christian
    #7
    pcbbc
    Super Member
    • Total Posts : 1507
    • Reward points : 0
    • Joined: 2014/03/27 07:04:41
    • Location: 0
    • Status: offline
    Re: Strange issue on eeprom write on 16f886 2020/01/27 17:44:55 (permalink)
    0
    ...and this behaviour it just effects the EEPROM module for - reasons? Not the program FLASH? Or the RAM registers?  Maybe you read then 5 times as well - But whatever, if it works for you.
    #8
    Jump to:
    © 2020 APG vNext Commercial Version 4.5