Olin Lathrop wrote: > David Duffy (AVD) wrote: > =20 >> The receiver is powered all the time, but its output goes to an NPN >> transistor that has a pull-up to Vdd. There is code in the receive ISR >> to dump bad packets and synchronise, but it seems like the receiver is >> just not listening. >> =20 > > Did you check for framing error in the receive code and reset the UART > receiver if found? A framing error can easily appear on power up. Slopp= y > UART code that doesn't check for and handle that will get hung as you > describe. > =20 Yes, framing and overrun errors are being handled. > David Duffy (AVD) wrote: > =20 >> The first was to add a 100n capacitor (also tried 10n & 1u) to the >> MCLR line. >> =20 > > Whoa, that's way big! Some programmers and debuggers may have a problem > with that. > =20 Or course. The object of the test was to see if delaying MCLR changed=20 the symptom. Obviously not a final (ICSP compatible) solution. >> I guess the only other thing I can try before replacing the PIC is to >> add some debugging pin code, maybe to the UART ISR for starters. >> =20 > > The *only* thing!? What about the obvious things like enabling brownout > detect and the powerup timer? Also make sure the UART handler is properl= y > written to handle framing errors and not hang on overruns. > =20 Brownout detect and powerup timer are enabled. > Jan-Erik Soderholm wrote: >> On 2010-11-25 13:24, David Duffy (AVD) wrote: >> =20 >>> As for power, there's not much to the circuit. A 12V battery >>> via a 1N4007, into a 78L05 with a 100uF on the input. >>> =20 >> What is the reason for the 100 uF cap between the battery >> and the 78L05 ? Intermittent larger current drains ? >> =20 The battery is not right at the board. There may be instances where it=20 is a metre or so away. The 100u input capacitor is there to keep the=20 source impedance low. Djula Djarmati wrote: > Are you clearing all registers at the beginning of the program? The bad=20 > PICs could power up with some inconvenient RAM value that you forgot to=20 > initialize. > =20 As this is a new chip type for me, it guess that's possible. I have=20 read the data sheet and think I have everything covered, but worth a look. > If not that, try to connect the PIC TX line to a PC and transmit back=20 > all what you receive. If you don't get good data, use the PC for both TX= =20 > and RX try again. That's possible as I don't think Tx is being used by anything else. alan.b.pearce@stfc.ac.uk wrote: > Ouch - does a 78L05 really have enough power dissipation to be dropping > 7V at whatever current you are drawing ??? Sure it is not doing a > thermal shutdown ??? > =20 The only thing powered from the 5V rail is the PIC and the 433MHz=20 receiver. (< 10mA, so 70mW max) Kerry Wentworth wrote: > This sounds to me like a register=20 > / variable is not getting initialized until after it is being used. On=20 > most processors it powers up in a state that allows the UART to run, but= =20 > on some, it powers up in a state that doesn't, as suggested by Djula. =20 > You could confirm this by grounding the 100nF cap on power up, then=20 > releasing it. If it still fails to respond to the UART, but does if you= =20 > momentarily touch it afterward (as you indicated it does) then it is=20 > almost certainly not a power up reset problem. Take a quick look at the= =20 > UART initialization code and see if anything jumps out at you. > =20 Yes, I had the thought about holding MCLR low at power-up, then=20 releasing it a few seconds later. It's at the top of my check list today. Kerry Wentworth wrote: > Can you modify the code so that the heart beat section sends a byte out=20 > the UART when it turns the LED on? That would allow you to confirm the=20 > UART is initialized and at the correct baud rate. Are you using auto=20 > baud detect? Not using auto baud, but sending a known byte out with the heartbeat=20 would be easy to do. Charles Craft wrote: > When you swap out the chip you're also redoing all the soldering. > What if you run a soldering iron around all the pins to refresh them > =20 That's a valid point. I don't do the SMD work myself these days, but=20 I'm pretty sure the PIC on the first suspect board was re-flowed (and=20 tested) before being replaced. I'll confirm with the guys and get them=20 to re-flow the PIC on the second board to verify. David... --=20 ___________________________________________ David Duffy Audio Visual Devices P/L Unit 8, 10 Hook St, Capalaba 4157 Australia Ph: +61 7 38235717 Fax: +61 7 38234717 Our Web Site: www.audiovisualdevices.com.au ___________________________________________ --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .