Critical problems with PIC 16F648A

During a new development we experienced critical problems with PIC 16F648A controllers (package DIP18, date code 03142Y3). We observed two malfunctions:

1. When writing data to port A, the port configuration in the TRISA register changed, so that one of the outputs became an input. This of course caused a malfunction in our circuit. Rewriting the TRISA register with the correct value helped somewhat, but did not completely solve the problem. We assume that the wrong bank (bank 1) was addressed during access of the port data register.

1. About two of three devices hang after having worked for several minutes, though the watchdog has been activated. This application makes extensive use of interrupts. We assume that incorrect RAM bank addressing causes this problem, too.

We tested the same program (i.e. the same HEX file) with three different controller types:

- PIC16F628 - runs well

- PIC16F628A - runs well

- PIC16F648A - problems occur

Additionally, we used a PIC 16F873 and an 873A with an adapter and a small software modification, and both performed without problems.

We assume that there is a critical detail in the internal structure of the controller. We do not know the exact cause of the failures, nor can we safely reproduce the problem in terms of a "recipe" to make it happen.

Perhaps anyone experienced similar problems with these chips, or can give any hint?

Thanks in advance for any response.

My guess is that the problem is an interrupt code bug that needs a certain timing to occur, since you say it takes "several minutes" to fail. Somewhere in your interrupt service code, you are not properly saving and restoring the STATUS register. Does any interrupt code select bank 1 ?

-Robert Scott Ypsilanti, Michigan (Reply through newsgroups, not by direct e-mail, as automatic reply address is fake.)

During a new development we experienced critical problems with PIC 16F648A controllers (package DIP18, date code 03142Y3). We observed two malfunctions:

1. When writing data to port A, the port configuration in the TRISA register changed, so that one of the outputs became an input. This of course caused a malfunction in our circuit. Rewriting the TRISA register with the correct value helped somewhat, but did not completely solve the problem. We assume that the wrong bank (bank 1) was addressed during access of the port data register.

1. About two of three devices hang after having worked for several minutes, though the watchdog has been activated. This application makes extensive use of interrupts. We assume that incorrect RAM bank addressing causes this problem, too.

We tested the same program (i.e. the same HEX file) with three different controller types:

- PIC16F628 - runs well

- PIC16F628A - runs well

- PIC16F648A - problems occur

Additionally, we used a PIC 16F873 and an 873A with an adapter and a small software modification, and both performed without problems.

We assume that there is a critical detail in the internal structure of the controller. We do not know the exact cause of the failures, nor can we safely reproduce the problem in terms of a "recipe" to make it happen.

Perhaps anyone experienced similar problems with these chips, or can give any hint?

Thanks in advance for any response.

not

If you suspect that the bank selection is being corrupted, then you could add some diagnostic checks of the STATUS register just AFTER each write to Port A. If you ever find the bank selection bit set incorrectly, then you will know that something is setting it that way.

-Robert Scott Ypsilanti, Michigan (Reply through newsgroups, not by direct e-mail, as automatic reply address is fake.)

Hello,

I have just been to the microchip web site but couldn't find 16F648!

I noticed the 16F628 has comparators but no ADCs.

You must configure the comparators, as they default to an on state. This causes pins to change their state and all sorts of strange things to happen.

Also make sure you have turned off any ADC on the 16f648 (if it has any) since your 16F628 doesn't have any, and once again they default to an on state.

If you have any more problems let me know.

Regards,

Geoffrey.

think,

momentary not

think, the

address is fake.)

There is no 16F648, only a 16F648A

It's essentially a 16F628A with double the ROM a bit more RAM and double the data EEPROM.

Best regards, Spehro Pefhany

Hallo Ppelectron !:

But ... 16F873 works fine, and the 16F648 not ... The program is in HiTech PICC written.

It is interesting, that one programm on 16f648 workscorrectly. He has one interrupt less. It does not have interrupt from timer 2.

All my interrupts are :

- timers 0 to 2

- ext int

- RS - ints (2x)

I think, that this is too much for this processor..... ;-( !!!

To follow up on some other posts, what does the memory map in the 16F648 look like? I think the 16F873 has some upper locations mapped to all banks. If the 16F648 doesn't, and that is where save data is stored, you could be lucky sometimes on the bank switch and sometimes not.

The memory mapping in 16F648 and 16F873 is exactly identical !!! but 16F873 have more registers. The last 16 Bytes is not "banked". And THE SAME PRGRAM on 873 works fine, aks on 648 NOT. The same machine code !!!!

Hallo Robert Scott !:

have

A few lines form listing :

OK, now lets see the interrupt exit code....

-Robert Scott Ypsilanti, Michigan (Reply through newsgroups, not by direct e-mail, as automatic reply address is fake.)