At 19.04 2008.05.21, Herbert Graf wrote:
>On Wed, 2008-05-21 at 19:47 +0100, Electron wrote:
>> At 18.26 2008.05.21, M. Adam Davis wrote:
>> >I haven't dug into you rparticular application, but the ICD2 protocol
>> >does depend, in some part, on the chip's oscillator.
>> >
>> >You should be able to disable the ICD2 as a debugger, enable it as a
>> >programmer, and then do a mass erase on the chip.
>> 
>> I wasn't using it as debugger, but as programmer!
>
>Have you tried a bulk erase?

Of course I tried everything that was possible, I'm not totally stupid. ;)

The ICD2 won't even *connect*.

Anyhow, I solved it. How? I thought, since communication is lost after the
0x42 write to OSCCONL, I thought I had to held the dsPIC reset at power
up (so that the damn instruction didn't execute), and then connect via ICD2.
Unfortunately, I have disabled MCLR, so I had to find other means to keep
the baby reset. If I didn't use an internal clock source, then I could just
shortcircuit the XTAL, but unfortunately I was using an internal clock source
(you see I'm lucky!). Actually, I found my way though: I played with voltages,
and found a small range where the CPU didn't run, but the ICSP worked at a
minimum. Once issued the bulk erase command, I tried then to increase the
voltage, but it didn't work. However, programming new code worked. Then
I got the chip free again! First thing I did was a bulk erase (and to change
that line from my sourcecode of course!) I had to redo the experiment though,
I was too curious. Again, 0x42 to OSCCONL and the chip is locked again! (but
working with its program running). I wasted another good amount of time to
get the CPU held reset at startup, and then the dsPIC was freed again! I have
had enough of it anyway.

It would be interesting to know if this affects only 30F5011 A1 or other
dsPIC's as well. It was pretty annoying, I lost many useful hours and now
I've to do other stuff, goodbye dsPIC programming till the next free time.

It could be useful also as an additional form of protection (turn a FLASH
chip into a ROM one!), although the clock divider should be compensated
anyway.

Cheers,
Mario


>
>TTYL
>-- 
>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