Post by thread:Bug in the PIC ???

dmulally@silver.sdsmt.edu wrote: {Quote hidden}> > Marc Schmaeche wrote: > > > > Hi folks, > > > > Enclosed you will see an extract of a complete PICMASTER's trace which > > shows my problem. For some reason (which I don't know yet) my ISR > > (interrupt service routine) is carried out twice. Below the trace there > > are some explanations what's done in the ISR and the main routine. > > > As already mentioned my problem is that the ISR is executed twice. To > > the best of my knowledge this shouldn't occur under any conditions! > > > > Please give me a note if I'm wrong or if I missed anything. > > > > Any hints will be appreciated highly. > > Thanks in advance for your comments. > > > > Best regards, > > Marc Schmaeche > > > Marc, > I don't speak from personal experience and havn't looked at your code > carefully but I've been told that this can happen due to a bug in the > PIC. Something to do with the interupt flag being clocked into a > flip-flop and taking 2 cycles to clear. A programming friend of mine > insists that one should always check conditions to ensure that the > interrupt is valid to avoid this. I'm not sure if all PICS do this. > > Dan -- Dear Dan, That's a good hint - but bad news for me too. Of course I can check all the Interrupt Flag bits before the Interrupt service routine (ISR) is responding to any of the Interrupt events. But this would add a considerable amount of "wasted" time nor it would prevent the PIC from starting the ISR twice (and wasting more time). I wonder if anybody else have had already (bad) experience like this? Moreover I'm becoming suspicious that the PIC16C622 sometimes might "forget" enabled Interrupts (although I didn't yet achieve to get an appropriate trace). I would be very grateful if you or somebody else would send me more information concerning the problems mentioned above (especially which member of the PIC family was involved). I look forward to hearing from you soon. Thank you very much for your help. Best regards, Marc Schmaeche ----------------------------------------------------------------------- ZENTRUM FUER ANGEWANDTE MIKROELEKTRONIK UND NEUE TECHNOLOGIEN DER BAYERISCHEN FACHHOCHSCHULEN E.V. Dipl.-Ing. M.Schmaeche Tel.: +49 (0)9131 691145 ZAM-Anwenderzentrum Nbg. Fax: +49 (0)9131 691166 Am Weichselgarten 7 E-Mail: spam_OUTmsTakeThisOuTzam.nf.fh-nuernberg.de 91058 Erlangen, Germany (Ger/Eng/Spa welcome) -----------------------------------------------------------------------

Dear Steve, Thanks again for your suggestions. In the meantime my investigations have proceeded, please see below ... > > Dear Marc, > > I no longer have a copy of your code fragment, so the following may not apply. > What order are you clearing these bits? I would clear the enable first (INTE), > and then clear the flag (INTF). The Interrupt Logic schematics are in error in > several printings of the manual. My latest manual shows INTF and INTE feeding a > two input AND so that either one should disable this interrupt. What is not > shown in the diagram is any of the latches that must exist within the interrupt > firmware. > > Are you sure that no other interrupts are firing instead? All other interrupts Yes, because finally I decided to replace the "RETFIE" at the end of my ISR (interrupt service routine) by a "RETURN" statement. So this should definitely leave the GIE bit cleared (the GIE bit is then set again by the main routine). At the end of my ISR then the RETURN statement is executed and unfortunately the PIC sometimes jumps back to adress 0x0004 ! In my opinion this means that the adress 0x0004 also must have been placed on the stack in this case! Just have a look at the following piece of trace: 06CC 1C06 CHECKINP btfss 0x6,0x0 (00000111) <-- Bit0 is RB0 06CD 2F3E (Extra Cycle: Forced NOP) 06CE 108B bcf 0xB,0x1 (00000111) 06CF 3090 movlw 0x90 (00000111) 06D0 048B iorwf 0xB (00000110) <-- falling edge 06D1 0860 (Extra Cycle: Forced NOP) at RB0 06D1 0860 (Extra Cycle: Forced NOP) 0004 1806 (Extra Cycle: Forced NOP) 0004 1806 EXT_INT btfsc 0x6,0x0 (00000110) 0005 2FC5 (Extra Cycle: Forced NOP) 0006 120B bcf 0xB,0x4 (00000110) 0007 108B bcf 0xB,0x1 (00000110) 0008 144F bsf 0x4F,0x0 (00000110) 0009 00DE movwf 0x5E (00000110) 000A 0E01 swapf 0x1,W (00000110) 000B 00DF movwf 0x5F (00000110) 000C 0EDE swapf 0x5E (00000110) 000D 0E5E swapf 0x5E,W (00000110) 000E 1FE2 btfss 0x62,0x7 (00000110) 000F 0008 return (00000110) <-- RETURN to ... 0010 2E55 (Extra Cycle: Forced NOP) 0004 1806 EXT_INT btfsc 0x6,0x0 (00000110) <-- adress 0x0004 ? 0005 2FC5 (Extra Cycle: Forced NOP) 0006 120B bcf 0xB,0x4 (00000110) 0007 108B bcf 0xB,0x1 (00000110) 0008 144F bsf 0x4F,0x0 (00000110) 0009 00DE movwf 0x5E (00000110) 000A 0E01 swapf 0x1,W (00000110) 000B 00DF movwf 0x5F (00000110) 000C 0EDE swapf 0x5E (00000110) 000D 0E5E swapf 0x5E,W (00000110) 000E 1FE2 btfss 0x62,0x7 (00000110) 000F 0008 return (00000110) <-- RETURN to ... 0010 2E55 (Extra Cycle: Forced NOP) 06D1 0860 movf 0x60,W (00000110) <-- main program 06D2 1D03 btfss 0x3,0x2 (00000110) 06D3 3A1F xorlw 0x1F (00000110) > are disabled? Instead of clearing the INTF do the following instruction: > clrf INTCON Unfortunately not possible because I've to poll the TOIF for counting the TMR0 overflow events. As mentioned above the GIE remains cleared at the end of my ISR. That should lead to the same results. > > This clear instruction should wipeout all pending interrupts and disable all > interrupts. If you are still getting double interrupts then something > abnormal does seem to be going on in the silicon. At the moment I cannot imagine any other reason for this strange behaviour? > > Has the problem been seen on an actual device? The PICMASTER is only a > silicon approximation. I suppose the device has the same problem, because I started my investigation from rare failures of the OTP devices. When I got the same failure with the PICMASTER I analysed the trace and found these double ISR calls. > > Finally, INTCON is totally readable and writeable. Within the interrupt service {Quote hidden}> routine, place the contents of INTCON into a spare data register for later > analysis. > > Good Luck. > > ---- Steve Miller > > >The ISR (interrupt service routine) is called due to a falling edge > >(maybe also a short spike). But inside the ISR I'm clearing INTCON.INTF > >as well as INTCON.INTE. This way I want to prevent the ISR from beeing > >called twice. Am I wrong? I still wonder whether anybody else has made similar observations? Best regards, Marc Schmaeche ----------------------------------------------------------------------- ZENTRUM FUER ANGEWANDTE MIKROELEKTRONIK UND NEUE TECHNOLOGIEN DER BAYERISCHEN FACHHOCHSCHULEN E.V. Dipl.-Ing. M.Schmaeche Tel.: +49 (0)9131 691145 ZAM-Anwenderzentrum Nbg. Fax: +49 (0)9131 691166 Am Weichselgarten 7 E-Mail: .....msKILLspam@spam@zam.nf.fh-nuernberg.de 91058 Erlangen, Germany (Ger/Eng/Spa welcome) -----------------------------------------------------------------------