Chip Malfunction PIC16F648A , date code 03142Y3

Discussion in 'Electronic Components' started by Grzegorz Zalot, Aug 18, 2003.

  1. We now know the cause of the problems with the PIC16F648A.
    The internal EEPROM writing procedure damages some bits in the port
    status register, most probably bit RP0 is affected. And seemingly this
    happens only if multiple interrupts occur during writing the EEPROM. However,
    this doesn't really matter, the chips are not usable anyway.
    Writing the EEPROM takes about 4 ms, too long to disable all interrupts
    during that time.

    regards
    --
    Grzegorz Zalot

    complex ltd.
    office tel/fax : +48 32 2505840
    mobil : +48 501 301515

    http://www.complex.org.pl/
    mailto:
    Grzegorz Zalot, Aug 18, 2003
    #1
    1. Advertising

  2. Hi Grzegorz,

    Grzegorz Zalot wrote:
    >
    > We now know the cause of the problems with the PIC16F648A.


    From where do you know that? Did Microchip say something?
    Can you post that too? It would be quite interesting....

    > The internal EEPROM writing procedure damages some bits in the port
    > status register, most probably bit RP0 is affected. And seemingly this
    > happens only if multiple interrupts occur during writing the EEPROM.


    With "multiple interrupt", you say, you re-enable interrupts after
    you *entered* the interrupt service routine?
    You are aware that there are only 8 stack levels (IIRC) and your
    ISR code must be able to handle re-entrance, aren't you?

    Have you tried to disable interrupt source one by one to identify
    the interrupt that makes a problem?

    Curious,
    Wolfgang
    Wolfgang Mahringer, Aug 18, 2003
    #2
    1. Advertising

  3. ........
    >>We now know the cause of the problems with the PIC16F648A.

    >
    >
    > From where do you know that? Did Microchip say something?


    Still no ....

    ....

    >>The internal EEPROM writing procedure damages some bits in the port
    >>status register, most probably bit RP0 is affected. And seemingly this
    >>happens only if multiple interrupts occur during writing the EEPROM.

    >
    >
    > With "multiple interrupt", you say, you re-enable interrupts after
    > you *entered* the interrupt service routine?


    NO !!!!!

    > You are aware that there are only 8 stack levels (IIRC) and your
    > ISR code must be able to handle re-entrance, aren't you?


    I know !!!

    >
    > Have you tried to disable interrupt source one by one to identify
    > the interrupt that makes a problem?


    Still no. I have not too much time .....


    --
    Grzegorz Zalot

    complex ltd.
    office tel/fax : +48 32 2505840
    mobil : +48 501 301515

    http://www.complex.org.pl/
    mailto:
    Grzegorz Zalot, Aug 18, 2003
    #3
  4. Hi Grzegorz,

    Grzegorz Zalot wrote:
    >
    > .......
    > >>We now know the cause of the problems with the PIC16F648A.

    > >
    > >
    > > From where do you know that? Did Microchip say something?

    >
    > Still no ....


    :-(((

    > >>The internal EEPROM writing procedure damages some bits in the port
    > >>status register, most probably bit RP0 is affected. And seemingly this
    > >>happens only if multiple interrupts occur during writing the EEPROM.

    > >
    > > With "multiple interrupt", you say, you re-enable interrupts after
    > > you *entered* the interrupt service routine?

    >
    > NO !!!!!


    Ah, ok. *phew*

    > > You are aware that there are only 8 stack levels (IIRC) and your
    > > ISR code must be able to handle re-entrance, aren't you?

    >
    > I know !!!
    >
    > >
    > > Have you tried to disable interrupt source one by one to identify
    > > the interrupt that makes a problem?

    >
    > Still no. I have not too much time .....


    I don't remember, have you tried more chips? May be that one is
    defective for some reason...

    Not really helpful,
    Wolfgang
    Wolfgang Mahringer, Aug 18, 2003
    #4
  5. Hallo Wolfgang Mahringer !:
    ........
    > I don't remember, have you tried more chips? May be that one is
    > defective for some reason...


    No, :-( .... Not only I have this problem ! This is like reproducible !

    >
    > Not really helpful,


    I too ....

    N-HTH
    --
    Grzegorz Zalot

    complex ltd.
    office tel/fax : +48 32 2505840
    mobil : +48 501 301515

    http://www.complex.org.pl/
    mailto:
    Grzegorz Zalot, Aug 18, 2003
    #5
  6. Grzegorz Zalot

    Tilmann Reh Guest

    Wolfgang Mahringer schrieb:

    > I don't remember, have you tried more chips? May be that one is
    > defective for some reason...


    Perhaps you missed the first thread about this problem, started
    on 18.07. by Grzegorz.
    He also used the 628 and 628A, both did perform perfectly without
    problems with exactly the same object code. The 648A however
    reproducibly showed these failures.

    --
    Dipl.-Ing. Tilmann Reh
    Autometer GmbH Siegen - Elektronik nach Maß.
    http://www.autometer.de

    ==================================================================
    In a world without walls and fences, who needs Windows and Gates ?
    (Sun Microsystems)
    Tilmann Reh, Aug 18, 2003
    #6
  7. Hi Tilman,

    Tilmann Reh schrieb:
    >
    > Wolfgang Mahringer schrieb:
    >
    > > I don't remember, have you tried more chips? May be that one is
    > > defective for some reason...

    >
    > Perhaps you missed the first thread about this problem, started
    > on 18.07. by Grzegorz.


    No, I haven't...

    > He also used the 628 and 628A, both did perform perfectly without
    > problems with exactly the same object code.


    Yes, I am aware of that...

    > The 648A however
    > reproducibly showed these failures.


    Thats why my question was: have you tried other (648's) chips?


    Wolfgang
    Wolfgang Mahringer, Aug 18, 2003
    #7
  8. Hallo Wolfgang Mahringer !:
    ........
    >>The 648A however
    >>reproducibly showed these failures.

    >
    >
    > Thats why my question was: have you tried other (648's) chips?


    All chips at my distributor have the same date code ..... I wait from two months
    onto a new chips .....

    --
    Grzegorz Zalot

    complex ltd.
    office tel/fax : +48 32 2505840
    mobil : +48 501 301515

    http://www.complex.org.pl/
    mailto:
    Grzegorz Zalot, Aug 18, 2003
    #8
  9. Hello Grzegorz,

    Well, you're getting your problem narrowed down.

    As I said in my reply to your original post, I will be very surprised if it
    turns out to be a silicon issue. I still strongly suspect your firmware. You
    should not have to disable interrupts for the entire cycle.


    Regards,
    Patrick Gomolchuk


    "Grzegorz Zalot" <> wrote in message
    news:...
    > We now know the cause of the problems with the PIC16F648A.
    > The internal EEPROM writing procedure damages some bits in the port
    > status register, most probably bit RP0 is affected. And seemingly this
    > happens only if multiple interrupts occur during writing the EEPROM.

    However,
    > this doesn't really matter, the chips are not usable anyway.
    > Writing the EEPROM takes about 4 ms, too long to disable all interrupts
    > during that time.
    >
    > regards
    > --
    > Grzegorz Zalot
    >
    > complex ltd.
    > office tel/fax : +48 32 2505840
    > mobil : +48 501 301515
    >
    > http://www.complex.org.pl/
    > mailto:
    >
    Patrick Gomolchuk, Aug 18, 2003
    #9
  10. "Patrick Gomolchuk" <> wrote in message
    news:XRb0b.21883$...
    > Hello Grzegorz,
    >
    > Well, you're getting your problem narrowed down.
    >
    > As I said in my reply to your original post, I will be very surprised if

    it
    > turns out to be a silicon issue. I still strongly suspect your firmware.

    You
    > should not have to disable interrupts for the entire cycle.


    I had a similar issue with PIC16F877 some time ago. I was using the PIC-C
    compiler from CCS. Their EEPROM-write routine did just that - turn off
    interrupts for the whole write period (actually, they sensed a "done" bit to
    terminate the process). Microchip's documentation says that you need to
    disable interrups only during the 55-AA trigger sequence, so I rewrote the
    routine to do just that, checking for "done" before starting a new write.
    Richard Henry, Aug 18, 2003
    #10
  11. Hallo Jan-Erik Söderholm !:
    ........
    > From the 16F627/628/648 data sheet (DS40044A) :
    >
    > "Required Sequence" :
    >
    > BCF INTCON, GIE ;Disable INTs.
    > MOVLW 55h ;
    > MOVWF EECON2 ;Write 55h
    > MOVLW AAh ;
    > MOVWF EECON2 ;Write AAh
    > BSF EECON1,WR ;Set WR bit
    > ;begin write
    >
    > And later on the same page (page 91) :
    >
    > "We strongly recommend that interrupts be disabled during this
    > code segment."


    Yes, during THIS SEQUENCE, and NOT during the EEPROM program cycle - the next
    4-8 ms !!!

    --
    Grzegorz Zalot

    complex ltd.
    office tel/fax : +48 32 2505840
    mobil : +48 501 301515

    http://www.complex.org.pl/
    mailto:
    Grzegorz Zalot, Aug 19, 2003
    #11
  12. Hello Patrick Gomolchuk !:
    > Hello Grzegorz,
    >
    > Well, you're getting your problem narrowed down.
    >
    > As I said in my reply to your original post, I will be very surprised if it
    > turns out to be a silicon issue.


    I am not surprise :-( !!!

    I still strongly suspect your firmware. You
    > should not have to disable interrupts for the entire cycle.


    This is NOT possible ! I have a special serial interface with ca. 0,1 ms cycle
    time. And the PIC16F873A works fine, but is too big and costs too much.


    --
    Grzegorz Zalot

    complex ltd.
    office tel/fax : +48 32 2505840
    mobil : +48 501 301515

    http://www.complex.org.pl/
    mailto:
    Grzegorz Zalot, Aug 19, 2003
    #12
  13. Have you checked the chip errata? This may be a known issue. You could also
    call microchip and work with them. If its silicon, they'll want to know
    about it.

    Regards

    "Grzegorz Zalot" <> wrote in message
    news:...
    > Hello Patrick Gomolchuk !:
    > > Hello Grzegorz,
    > >
    > > Well, you're getting your problem narrowed down.
    > >
    > > As I said in my reply to your original post, I will be very surprised if

    it
    > > turns out to be a silicon issue.

    >
    > I am not surprise :-( !!!
    >
    > I still strongly suspect your firmware. You
    > > should not have to disable interrupts for the entire cycle.

    >
    > This is NOT possible ! I have a special serial interface with ca. 0,1 ms

    cycle
    > time. And the PIC16F873A works fine, but is too big and costs too much.
    >
    >
    > --
    > Grzegorz Zalot
    >
    > complex ltd.
    > office tel/fax : +48 32 2505840
    > mobil : +48 501 301515
    >
    > http://www.complex.org.pl/
    > mailto:
    >
    Robert Monsen, Aug 19, 2003
    #13
  14. Grzegorz Zalot

    Ben Bradley Guest

    In
    comp.arch.embedded,sci.electronics.components,sci.electronics.design,
    "Patrick Gomolchuk" <> wrote:

    >
    >"Grzegorz Zalot" <> wrote in message
    >news:...
    >> Hello Patrick Gomolchuk !:
    >> > Hello Grzegorz,
    >> >
    >> > Well, you're getting your problem narrowed down.
    >> >
    >> > As I said in my reply to your original post, I will be very surprised if

    >it
    >> > turns out to be a silicon issue.

    >>
    >> I am not surprise :-( !!!
    >>
    >> I still strongly suspect your firmware. You
    >> > should not have to disable interrupts for the entire cycle.

    >>
    >> This is NOT possible ! I have a special serial interface with ca. 0,1 ms

    >cycle
    >> time. And the PIC16F873A works fine, but is too big and costs too much.
    >>
    >>
    >> --
    >> Grzegorz Zalot
    >>
    >> complex ltd.
    >> office tel/fax : +48 32 2505840
    >> mobil : +48 501 301515
    >>
    >> http://www.complex.org.pl/
    >> mailto:
    >>

    >
    >Gregorz,
    >
    >I am bitbanging 2 channels with a comparable frequency on the 648a (some
    >with identical date code, got them from Digikey), as well as using every
    >other peripheral on this device pretty much to their maximum potentials. All
    >interrupts are used extensively, including the eeprom write-end interrupt. I
    >experience no such problems on this busy device. I hand code everything and
    >I see no such critical error. Although this successful application is not
    >sufficient proof, it does lead me to maintain that it is highly likely that
    >your code is at fault. The fact that your code works on other flavors of the
    >device does not mean much. Marginal code works marginally. I'd keep digging
    >if it is economically viable to do so. You should be able to trap this error
    >somehow.


    I'm not familiar with the pic and haven't followed all these
    threads, but I've done my share of embedded code.
    It could be useful if the 'problem code' on the 'problem
    microcontroller' can be reduced to the minimum amount of code that
    will produce the problem. This will either result in code that no
    longer has the proprietary application and can be shown to the
    manufacturer or posted publically, clearly demonstrating the problem
    to all, or in creating this minimum-problem-producing code the coder
    will find a problem in the code, fix it and go on.

    HTH, HAND, etc.


    >Regards,
    >Patrick Gomolchuk
    >
    >
    Ben Bradley, Aug 20, 2003
    #14
  15. Hello Patrick Gomolchuk !:
    .........
    > I am bitbanging 2 channels with a comparable frequency on the 648a (some
    > with identical date code, got them from Digikey), as well as using every
    > other peripheral on this device pretty much to their maximum potentials. All
    > interrupts are used extensively, including the eeprom write-end interrupt. I
    > experience no such problems on this busy device. I hand code everything and
    > I see no such critical error. Although this successful application is not
    > sufficient proof, it does lead me to maintain that it is highly likely that
    > your code is at fault. The fact that your code works on other flavors of the
    > device does not mean much. Marginal code works marginally. I'd keep digging
    > if it is economically viable to do so. You should be able to trap this error
    > somehow.


    I have 3 circuits with this processor, and one works OK. But not only I have
    such problems - a different man in Poland has a similar problem. In this moment
    we look for exact causes.
    Software looks OK, because (fast) the same code works OK on 16F873.

    regards

    PS. You speak polish ???

    --
    Grzegorz Zalot

    complex ltd.
    office tel/fax : +48 32 2505840
    mobil : +48 501 301515

    http://www.complex.org.pl/
    mailto:
    Grzegorz Zalot, Aug 20, 2003
    #15
  16. Grzegorz Zalot

    Brian Logan Guest

    On Wed, 20 Aug 2003 07:20:58 +0200, Grzegorz Zalot <> wrote:

    >I have 3 circuits with this processor, and one works OK. But not only I have
    >such problems - a different man in Poland has a similar problem. In this moment
    >we look for exact causes.
    >Software looks OK, because (fast) the same code works OK on 16F873.


    I believe you could be right about a chip problem as I've recently learned of a
    problem of a similar nature in the PIC16F874A Rev. B0 errata sheet. The problem
    on those devices is that some instructions are being corrupted above 4MHz. In
    the errata sheet, Microchip advise customers to test a sample of at least 100
    units with their own code to see if the parts are suitable. The section from the
    errata sheet begins:

    "3. Module: Core
    Certain code sequence and placement may cause
    the corruption of a few bits in the instruction fetch
    when the part is used above 4 MHz. A corrupted
    instruction fetch will cause the part to execute an
    improper instruction and result in unpredictable
    outputs."


    Brian Logan
    Brian Logan, Aug 20, 2003
    #16
  17. Hello Brian Logan !:
    .......
    > I believe you could be right about a chip problem as I've recently learned of a
    > problem of a similar nature in the PIC16F874A Rev. B0 errata sheet. The problem
    > on those devices is that some instructions are being corrupted above 4MHz. In
    > the errata sheet, Microchip advise customers to test a sample of at least 100
    > units with their own code to see if the parts are suitable. The section from the
    > errata sheet begins:


    I know this problem (errata). One my circiut have a 4 MHz quartz, the second 12
    MHz. Then no this cause ....

    --
    Grzegorz Zalot

    complex ltd.
    office tel/fax : +48 32 2505840
    mobil : +48 501 301515

    http://www.complex.org.pl/
    mailto:
    Grzegorz Zalot, Aug 21, 2003
    #17
  18. Hello Patrick Gomolchuk !:
    ....
    > Gregorz,
    >
    > I am bitbanging 2 channels with a comparable frequency on the 648a (some
    > with identical date code, got them from Digikey), as well as using every
    > other peripheral on this device pretty much to their maximum potentials. All
    > interrupts are used extensively, including the eeprom write-end interrupt. I
    > experience no such problems on this busy device. I hand code everything and
    > I see no such critical error. Although this successful application is not
    > sufficient proof, it does lead me to maintain that it is highly likely that
    > your code is at fault. The fact that your code works on other flavors of the
    > device does not mean much. Marginal code works marginally. I'd keep digging
    > if it is economically viable to do so. You should be able to trap this error
    > somehow.


    What compiler do you use ? We have HiTech the newest version. And you ?
    Different firm in PL which has this problems use HiTech also.


    --
    Grzegorz Zalot

    complex ltd.
    office tel/fax : +48 32 2505840
    mobil : +48 501 301515

    http://www.complex.org.pl/
    mailto:
    Grzegorz Zalot, Aug 25, 2003
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mike
    Replies:
    4
    Views:
    431
    Franc Zabkar
    May 25, 2004
  2. Grzegorz Zalot

    Chip Malfunction PIC16F648A , date code 03142Y3

    Grzegorz Zalot, Aug 18, 2003, in forum: Electronic Design
    Replies:
    17
    Views:
    725
    Grzegorz Zalot
    Aug 25, 2003
  3. c a l a n d e

    Date code decipher help

    c a l a n d e, Sep 2, 2006, in forum: Electronic Components
    Replies:
    2
    Views:
    2,249
  4. Henry Kolesnik

    Mallory date code ?

    Henry Kolesnik, Sep 22, 2008, in forum: Electronic Repair
    Replies:
    11
    Views:
    1,614
    raypsi
    Sep 27, 2008
  5. Peter Leopold

    Yuasa production date code

    Peter Leopold, Aug 13, 2004, in forum: Security Alarms
    Replies:
    0
    Views:
    2,346
    Peter Leopold
    Aug 13, 2004
Loading...

Share This Page