Chip Malfunction PIC16F648A , date code 03142Y3

[Grzegorz Zalot]

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:complex@alpha.pl

 

[Wolfgang Mahringer]

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

 

[Grzegorz Zalot]

........

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:complex@alpha.pl

 

[Wolfgang Mahringer]

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

 

[Grzegorz Zalot]

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:complex@alpha.pl

 

[Tilmann Reh]

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)

 

[Wolfgang Mahringer]

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

 

[Grzegorz Zalot]

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:complex@alpha.pl

 

[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 still strongly suspect your firmware. You
should not have to disable interrupts for the entire cycle.


Regards,
Patrick Gomolchuk


"Grzegorz Zalot" <complex@alpha.pl> wrote in message
news:3F409FEB.4060101@alpha.pl...

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:complex@alpha.pl

 

[Richard Henry]

"Patrick Gomolchuk" <pomolchuk@isaidnospamtycothermal.com> wrote in message
news:XRb0b.21883$L6.257055@news2.telusplanet.net...

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.

 

[Grzegorz Zalot]

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:complex@alpha.pl

 

[Grzegorz Zalot]

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:complex@alpha.pl

 

[Robert Monsen]

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" <complex@alpha.pl> wrote in message
news:3F41AFB0.9010704@alpha.pl...

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:complex@alpha.pl

 

[Ben Bradley]

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

"Grzegorz Zalot" <complex@alpha.pl> wrote in message
news:3F41AFB0.9010704@alpha.pl...
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:complex@alpha.pl


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

 

[Grzegorz Zalot]

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:complex@alpha.pl

 

[Brian Logan]

On Wed, 20 Aug 2003 07:20:58 +0200, Grzegorz Zalot <complex@alpha.pl> 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

 

[Grzegorz Zalot]

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:complex@alpha.pl

 

[Grzegorz Zalot]

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:complex@alpha.pl