Killing Chips

Started by Mark Butcher February 6, 2006
Hi All

Just wondering whether any one knows whether it is possible to 
destroy HCS devices by incorrectly deleting Flash?

I have just built a board with the NE64 and I connected it to the 
debugger. I wanted to download a boot program but wasn't 
concentrating much - I had seen that the FLASH was not completely 
blank (I assume it can have a bit of garbage in it when a chip is 
fresh from the bag). As I said, without thinking I sent a couple of 
commands to delete the FLASH.
To be exact:
- a write to a FLASH location (any location to prime delete)
- CMD_FLASH_ERASE to FCMD     (prepare erase command)
- CBEIF to FSTAT              (start erase command)

I forgot to set up the Flash clock divide to produce a clock of 
between 150k and 200k...

Afterwards nothing worked and the board, which was originally 
consuming a few milli-amperes was taking about 400mA and the NE64 
was getting rather hot.

Not concentrating entirely, I don't know exactly whether it all 
happened when I sent the above command sequence or not but it seems 
quite likely.

Anyone also managed to produce such destruction? In any case it 
looks as though I'll have to solder a new one in tomorrow but I 
don't want to see whether I can repeat what happend.

So any one with similar experience?

Cheers

Mark Butcher
www.mjbc.ch
	
Hi Mark.
Do you still have a BDM access?
If not, do you try to mass erase and unsecure the chip?
Regards,
Gilles
	At 01:27 AM 2/7/2006, you wrote:
>Hi All
>
>Just wondering whether any one knows whether it is possible to
>destroy HCS devices by incorrectly deleting Flash?
>
>I have just built a board with the NE64 and I connected it to the
>debugger. I wanted to download a boot program but wasn't
>concentrating much - I had seen that the FLASH was not completely
>blank (I assume it can have a bit of garbage in it when a chip is
>fresh from the bag). As I said, without thinking I sent a couple of
>commands to delete the FLASH.
>To be exact:
>- a write to a FLASH location (any location to prime delete)
>- CMD_FLASH_ERASE to FCMD     (prepare erase command)
>- CBEIF to FSTAT              (start erase command)
>
>I forgot to set up the Flash clock divide to produce a clock of
>between 150k and 200k...
>
>Afterwards nothing worked and the board, which was originally
>consuming a few milli-amperes was taking about 400mA and the NE64
>was getting rather hot.
>
>Not concentrating entirely, I don't know exactly whether it all
>happened when I sent the above command sequence or not but it seems
>quite likely.
>
>Anyone also managed to produce such destruction? In any case it
>looks as though I'll have to solder a new one in tomorrow but I
>don't want to see whether I can repeat what happend.
>
>So any one with similar experience?
>
>Cheers
>
>Mark Butcher
>www.mjbc.ch
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
	
Hi Mark,

The timebase is the the reference of the internal charge pump for the
Flash array. It generates the high voltage needed for programming/erasing.
If the voltage is too low, you risk bit flip as not enough charges
will be captured in the floating gate.
If the voltage is too high, you do overprogramming and are stressing
the floating gate. This accelerated the natural destruction because of
the migrating charges becoming lazy.

In my humble opinion, even if you can recover this MCU, it should go
directly to the recycling bin !
Otherwise, you can potentially have trouble updating your software
later... Not worth the risk, is it ?

I've seen a nice App Note on FSL web explaining how these Flash cells
are working.

Cheers,
Alban Rampon.

--- In 68HC12@68HC..., "Mark Butcher" <M_J_Butcher@...> wrote:
>
> Hi All
> 
> Just wondering whether any one knows whether it is possible to 
> destroy HCS devices by incorrectly deleting Flash?
> 
> I have just built a board with the NE64 and I connected it to the 
> debugger. I wanted to download a boot program but wasn't 
> concentrating much - I had seen that the FLASH was not completely 
> blank (I assume it can have a bit of garbage in it when a chip is 
> fresh from the bag). As I said, without thinking I sent a couple of 
> commands to delete the FLASH.
> To be exact:
> - a write to a FLASH location (any location to prime delete)
> - CMD_FLASH_ERASE to FCMD     (prepare erase command)
> - CBEIF to FSTAT              (start erase command)
> 
> I forgot to set up the Flash clock divide to produce a clock of 
> between 150k and 200k...
> 
> Afterwards nothing worked and the board, which was originally 
> consuming a few milli-amperes was taking about 400mA and the NE64 
> was getting rather hot.
> 
> Not concentrating entirely, I don't know exactly whether it all 
> happened when I sent the above command sequence or not but it seems 
> quite likely.
> 
> Anyone also managed to produce such destruction? In any case it 
> looks as though I'll have to solder a new one in tomorrow but I 
> don't want to see whether I can repeat what happend.
> 
> So any one with similar experience?
> 
> Cheers
> 
> Mark Butcher
> www.mjbc.ch
>
	
Hi Gilles

BDM didn't work any more. Conclusion - "dead as a door nail".
Soldered in a new chip and it's working again.

I will be more careful and see about building in some software 
protection (simply checking that the clock has been set up correctly 
before zapping).

Cheers

Mark
www.mjbc.ch

--- In 68HC12@68HC..., Gilles Blanquin <gilles.blanquin@...> 
wrote:
>
> Hi Mark.
> Do you still have a BDM access?
> If not, do you try to mass erase and unsecure the chip?
> Regards,
> Gilles
> 
> 
> 
> At 01:27 AM 2/7/2006, you wrote:
> >Hi All
> >
> >Just wondering whether any one knows whether it is possible to
> >destroy HCS devices by incorrectly deleting Flash?
> >
> >I have just built a board with the NE64 and I connected it to the
> >debugger. I wanted to download a boot program but wasn't
> >concentrating much - I had seen that the FLASH was not completely
> >blank (I assume it can have a bit of garbage in it when a chip is
> >fresh from the bag). As I said, without thinking I sent a couple 
of
> >commands to delete the FLASH.
> >To be exact:
> >- a write to a FLASH location (any location to prime delete)
> >- CMD_FLASH_ERASE to FCMD     (prepare erase command)
> >- CBEIF to FSTAT              (start erase command)
> >
> >I forgot to set up the Flash clock divide to produce a clock of
> >between 150k and 200k...
> >
> >Afterwards nothing worked and the board, which was originally
> >consuming a few milli-amperes was taking about 400mA and the NE64
> >was getting rather hot.
> >
> >Not concentrating entirely, I don't know exactly whether it all
> >happened when I sent the above command sequence or not but it 
seems
> >quite likely.
> >
> >Anyone also managed to produce such destruction? In any case it
> >looks as though I'll have to solder a new one in tomorrow but I
> >don't want to see whether I can repeat what happend.
> >
> >So any one with similar experience?
> >
> >Cheers
> >
> >Mark Butcher
> >www.mjbc.ch
> >
> >
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> >
>
	
> I will be more careful and see about building in some software 
> protection (simply checking that the clock has
been set up correctly 
> before zapping).

As I understand, HCS12 FLASH has such a protection - if clock divider is 
not set, FLASH erase/pgm attempt fails with error flag set ?

-- 
Michal Konieczny
mk@mk@....

On Tue, 07 Feb 2006 17:34:33 +0100, Michal Konieczny
<0xmk@0xmk...>  
wrote:

>
> As I understand, HCS12 FLASH has such a protection - if clock divider is
> not set, FLASH erase/pgm attempt fails with error flag set ?
>

Yes, I think that's the case, but there is no protection against wrong  
settings :-(

-------------------------------
Dipl.Ing. J.Krummsdorf
Sttelner Strasse 30
04416 Markkleeberg,Germany
-------------------------------
WEB : www.krummsdorf.de/hc12icd/
--------------------------------
email: info@info...
--
	
>>As I understand, HCS12 FLASH has such a protection - if clock
divider is
>>not set, FLASH erase/pgm attempt fails with
error flag set ?
> 
> Yes, I think that's the case, but there is no protection against wrong  
> settings :-(

Yes, but Mark said that he forgot to set the divider, and something 
about adding check in software to see if the divider is set prior to 
programming. That check does HCS12 itself, so it's redundant.
You can't kill the part with the divider not set. I tried that many 
times during writing my programming software. Wrong divider value is 
completely different matter.

-- 
Michal Konieczny
mk@mk@....

--- In 68HC12@68HC..., Michal Konieczny <0xmk@...> wrote:
> Yes, but Mark said that he forgot to set the
divider, and something 
> about adding check in software to see if the divider is set prior to 
> programming. That check does HCS12 itself, so it's redundant.
> You can't kill the part with the divider not set. I tried that many 
> times during writing my programming software. Wrong divider value is 
> completely different matter.
> 
> -- 
> Michal Konieczny
> mk@...
>

I don't know of such a check, what specifically?
I only know of checking that the chrystal frequency isn't practically
stopping, not the same thing.
	
 >> That check does HCS12 itself, so it's redundant.
> 
> I don't know of such a check, what specifically?

See FDIVLD bit in FCLKDIV register, and reason number one for setting 
ACCERR flag during command write sequence: if FCLKDIV is not set, then 
any FLASH command will fail with ACCERR bit set.

-- 
Michal Konieczny
mk@mk@....

--- In 68HC12@68HC..., Michal Konieczny <0xmk@...> wrote:
>
>  >> That check does HCS12 itself, so it's redundant.
> > 
> > I don't know of such a check, what specifically?
> 
> See FDIVLD bit in FCLKDIV register, and reason number one for setting 
> ACCERR flag during command write sequence: if FCLKDIV is not set, then 
> any FLASH command will fail with ACCERR bit set.
> 
> -- 
> Michal Konieczny
> mk@...

Oh I forgot you meant FDIVLD. I thought you were talking about
something to do with the clock being too fast or too slow. AFAIK, it
wouldn't have allowed the MCU to be damaged except FCLKDIV was set to
something. It was just set to the wrong value for the current clk speed.