Post by thread:Static Reboot

Hey, We discovered a very odd problem with our PIC18LF2520's. When you approach the PIC it reboots. With some experimentation we found that it's because of sensitivity to static electricity. In other words grounding onself it doesn't happen, and deliberate charging causes the PIC to reboot at physically further distances depending on the amount of charge you're carrying. This is bad. Note that the MCLR is configured as an output to an LED, so I don't see this as being the reason for the reboot. Further. We have found that sometimes when you start them they just keep resetting. In the main method we have the basic configuration, like setting the ports LO, turning on LEDs, configuring the tranceivers, etc. There after we print the software name+version to the serial port. When watching the serial, all you see is the name+version being printed in a loop. The code has no loop wrapping this, and the only way for this to happen is if the main method would be repeatedly called, and again the only way I can see this happening is with the PIC enter/recovering from reset continuously. This is bad :/ I'm not sure if these 2 problems are related. Though the latter definitely makes the system unusable, because once it occurs the only way to fix it is to turn it off/on until it starts to act it's age. Any advice/ideas would be more than appreciated. The engineers over here are down on ideas. If you need more info, just specify what and I'll send it along. Quintin Beukes

Make sure fuse settings actually set MCLR to an I/O port. Remove the led if necessary and pull MCLR to VCC just to be sure the same issue exists when using MCLR as a reset line. Is there any ripple on the supply? What kind of oscillator are you using (what's the load capacitance), and does it have capacitors from each side to ground, and if so what value? Is there any resistance across the crystal? A schematic and graphic of the board layout including ground plane would help. Since you have serial communication that can help you debug, change the code to show the reset source on powerup through the serial port so you can figure out why it's resetting. Tony Picbits Sales wrote: {Quote hidden}> I've seen this happen a lot in PICs that aren't adequately decoupled. > > Check you have a decoupling capacitor (or capacitors) as close to the power > pins as possible. Try the circuit with a 100nF + 10nF + 1nF in parallel to > the power pins. > > Are you using an internal or external oscillator ? It could be the > oscillator design becomes unstable when the extra capacitance of the human > body enters the equation. > > Dom > > {Original Message removed}

What you said sounds so easy ;> If we could only reproduce it while at the office... even while at the PIC. We only notice the problems when remotely logged in. For the first time yesterday we had it happen in the office. Either way, I'll get you that information. Thanks for all the quick responses! Everytime I see an incoming mail I hope this might be "the one" :> Quintin Beukes On Tue, Sep 22, 2009 at 5:25 PM, Tony Vandiver <.....tonyKILLspam@spam@traceelectronics.com> wrote: {Quote hidden}> Make sure fuse settings actually set MCLR to an I/O port. Remove the > led if necessary and pull MCLR to VCC just to be sure the same issue > exists when using MCLR as a reset line. Is there any ripple on the > supply? What kind of oscillator are you using (what's the load > capacitance), and does it have capacitors from each side to ground, and > if so what value? Is there any resistance across the crystal? A > schematic and graphic of the board layout including ground plane would > help. Since you have serial communication that can help you debug, > change the code to show the reset source on powerup through the serial > port so you can figure out why it's resetting. > > Tony > > > Picbits Sales wrote: >> I've seen this happen a lot in PICs that aren't adequately decoupled. >> >> Check you have a decoupling capacitor (or capacitors) as close to the power >> pins as possible. Try the circuit with a 100nF + 10nF + 1nF in parallel to >> the power pins. >> >> Are you using an internal or external oscillator ? It could be the >> oscillator design becomes unstable when the extra capacitance of the human >> body enters the equation. >> >> Dom >> >> {Original Message removed}

Power on could be too lazy, PWRTE is disabled an BOR enabled to a wrong thresold voltage. Vasile On 9/22/09, Quintin Beukes <quintinKILLspamlast.za.net> wrote: {Quote hidden}> These guys say that they do have 2 capacitors over ground/positive. > Though not "as close as possible to the pic", and not those sizes. > > Further, we're using an external oscillator. Though the static problem > I don't think is our biggest problem. Our real "problem" is that they > intermittently go into infinite reset loops when powered on. > > Quintin Beukes > > > > On Tue, Sep 22, 2009 at 4:56 PM, Picbits Sales <.....salesKILLspam.....picbits.co.uk> wrote: > > I've seen this happen a lot in PICs that aren't adequately decoupled. > > > > Check you have a decoupling capacitor (or capacitors) as close to the power > > pins as possible. Try the circuit with a 100nF + 10nF + 1nF in parallel to > > the power pins. > > > > Are you using an internal or external oscillator ? It could be the > > oscillator design becomes unstable when the extra capacitance of the human > > body enters the equation. > > > > Dom > > > > {Original Message removed}

At 10:39 AM 22/09/2009, you wrote: {Quote hidden}>Hey, > >We discovered a very odd problem with our PIC18LF2520's. When you >approach the PIC it reboots. With some experimentation we found that >it's because of sensitivity to static electricity. In other words >grounding onself it doesn't happen, and deliberate charging causes the >PIC to reboot at physically further distances depending on the amount of >charge you're carrying. > >This is bad. > >Note that the MCLR is configured as an output to an LED, so I don't see >this as being the reason for the reboot. > >Further. We have found that sometimes when you start them they just >keep resetting. In the main method we have the basic configuration, like >setting the ports LO, turning on LEDs, configuring the tranceivers, etc. >There after we print the software name+version to the serial port. When >watching the serial, all you see is the name+version being printed in a >loop. The code has no loop wrapping this, and the only way for this to >happen is if the main method would be repeatedly called, and again the >only way I can see this happening is with the PIC enter/recovering from >reset continuously. > >This is bad :/ > >I'm not sure if these 2 problems are related. Though the latter definitely >makes the system unusable, because once it occurs the only way to fix >it is to turn it off/on until it starts to act it's age. > >Any advice/ideas would be more than appreciated. The engineers over >here are down on ideas. If you need more info, just specify what and >I'll send it along. The second problem sounds like the WDT could be enabled and resetting the micro, but "sometimes" is odd, so maybe not. I seriously doubt your engineers have managed to configure /MCLR as an output unless they have access to some very specialized equipment ;-) .. it is "input only".. so the LED is obviously not going to be controlled. If /MCLR is enabled and floating you could see such problems.. especially if the pin is fitted with an antenna such as a wire to an unused LED. >Best regards, Spehro Pefhany --"it's the network..." "The Journey is the reward" EraseMEspeffspam_OUTTakeThisOuTinterlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com

Firstly, the WDT is disabled. We have an exit(0) in the code, though it was removed in a version of the code I was using to test something, and this exact one accidentally went to the client (mix up). And it also had this problem. i know this because I changed the "name" being printed at startup, and when having a look at the device it was this name being printed repeatedly. So it's safe to say that it's not the WDT or a programmatic exit(). We do have the BOR enabled. I can't say for 100% sure, but will confirm the PWRTE, though all the source files I've seen have had them enabled so far. So I doubt this is the problem. Maybe it's not connected to an LED. I'm not sure. Though I know that it is configured as either an INPUT/OUTPUT. I'm working from memory now, but I'm sure I remember the MCLR being configured as an OUTPUT. I know for a fact that it is configured to not be an MCLR. I asked about this earlier and he said that it is done in the configuration bits when programming the PIC. Will confirm this, and get the information requested by you guys. Sorry for the "middle man" approach. I'll try and convince the engineer working on this device to join the list himself. Quintin Beukes On Tue, Sep 22, 2009 at 5:20 PM, Spehro Pefhany <speffspam_OUTinterlog.com> wrote: {Quote hidden}> At 10:39 AM 22/09/2009, you wrote: >>Hey, >> >>We discovered a very odd problem with our PIC18LF2520's. When you >>approach the PIC it reboots. With some experimentation we found that >>it's because of sensitivity to static electricity. In other words >>grounding onself it doesn't happen, and deliberate charging causes the >>PIC to reboot at physically further distances depending on the amount of >>charge you're carrying. >> >>This is bad. >> >>Note that the MCLR is configured as an output to an LED, so I don't see >>this as being the reason for the reboot. >> >>Further. We have found that sometimes when you start them they just >>keep resetting. In the main method we have the basic configuration, like >>setting the ports LO, turning on LEDs, configuring the tranceivers, etc. >>There after we print the software name+version to the serial port. When >>watching the serial, all you see is the name+version being printed in a >>loop. The code has no loop wrapping this, and the only way for this to >>happen is if the main method would be repeatedly called, and again the >>only way I can see this happening is with the PIC enter/recovering from >>reset continuously. >> >>This is bad :/ >> >>I'm not sure if these 2 problems are related. Though the latter definitely >>makes the system unusable, because once it occurs the only way to fix >>it is to turn it off/on until it starts to act it's age. >> >>Any advice/ideas would be more than appreciated. The engineers over >>here are down on ideas. If you need more info, just specify what and >>I'll send it along. > > The second problem sounds like the WDT could be enabled and resetting the > micro, but "sometimes" is odd, so maybe not. > > I seriously doubt your engineers have managed to configure /MCLR as an > output unless they have access to some very specialized equipment ;-) > .. it is "input only".. so the LED is obviously not going to be controlled. > > If /MCLR is enabled and floating you could see such problems.. especially > if the pin is fitted with an antenna such as a wire to an unused LED. > >>Best regards, > > Spehro Pefhany --"it's the network..." "The Journey is the reward" > @spam@speffKILLspaminterlog.com Info for manufacturers: http://www.trexon.com > Embedded software/hardware/analog Info for designers: http://www.speff.com > > > >

Quintin Beukes wrote: > Firstly, the WDT is disabled. We have an exit(0) in the code, though > it was removed in a version of the code I was using to test > something, and this exact one accidentally went to the client (mix > up). And it also had this problem. i know this because I changed the > "name" being printed at startup, and when having a look at the device > it was this name being printed repeatedly. So it's safe to say that > it's not the WDT or a programmatic exit(). If you use C, there is always an implicit "exit" at the end of main(). When you reach the end of main you exit it, and most compilers for embedded systems (re)start at the reset vector. > Maybe it's not connected to an LED. I'm not sure. Though I know that > it is configured as either an INPUT/OUTPUT. I'm working from memory > now, but I'm sure I remember the MCLR being configured as an OUTPUT. > I know for a fact that it is configured to not be an MCLR. I asked > about this earlier and he said that it is done in the configuration > bits when programming the PIC. As others have said, independently of whether this pin is an input or MCLR (which is also an input), it should always be pulled to one of the rails by external circuitry. Gerhard

Hey, Thanks for all your help. It definitely helped us reach the solution, because in the process of trying these things Francois discovered the problem (by just "trying" something), which ended up removing the problem - or so it seems. We'll see on Friday when they are installed in the field. So to recap. We noticed that at times when powering up the PIC it goes into endless resets. These happen at crazy speeds. If you opened a serial interface to the PIC your screen would literally be flooded with the boot up message. So the solution was grounding 4 open outputs. They were definitely configured as outputs. We confirmed this 3 times. They were all on PORTB, and we set TRISB=0x00; You guys sent a lot of mails (thanks for that), didn't someone somewhere mention that even if a pin is configured as an OUTPUT, that it should still be grounded? If this is not a standard, why would an open output cause a reset when millivolts are applied to the pin (ex. static electricity from the body when approaching the device)? I will let post our results on Friday. Quintin Beukes On Wed, Sep 23, 2009 at 11:34 AM, Tamas Rudnai <RemoveMEtamas.rudnaiTakeThisOuTgmail.com> wrote: {Quote hidden}> On Wed, Sep 23, 2009 at 9:11 AM, Quintin Beukes <spamBeGonequintinspamBeGonelast.za.net> wrote: > >> Further, he confirmed that the MCLR is used as a programming PIN. I'm >> not sure if that is an open input/output. We are performing tests on >> this now. >> > > What Olin and others suggested about putting an unused pin to output and > drive them active low is not applicable to this pin. As Jan-Erik pointed out > the VPP/MCLR/RE3 pin can be configured either MCLR or digital input, but not > output. Also there is no internal pull-up for that pin, so no matter if you > use it as MCLR or digital input that pin needs an external circuit anyway. > > Tamas > > >> >> Q >> --

At 11:32 AM 9/22/2009, Quintin Beukes wrote: >Maybe it's not connected to an LED. I'm not sure. Though I know that >it is configured as either an INPUT/OUTPUT. I've just read your most recent message, where you say that MCLR is used as a programming pin. I guess my question would be: is there a pull-up or pull-down resistor on that pin? The reason that is important is this: even if MCLR is configured as an input, it can still have an effect on the PIC, The reason is that MCLR is responsive to 3 different voltage levels: Gnd, 5V, Vpp. If MCLR is just floating, it is possible that an external static field can drive MCLR well above 5V and into the Vpp territory. The PIC will do decidedly strange things when that happens - most often, it will attempt to go into programming mode. But the effect is different with different PIC families. My suggestion, for what its worth, would be to examine the PCB and see what is connected to MCLR. If it is just floating, tie a 10K resistor between MCLR and Vdd. You may now find that your problems have vanished. dwayne -- Dwayne Reid <TakeThisOuTdwaynerEraseMEspam_OUTplanet.eon.net> Trinity Electronics Systems Ltd Edmonton, AB, CANADA (780) 489-3199 voice (780) 487-6397 fax http://www.trinity-electronics.com Custom Electronics Design and Manufacturing

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 On Wed, Sep 23, 2009 at 6:10 PM, Dwayne Reid <RemoveMEdwaynerTakeThisOuTplanet.eon.net> wrote: {Quote hidden}> At 11:32 AM 9/22/2009, Quintin Beukes wrote: > >>Maybe it's not connected to an LED. I'm not sure. Though I know that >>it is configured as either an INPUT/OUTPUT. > > I've just read your most recent message, where you say that MCLR is > used as a programming pin. > > I guess my question would be: is there a pull-up or pull-down > resistor on that pin? > > The reason that is important is this: even if MCLR is configured as > an input, it can still have an effect on the PIC, The reason is that > MCLR is responsive to 3 different voltage levels: Gnd, 5V, Vpp. If > MCLR is just floating, it is possible that an external static field > can drive MCLR well above 5V and into the Vpp territory. The PIC > will do decidedly strange things when that happens - most often, it > will attempt to go into programming mode. But the effect is > different with different PIC families. > > My suggestion, for what its worth, would be to examine the PCB and > see what is connected to MCLR. If it is just floating, tie a 10K > resistor between MCLR and Vdd. You may now find that your problems > have vanished. > > dwayne > > > -- > Dwayne Reid <dwaynerEraseME.....planet.eon.net> > Trinity Electronics Systems Ltd Edmonton, AB, CANADA > (780) 489-3199 voice (780) 487-6397 fax > http://www.trinity-electronics.com > Custom Electronics Design and Manufacturing > >

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 conditions 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 several 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..." "The Journey is the reward" EraseMEspeffinterlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com

If it's a problem of static field (and not an output which in real life is input ) then probably you should check if thre is any ground plane below the PIC belly which is left floated and not connected to GND (if there is any). I had once this problem, but with a SMD package. I hope your prototype is on a proffesional PCB before running in the field... Vasile On 9/23/09, Quintin Beukes <RemoveMEquintinEraseMEEraseMElast.za.net> wrote: {Quote hidden}> 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 > > > > On Wed, Sep 23, 2009 at 6:10 PM, Dwayne Reid <RemoveMEdwaynerspam_OUTKILLspamplanet.eon.net> wrote: > > At 11:32 AM 9/22/2009, Quintin Beukes wrote: > > > >>Maybe it's not connected to an LED. I'm not sure. Though I know that > >>it is configured as either an INPUT/OUTPUT. > > > > I've just read your most recent message, where you say that MCLR is > > used as a programming pin. > > > > I guess my question would be: is there a pull-up or pull-down > > resistor on that pin? > > > > The reason that is important is this: even if MCLR is configured as > > an input, it can still have an effect on the PIC, The reason is that > > MCLR is responsive to 3 different voltage levels: Gnd, 5V, Vpp. If > > MCLR is just floating, it is possible that an external static field > > can drive MCLR well above 5V and into the Vpp territory. The PIC > > will do decidedly strange things when that happens - most often, it > > will attempt to go into programming mode. But the effect is > > different with different PIC families. > > > > My suggestion, for what its worth, would be to examine the PCB and > > see what is connected to MCLR. If it is just floating, tie a 10K > > resistor between MCLR and Vdd. You may now find that your problems > > have vanished. > > > > dwayne > > > > > > -- > > Dwayne Reid <RemoveMEdwaynerTakeThisOuTspamplanet.eon.net> > > Trinity Electronics Systems Ltd Edmonton, AB, CANADA > > (780) 489-3199 voice (780) 487-6397 fax > > http://www.trinity-electronics.com > > Custom Electronics Design and Manufacturing > > > > --

This is in fact a professional board, and it has a solid ground plane at the bottom. This is no longer the prototype. All tests on the prototype were successful. It was when they were put in the field that problems occurred. Also, our PIC doesn't have track/plane directly below it (below "the belly", as you say). Is this an official term? Quintin Beukes On Wed, Sep 23, 2009 at 7:39 PM, Vasile Surducan <EraseMEpiclist9spamspamBeGonegmail.com> wrote: {Quote hidden}> If it's a problem of static field (and not an output which in real > life is input ) then probably you should check if thre is any ground > plane below the PIC belly which is left floated and not connected to > GND (if there is any). I had once this problem, but with a SMD > package. I hope your prototype is on a proffesional PCB before running > in the field... > > Vasile > > On 9/23/09, Quintin Beukes <RemoveMEquintinKILLspamlast.za.net> 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 >> >> >> >> On Wed, Sep 23, 2009 at 6:10 PM, Dwayne Reid <dwaynerSTOPspamspam_OUTplanet.eon.net> wrote: >> > At 11:32 AM 9/22/2009, Quintin Beukes wrote: >> > >> >>Maybe it's not connected to an LED. I'm not sure. Though I know that >> >>it is configured as either an INPUT/OUTPUT. >> > >> > I've just read your most recent message, where you say that MCLR is >> > used as a programming pin. >> > >> > I guess my question would be: is there a pull-up or pull-down >> > resistor on that pin? >> > >> > The reason that is important is this: even if MCLR is configured as >> > an input, it can still have an effect on the PIC, The reason is that >> > MCLR is responsive to 3 different voltage levels: Gnd, 5V, Vpp. If >> > MCLR is just floating, it is possible that an external static field >> > can drive MCLR well above 5V and into the Vpp territory. The PIC >> > will do decidedly strange things when that happens - most often, it >> > will attempt to go into programming mode. But the effect is >> > different with different PIC families. >> > >> > My suggestion, for what its worth, would be to examine the PCB and >> > see what is connected to MCLR. If it is just floating, tie a 10K >> > resistor between MCLR and Vdd. You may now find that your problems >> > have vanished. >> > >> > dwayne >> > >> > >> > -- >> > Dwayne Reid <spamBeGonedwaynerSTOPspamEraseMEplanet.eon.net> >> > Trinity Electronics Systems Ltd Edmonton, AB, CANADA >> > (780) 489-3199 voice (780) 487-6397 fax >> > http://www.trinity-electronics.com >> > Custom Electronics Design and Manufacturing >> > >> > --

On Wed, Sep 23, 2009 at 6:16 PM, Spehro Pefhany <KILLspamspeffspamBeGoneinterlog.com> wrote: > 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. > That's a good point actually. I am not sure which language the firmware was developped but *if* there is any firmware error on banking or context savings in the isr or even with the indirect addressing then the TRIS could set incorrectly at some point so that the PORTB becomes floating input from active output. Tamas {Quote hidden}> > >Best regards, > > Spehro Pefhany --"it's the network..." "The Journey is the > reward" > EraseMEspeffEraseMEinterlog.com Info for manufacturers: > http://www.trexon.com > Embedded software/hardware/analog Info for designers: > http://www.speff.com > > > > -

We verified all inputs carefully. We have 3 lines: TRISA=0x18; //00011000 TRISB=0x00; //00000000 TRISC=0x80; //10000000 Me and Francois checked all those ports against the datasheet and the schematic. 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 <@spam@speff@spam@spam_OUTinterlog.com> wrote: {Quote hidden}> 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 conditions > 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 several > 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..." "The Journey is the reward" > spamBeGonespeffKILLspaminterlog.com Info for manufacturers: http://www.trexon.com > Embedded software/hardware/analog Info for designers: http://www.speff.com > > > >

Thanks for both of these messages. I agree and will definitely verify this first thing Friday morning. Quintin Beukes On Wed, Sep 23, 2009 at 7:56 PM, Tamas Rudnai <.....tamas.rudnaispam_OUTgmail.com> wrote: {Quote hidden}> On Wed, Sep 23, 2009 at 6:16 PM, Spehro Pefhany <TakeThisOuTspeff.....TakeThisOuTinterlog.com> wrote: > >> 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. >> > > That's a good point actually. I am not sure which language the firmware was > developped but *if* there is any firmware error on banking or context > savings in the isr or even with the indirect addressing then the TRIS could > set incorrectly at some point so that the PORTB becomes floating input from > active output. > > Tamas > > > >> >> >Best regards, >> >> Spehro Pefhany --"it's the network..." "The Journey is the >> reward" >> TakeThisOuTspeffKILLspamspaminterlog.com Info for manufacturers: >> http://www.trexon.com >> Embedded software/hardware/analog Info for designers: >> http://www.speff.com >> >> >> >> -

Just because you set TRISB = 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 = 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 <.....quintinRemoveMElast.za.net> wrote: {Quote hidden}> We verified all inputs carefully. We have 3 lines: > TRISA=0x18; //00011000 > TRISB=0x00; //00000000 > TRISC=0x80; //10000000 > > Me and Francois checked all those ports against the datasheet and the schematic. > > 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 <RemoveMEspeffspamBeGoneinterlog.com> wrote: >> 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 conditions >> 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 several >> 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..." "The Journey is the reward" >> spamBeGonespeff@spam@spam_OUTinterlog.com Info for manufacturers: http://www.trexon.com >> Embedded software/hardware/analog Info for designers: http://www.speff.com >> >> >> >> -

Hey, > Just because you set TRISB = 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 = 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 <TakeThisOuTstienmanspamgmail.com> wrote: {Quote hidden}> Just because you set TRISB = 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 = 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 <quintinEraseMElast.za.net> wrote: >> We verified all inputs carefully. We have 3 lines: >> TRISA=0x18; //00011000 >> TRISB=0x00; //00000000 >> TRISC=0x80; //10000000 >> >> Me and Francois checked all those ports against the datasheet and the schematic. >> >> 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 <RemoveMEspeffEraseMEspam_OUTinterlog.com> wrote: >>> 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 conditions >>> 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 several >>> 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..." "The Journey is the reward" >>> @spam@speffRemoveMEEraseMEinterlog.com Info for manufacturers: http://www.trexon.com >>> Embedded software/hardware/analog Info for designers: http://www.speff.com >>> >>> >>> >>> --

> 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. > Reading this thread brought several things to mind. They are not necessarily aimed at your problem, but can be generally applied. If connecting the pins together without grounding them remedies the problem, that suggests that at least one of them is an input, and that at least one of them is an output. In effect, it ties the inputs to whatever logic level the output pin is. It also demonstrates that an "approach of static" (a high impedance phenomenon) would not affect an output pin (or any pin connected to it). If one of the pins is found to be an input, then that's kind of a lesson worth considering when approaching the notion of connecting unused pins to ground. They say, "Be sure you don't try to drive them high". And we say, "I'm careful not to." And then something like this happens, causing us to reconsider just how sure about that we are :) TRIS is not the end-all in pin programming either. I had a situation once where port D was behaving extremely strangely. It turned out the parallel port feature had been enabled, which meant some other pin (on port E) was controlling its ability to be an input. I looked at the chip in question here, and I see that some of port B can be an A/D channel. There's a register to make it not do that, and it has to be set when you start. Things like that. And then the overall lesson. “When you eliminate the impossible, whatever remains--however improbable--must be the truth.” Paraphrasing that, it says that once you know nothing in your circuit could be wrong, you are left with the task of proving it. That's why putting a TRIS instruction in your code almost certainly sets the port up, but only "almost". You would still need to show that it actually compiled into your code, that it is actually loaded (and gets executed!) on the chip, that it had the intended effect, and that nothing else fiddled with the port later. (And maybe another thing I haven't thought of!) Barry

Very good thoughts. I appreciate it. Quintin Beukes On Wed, Sep 23, 2009 at 10:12 PM, Barry Gershenfeld <EraseMEgbarry42@spam@gmail.com> wrote: {Quote hidden}>> 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. >> > > > Reading this thread brought several things to mind. They are not > necessarily aimed at your problem, but can be generally applied. > > > If connecting the pins together without grounding them remedies the problem, > that suggests that at least one of them is an input, and that at least one > of them is an output. In effect, it ties the inputs to whatever logic level > the output pin is. It also demonstrates that an "approach of static" (a > high impedance phenomenon) would not affect an output pin (or any pin > connected to it). > > If one of the pins is found to be an input, then that's kind of a lesson > worth considering when approaching the notion of connecting unused pins to > ground. They say, "Be sure you don't try to drive them high". And we say, > "I'm careful not to." And then something like this happens, causing us to > reconsider just how sure about that we are :) > > TRIS is not the end-all in pin programming either. I had a situation once > where port D was behaving extremely strangely. It turned out the parallel > port feature had been enabled, which meant some other pin (on port E) was > controlling its ability to be an input. I looked at the chip in question > here, and I see that some of port B can be an A/D channel. There's a > register to make it not do that, and it has to be set when you start. > Things like that. > > And then the overall lesson. “When you eliminate the impossible, whatever > remains--however improbable--must be the truth.” Paraphrasing that, it says > that once you know nothing in your circuit could be wrong, you are left with > the task of proving it. That's why putting a TRIS instruction in your code > almost certainly sets the port up, but only "almost". You would still need > to show that it actually compiled into your code, that it is actually loaded > (and gets executed!) on the chip, that it had the intended effect, and that > nothing else fiddled with the port later. (And maybe another thing I > haven't thought of!) > > Barry >