So I got tired of constantly popping the F84 out of its socket and into the
programmer, and decided to make an ICSP header on my test board, and rig a
cable to the programmer (the ITU PIC-1).
The problem I've run into is the oscillator. While the programmer is doing
its thing, it is supplying +5 to the F84, and the rest of the circuit,
which makes the oscillator do its thing, and thus the programming fails.
If I pop the oscillator out before programming, everything works fine.
Any suggestions on an easy (automatic) method to cut out the oscillator
while programming?
>The problem I've run into is the oscillator. While the programmer is doing
>its thing, it is supplying +5 to the F84, and the rest of the circuit,
>which makes the oscillator do its thing, and thus the programming fails.
Have a loop-back connector that grounds the oscillator (OSC1 pin) when the
programming jack is connected.
Andy
==================================================================
Andy Kunz - Statistical Research, Inc. - Westfield, New Jersey USA
==================================================================
>>The problem I've run into is the oscillator. While the programmer is doing
>>its thing, it is supplying +5 to the F84, and the rest of the circuit,
>>which makes the oscillator do its thing, and thus the programming fails.
>
>Have a loop-back connector that grounds the oscillator (OSC1 pin) when the
>programming jack is connected.
This is interesting. Our F84 system does not halt the clock, and so far we
have a 100% success rate. 8 mhz clock, FWIW
We did hit a snag early on, in that the cable used in normal operation plugs
into the same connector, and serial input (soft uart) was causing the uP
clock to halt for 200-300uS. This was traced to capacitive coupling in the
cable, combined with the diode on MCLR taking the MCLR voltage above 5V.
Our current "operating" cables have that conductor missing :)
I would have done it differently, but the modular connector is already the
largest component on the board, and another connector was NOT an option.
> So I got tired of constantly popping the F84 out of its socket and into the
> programmer, and decided to make an ICSP header on my test board, and rig a
> cable to the programmer (the ITU PIC-1).
>
> The problem I've run into is the oscillator. While the programmer is doing
> its thing, it is supplying +5 to the F84, and the rest of the circuit,
> which makes the oscillator do its thing, and thus the programming fails.
>
> If I pop the oscillator out before programming, everything works fine.
Am I very wrong if I don't see the problem?
I don't know how your programmer works, but mine (one of these self
constructed & programmed prototype programmers) takes absolute control of the
MCLR voltage. In programming mode the voltage can be 0V or 13V, the same in
one of my big projects with ICSP abilities. I do this by setting a jumper from
running to programming position.
The newest programming spec for the PIC16F84 says: "The OSC must not have 72
osc clocks while the device MCLR is between VIL and VIHH." At my programming
method this never happens.
I think you use this little "typical in-system serial programming connection"
shown in the PIC databook which I found to be a bit too simple...
I can also imagine an ICSP connector on which you normally plug a jumper to
connect the MCLR pin to the normal reset circuit. While programming you pull
this jumper and connect the programming cable.
Hope it helped
Florian
ps: never programmed a PIC16F(!)84, only PIC16C84s because I haven't run out
of them yet.
> Am I very wrong if I don't see the problem?
> I don't know how your programmer works, but mine (one of these self
> constructed & programmed prototype programmers) takes absolute control of the
> MCLR voltage.
Well, it's not the MCLR voltage that's causing the problem. It's Vdd, at 5
volts, that is powering the oscillator.
On Fri, 1 May 1998 02:28:54 GMT Jon Hylands <Jonspam_OUTHUV.COM> writes:
>Well, it's not the MCLR voltage that's causing the problem. It's Vdd,
>at =
>5
>volts, that is powering the oscillator.
The problem is that MCLR doesn't rise fast enough. If the oscillator is
running or external clock applied, MCLR can't stay in the "normal
operating" range (high enough to bring PIC out of reset, but too low to
enter programming mode) for too long. If the PIC does enter programming
mode in time, it will ignore further oscillator inputs. The
specification is 72 osc clocks (or, if the clock is very slow or stopped,
8 ms). 72 osc clocks are 18 us at 4 MHz. This could be difficult to
achieve if there are capacitors connected to MCLR.
_____________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]
Your problem is probably that the reset voltage rises too slow. The
required rise time is specified as the maximum number of elapsed clock
cycles, so removing the Xtal helps, but it does not address the real
problem. I've had this with my own programmer.
regards,
Wouter.
----------
> From: Jon Hylands <@spam@JonKILLspamHUV.COM>
> To: KILLspamPICLISTKILLspamMITVMA.MIT.EDU
> Subject: More 16F84 ICSP... (for real this time)
> Date: Thursday, April 30, 1998 15:29
>
> Hi all,
>
> So I got tired of constantly popping the F84 out of its socket and into
the
> programmer, and decided to make an ICSP header on my test board, and rig
a
> cable to the programmer (the ITU PIC-1).
>
> The problem I've run into is the oscillator. While the programmer is
doing {Quote hidden}
> its thing, it is supplying +5 to the F84, and the rest of the circuit,
> which makes the oscillator do its thing, and thus the programming fails.
>
> If I pop the oscillator out before programming, everything works fine.
>
> Any suggestions on an easy (automatic) method to cut out the oscillator
> while programming?
>
> Later,
> Jon
>
> --------------------------------------------------------------
> Jon Hylands RemoveMEJonTakeThisOuThuv.comhttp://www.huv.com/jon
>
> Project: Micro Seeker (Micro Autonomous Underwater Vehicle)
> http://www.huv.com
huv.com http://www.huv.com/jon
