Chip Malfunction PIC16F648A , date code 03142Y3

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.
 Click to see the full signature
Reply to
Grzegorz Zalot
Loading thread data ...

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

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

Reply to
Wolfgang Mahringer

.......

Still no ....

...

NO !!!!!

I know !!!

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

--
Grzegorz Zalot

complex ltd.
 Click to see the full signature
Reply to
Grzegorz Zalot

:-(((

Ah, ok. *phew*

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

Not really helpful, Wolfgang

Reply to
Wolfgang Mahringer

Hallo Wolfgang Mahringer !: .......

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

I too ....

N-HTH

--
Grzegorz Zalot

complex ltd.
 Click to see the full signature
Reply to
Grzegorz Zalot

Wolfgang Mahringer schrieb:

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ß.
 Click to see the full signature
Reply to
Tilmann Reh

Hi Tilman,

Tilmann Reh schrieb:

No, I haven't...

Yes, I am aware of that...

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

Wolfgang

Reply to
Wolfgang Mahringer

Hallo Wolfgang Mahringer !: .......

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

--
Grzegorz Zalot

complex ltd.
 Click to see the full signature
Reply to
Grzegorz Zalot

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

However,

Reply to
Patrick Gomolchuk

it

You

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.

Reply to
Richard Henry

Hallo Jan-Erik Söderholm !: .......

Yes, during THIS SEQUENCE, and NOT during the EEPROM program cycle - the next

4-8 ms !!!
--
Grzegorz Zalot

complex ltd.
 Click to see the full signature
Reply to
Grzegorz Zalot

Hello Patrick Gomolchuk !:

I am not surprise :-( !!!

I still strongly suspect your firmware. You

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.
 Click to see the full signature
Reply to
Grzegorz Zalot

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

it

cycle

Reply to
Robert Monsen

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.

Reply to
Ben Bradley

Hello Patrick Gomolchuk !: ........

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.
 Click to see the full signature
Reply to
Grzegorz Zalot

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

Reply to
Brian Logan

Hello Brian Logan !: ......

the

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.
 Click to see the full signature
Reply to
Grzegorz Zalot

Hello Patrick Gomolchuk !: ...

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.
 Click to see the full signature
Reply to
Grzegorz Zalot

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.