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
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
.......
Still no ....
...
NO !!!!!
I know !!!
Still no. I have not too much time .....
:-(((
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
Hallo Wolfgang Mahringer !: .......
No, :-( .... Not only I have this problem ! This is like reproducible !
I too ....
N-HTH
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.
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
Hallo Wolfgang Mahringer !: .......
All chips at my distributor have the same date code ..... I wait from two months onto a new chips .....
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,
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.
Hallo Jan-Erik Söderholm !: .......
Yes, during THIS SEQUENCE, and NOT during the EEPROM program cycle - the next
4-8 ms !!!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.
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
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.
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 ???
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
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 ....
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.
Have something to add? Share your thoughts — no account required.
Ask the community — no account required