Flash Erase problem from the bootloader !

[svetozaryamakov]

Hello Everyone,

I am making a product using S12D64 and for ddevelopmenttool I am using USB Multilink with CodeWarrior. After a few years of successful experience and product realization

I decided to add a serial bootloader. But I am suffering serious Flash Erase problem and couldn't solve it. After I made MASS ERASE from the boatloader the S12D64 became totally unrecognisable by the USB Multilink. After I made 2 IC useless, I try alternative solution with SECTOR ERASE. I successfully erased and programmed a few sectors and after that gradually increased erasing flash areas. I erased memory area $4000-$7FFF and after that IC was recognizable, I erased additionally a few sectors from area above $C000 and again the IC was recognizable. But when I erased the whole page $C000-$FFFF the IC became unrecognisable again.

Can someone has any idea what I am making wrong and how to fix it?

[kef2 · Accepted solution]

It must be chip security. Erased state of flash is all ones. FSEC register is loaded at reset from NVSEC location at 0xFF0F. All ones in FSEC makes chip secured. Engaged security prevents memory reads over BDM. Just download unsecure_12 utility from pemicro.com. It should revive your "dead" chips.

[svetozaryamakov]

Thank you Edward,

Yes that was the problem, but initially I was fooled by the Unsecure command in CodeWarrior Debugger, which fails to work. The unsecure_12  from pemicro.com did the job and now all my "dead" chips are live again. Thanks again.

[kef2]

Unsecure command in debugger uses unsecurexx.cmd scripts. Some of them are buggy. For example script for D64 has these lines:

ww 0x108 0xD000  // write to FADDR address register

ww 0x118 0x0400  // write to EADDR eeprom address register

FADDR and EADDR registers are FLASH/EEPROM internal word addresses. 0xD000 would mean 0xD000*2= 0x1A000'th byte of flash memory array. That's over 100k of memory, while D64 has only 64k. The same for EADDR setting. Try changing FADDR and EADDR settings to 0.

Another problem is automatic BDM clock detection. P&E debugger seems not using BDM SYNC to detect bus clock and tries to read some detection patterns from memory. It works well on unsecured parts, but it usually fails on secured parts. So to use unsecure scripts, you need to verify that auto clock detection is turned on and that proper delay count is specified in Connect dialog.