He confirmed that he did check on that yesterday and they are all configured as outputs. Quintin Beukes On Tue, Sep 22, 2009 at 5:13 PM, Jan-Erik Soderholm wrote: > > > Bob Axtell wrote: >> (header added to expand readership. Most people reject missing header >> messages) >> >> I understand your problem, and we have ALL had a problem like this at one >> time or another. >> >> In my experience, this is caused by one of the multiple VSS or VDD pins >> floating. See, internally, some PICs operate in sections (to ease chip >> testing), and the pins MUST be attached properly. Make sure that this is >> actually performed, by measuring from the GND plane to each pin with a LOW >> RANGE OHMMETER. Just using a standard meter is misleading, because the >> internal connection can be good enough for a "beep". The connection has to >> be 1/10 of an ohm or LESS. >> >> The second place to look is at the oscillator / resonator. If the GND >> connection to the phase shifting caps is not good, the oscillator can do >> bizarre things. >> >> Report your findings! >> >> --Bob >> >> >> >> >> >>> 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 >>> -- >>> http://www.piclist.com PIC/SX FAQ & list archive >>> View/change your membership options at >>> http://mailman.mit.edu/mailman/listinfo/piclist >>> >> >> > > This can be caused of *any* I/O pin left as an "open input". > Never *ever* do that with *any* CMOS chip. > Since a plain digital I/O pin is input by default, I'd guess > that you have simply "forgot" to switch any unused pins to output. > -- > 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