Searching \ for 'Bug in the PIC ???' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Bug in the PIC ???'.

Truncated match.
PICList Thread
'Bug in the PIC ???'
1997\07\01@055831 by ms

flavicon
face
dmulally@silver.sdsmt.edu wrote:
{Quote hidden}

--
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_OUTmsTakeThisOuTspamzam.nf.fh-nuernberg.de
 91058 Erlangen, Germany             (Ger/Eng/Spa welcome)
-----------------------------------------------------------------------

1997\07\03@021347 by ms

flavicon
face
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}

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: .....msKILLspamspam@spam@zam.nf.fh-nuernberg.de
 91058 Erlangen, Germany             (Ger/Eng/Spa welcome)
-----------------------------------------------------------------------

More... (looser matching)
- Last day of these posts
- In 1997 , 1998 only
- Today
- New search...