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 wrote: > 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 controlle= d. > > 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..." =A0 =A0 =A0 =A0 =A0 =A0"The Journe= y 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.sp= eff.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