Damn, that should have been
(with "normal" EXTERNAL MCLR)
of course !

My guess is that this can be seen if
using *internal* MCLR...

Sorry...
Jan-Erik.

Jan-Erik Soderholm wrote:
> B.t.w, are you using "internal-MCLR" ?
> Or how can the application interfere with the
> programming ? Normaly (with "normal" internal MCLR)
> the processor is held in reset-state until
> Vpp is applied, so the code never runs...
> 
> Jan-Erik.
> 
> Peter Todd wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On Tue, Jun 12, 2007 at 04:12:08PM +0100, Alan B. Pearce wrote:
>>>> Also if I wait a day, burning works fine again,
>>>> for about twenty or so burns.
>>> This strikes me as a problem with LV programming bit being set, and the PGM 
>>> pin not being held in the correct state.
>>>
>>> What programmer are you using? I seem to remember someone recently having a 
>>> problem where they found their programmer was illegally changing some bits 
>>> in the config word from what was specified, and doing something like this. 
>> The problem appears with both a PICStart+ clone and a PICKit2...
>>
>> That said, sure enough I found it. Turns out the errata was applicable,
>> namely that switching to the internal oscillator to 8mhz too soon
>> actually causes the oscillator to overshoot, resulting in an out of spec
>> condition. This didn't seem to affect my app at all, but it did cause
>> programming to fail. Adding a half second delay at the very top of the
>> program fixed the issue. Anything I did after the oscillator switch had
>> no effect, for instance an infinit loop directly after the switch to
>> 8mhz still failed, which the same infinit loop, with a five second delay
>> before the switch worked fine.
>>
>> What's really weird is it took a good 6 months of on and off development
>> to even run into the problem. Yet I the code to switch to 8mhz was in
>> there from the very start, and indeed was copied from another 16lf819
>> using project.
>>
>> Even weirder though was I was trying some months old firmware versions
>> out, that now suddenly, and reliably, have the problem! It's like
>> running into it once in a day causes the programmer, even after being
>> turned off, to trigger it even with firmware that previously worked
>> fine. All the time I was using the same three 16lf819's, and my "clean"
>> ones that I could reproduce the problem with too were all from the same
>> rail.
>>
>> Embedded programming is downright wacky!
>>
>> - -- 
>> http://petertodd.org
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.6 (GNU/Linux)
>>
>> iD8DBQFGbr9/3bMhDbI9xWQRAhXnAJsHZ4VfM7f6uhlVEX10MgfN5bTdcQCeIU2X
>> ONZulV9nocMffezKudAZjzc=
>> =jBtE
>> -----END PGP SIGNATURE-----
> 

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