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.

--
Grzegorz Zalot

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

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.

--
Grzegorz Zalot

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

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.)

Reply to
Robert Scott

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.

--
Grzegorz Zalot

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

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.)

Reply to
Robert Scott

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.)

>
Reply to
Geoffrey Swales

There is no 16F648, only a 16F648A

formatting link

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

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
 Click to see the full signature
Reply to
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..... ;-( !!!

--
Grzegorz Zalot

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

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.

Reply to
dennyd

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 !!!!

--
Grzegorz Zalot

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

Hallo Robert Scott !:

have

A few lines form listing :

************************ 767 psect intsave_0 768 007F saved_w 769 007F ds 1 ............. 784 0004 int_entry 785 0004 00FF movwf saved_w 786 0005 0803 movf 3,w 787 0006 0183 clrf 3 788 0007 00F7 movwf saved_status 789 0008 0804 movf 4,w 790 0009 00F8 movwf saved_fsr 791 000A 080A movf 10,w 792 000B 00F9 movwf saved_pclath 793 000C 018A clrf 10 794 795 psect intsave 796 0077 saved_status 797 0077 ds 1 798 0078 saved_fsr 799 0078 ds 1 800 0079 saved_pclath 801 0079 ds 1 ************************* This is automatically generated by HtPICC. Wrong way ......
--
Grzegorz Zalot

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

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.)

Reply to
Robert Scott

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.