Hey, > 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. It's definitely not unnoticed code setting it. As a test for the reboot I made a simple program which only does the basic configuration with the following. When the program starts it turns on LED1, waits for 8 seconds and turns on LED2. Then it enters an infinite loop. This allowed us to do tests on it and notice when it reboots. > 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. This sounds very interesting and might even explain why it sometimes enters an infinite loop of rapid resets. Will have a look. I noticed that sometimes when you reset the PIC with static it enters this infinite loop. I guess it's if the static is discharged at the perfect timings, and what you say sounds like it could be related to this "perfect timing", ie. one discharge to reset and then another charge before the configuration instructions, like you mentioned > 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. We eventually didn't ground them, but we are aware of this. Francois explained it and the reasons for it in the same conversation where he mentioned we shouldn't ground the open OUTPUT pins. Thanks anyway. Quintin Beukes On Wed, Sep 23, 2009 at 8:18 PM, M. Adam Davis wrote: > Just because you set TRISB =3D 0x00 doesn't mean that it remained there. > =A0Might 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 wro= te: >> 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 sc= hematic. >> >> 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 wro= te: >>> 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 condit= ions >>> 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 sev= eral >>> 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 "= output" >>> 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 Jour= ney 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.= speff.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 > -- = http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist