On 25/11/2010 07:08, David Duffy (AVD) wrote:
> ivp wrote:
>>> The PIC has a 10K resistor from MCLR to Vdd, but no capacitor
>>> to Vss. If I reset it by shorting to Vss, the unit works fine again.
>>> It's only when the board is first powered up that the fault occurs
>>>
>> If you change nothing else, a cap would ensure that Vdd gets up
>> before /mclr, holding the chip in reset. However, PWRTE is meant
>> to perform that task
>>
> Only had time for two tests today.
>
> The first was to add a 100n capacitor (also tried 10n&  1u) to the MCLR
> line. Faulty unit still does not function correctly when powered-up. If
> I shorted that cap (pulled MCLR low) momentarily, it did start working
> correctly.
>
> The second test was to remove the 47u capacitor on the 5V rail. Same as
> above; still faulty operation on start-up.
>
> For kicks, I checked the markings on the PIC chip from a good and bad
> unit; they are from the same batch as far as I can tell.
>
> 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.
> David...
>

Ok, seems that the power rail rising as far as the PIC is concerned=20
makes no difference. As Joe pointed out, the power up timer should take=20
care of that anyway, and a 10K resistor with no cap on MCLR should be=20
fine - in fact in the ICD3 datasheet Microchip actually recommend=20
avoiding any capacitance on MCLR. The 47uF cap idea was just in case=20
inrush current was causing some issue like it can with USB (I don't know=20
what else is going on in your circuit)
Is there anything else in circuit that could be causing issues?=20
Something that powers up separately and might be driving the PIC pins?
With the fact that changing the PIC worked with the other board, then it=20
seems like either a faulty PIC (unlikely on both boards but possible) or=20
a design issue causing borderline tolerances that could show up with=20
different conditions/components.
Just seen Joe's post - simplifying the circuit connections to the PIC=20
would be a good idea to help debug, start off with nothing (or as near=20
as possible) then add stuff till the problem appears (assuming it=20
actually goes away - if not then it would look like a faulty PIC being=20
the problem)  If physically disconnecting is difficult - can you power=20
down the receiver until you have turned on the power to the PIC?
Also, maybe try resetting the UART (clearing the overflow flag etc)=20
after a delay in your startup routine to see whether there is a problem=20
with data arriving too early.



--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.