Just because you set TRISB =3D 0x00 doesn't mean that it remained there. Might want to check with a debugger to be certain that nothing else in the program changes it, especially runaway code. Further, and this could be the main issue, there is a period of time between reset and TRISB =3D 0x00 where the chip is vulnerable to static induced resets due to several pins in port B being left floating inputs. Also, if you initialize interrupts before you set TRIS and you enable interrupt on pin change, you may also be causing what appear to be resets because your pins are floating inputs until the TRIS setup. If you've decided to keep the pins as outputs AND ground them, please do so through a resistor - you will save yourself much headache later. -Adam On Wed, Sep 23, 2009 at 1:59 PM, Quintin Beukes wrote: > We verified all inputs carefully. We have 3 lines: > =A0 =A0 =A0 =A0TRISA=3D0x18; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 //00011000 > =A0 =A0 =A0 =A0TRISB=3D0x00; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 //00000000 > =A0 =A0 =A0 =A0TRISC=3D0x80; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 //10000000 > > Me and Francois checked all those ports against the datasheet and the sch= ematic. > > Further, we eventually didn't ground the PINs because Francois also > said that it's "bad". Though we found shorting them against each other > only also prevented the PIC from rebooting due to static. > > We will definitely do those tests you mentioned on all PINs to ensure > they are in fact outputs, and get back to you on the results. We've > got public holiday tomorrow, so it will only be by Friday. > > Quintin Beukes > > > > On Wed, Sep 23, 2009 at 7:16 PM, Spehro Pefhany wrot= e: >> At 12:45 PM 23/09/2009, you wrote: >>>That was actually what we tried RIGHT before finding the solution. >>>Doing the 10k resistor between VDD and MCLR didn't help for being >>>reset by static fields. And when only the PORTB output pins are >>>grounded, then it takes the problem away. >>> >>>Quintin Beukes >> >> >> You should not ground outputs directly, IMHO, ever. There is no way that >> an output would cause the symptoms you describe (barring extreme conditi= ons >> such as very high EMI in the vicinity from a substantial RF >> transmitter, welder etc.). >> >> Most likely, there is a floating input somewhere in your system that is >> triggering the reset either directly or via an interrupt. There are seve= ral >> interrupt pins on PORTB. >> >> At this point you should not be trusting anything- verify that the pins >> are actually outputs by verifying that they will actually sink or source >> current (eg. to an LED in series with a resistor to Vdd or Vss). >> You could also try feeding a ~10Hz 0V/5V square wave signal into each "o= utput" >> via a 1K series resistor and see if any misbehavior is noted. >> >>>Best regards, >> >> Spehro Pefhany --"it's the network..." =A0 =A0 =A0 =A0 =A0 =A0"The Journ= ey is the reward" >> speff@interlog.com =A0 =A0 =A0 =A0 =A0 =A0 Info for manufacturers: http:= //www.trexon.com >> Embedded software/hardware/analog =A0Info for designers: =A0http://www.s= peff.com >> >> >> >> -- >> http://www.piclist.com PIC/SX FAQ & list archive >> View/change your membership options at >> http://mailman.mit.edu/mailman/listinfo/piclist >> > > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > -- = http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist