WARNING - Device is secure, Error 14 (HCS08)

[zenta]

Hello,

i have the following problem:

I connect to the target MC9S08LL16 by using hiwave.exe. After this, i try to load my software (test.abs).

The Debugger posts the notice, that the flash on the device is secure, erases the flash and requests another Reset. After this Error 14 will be posted.

You can see it in the pictures load_step1.jpg and load_step2.jpg 

I don't know, if this is a failure in the connection or by erasing the flash.

If i try to erase the flash by myself, FOPT will be still 0xC3 after reset.

(You can see my little try in picture "Flash Erase.jpg")

I would be very happy for any good advice,

thanks

regards

zenta

load_step1.jpg

load_step2.jpg

Flash_Erase.jpg

Message Edited by t.dowe on 2009-10-19 10:29 AM

[zenta]

...sorry...i think, i have forgotten to post my connection:

 I connect via USB Multilink Interface from P&E micro to MC9S08LL16 by using the specified 4 Pins. (Reset, BGND, GND, VDD)

The Driver has got the version: V9.02

[zenta]

We have new technical expertise:

When we get a new prototyp, the device MC9S08LL16 is totally blank, has never been programmed before. The Flash is filled with 0xFF.

The important Flash-Rgeister contains:

- FOPT = 0xC2

- FPROT = 0xF8, (0xFF)

- NVOPT = 0xFE

- NVPROT = 0xF8

By loading the programm code, the Hiwave-Debugger post, that the device is secure, erased the flash, and try to load the Programm algorithm of 9S08LL16.S8P. Error 14 occured.

After this the whole Flash from 0xC000 until 0xFFFF is filled with 0x00, even NVOPT, NVPROT.

FOPT is still 0xC3. Because of this no more Flash activity is possible. No more write to NV-Registers and so on.

[peg]

Hello zenta,

I am not sure what is happening here but the registers you have shown appear correct.

FOPT is $C2 which menas the device is unsecured.

FPROT is $F8 which is protected but the algorithm will write this to $FF to unsecure it.

A mass erase should always work no matter what the state of any registers.

[zenta]

Hi,

thank you for your replay peg.

The problem is solved finally, I hope...

Unfortunately it is a problem of the file 9S08LL16.S8P. There are more than one mistake inside. Was it ever tested?...sorry...

At first the command EM = Erase module, killed the device. Do not ask me why, this command kill it. Never use it.

At second, the SOPT1 (0x1802)  has to be written with 0x03 and not 0x02. If it is written by 0x02, he will do resets while programming the device.
9S08LL16.S8P, line 2: WRITE_BYTE=03/00001802/

To programm a blank MC9S08LL16 with Real-Time Debugger (Hiwave) and a USB-Multilink, you have to do the following things:
1.) Change the line 2 in 9S08LL16.S8P to "WRITE_BYTE=03/00001802/"
2.) Connect to the target
3.) Start "Start Expert Mode Programmer...". Now he will load the Programmalgorithmus out of 9S08LL16.S8P, (else choose CM)
4.) SS - Specify object file, choose your file to load (*.s19, *.abs, ...)
5.) PM - Programm Module
6.) (VC - Verify CRC Checksum)
7.) (PT - Program Trim Value)
8.) RE - Reset chip
I don't know, but if you use once the command EM - Erase Module, you will not be able to write to your device again. Because of this do not use the option "Load.." in the Real-Time Debugger (Hiwave) because this function includes the command EM.

Pherhaps this error/strange behaviour will be tested/examined by Freescale/Pemicro.....
Thanks a lot,

Regards
zenta

[peg]

Hello again zenta,

So your saying you have figured out how to get blank devices programmed, but, you can't programme then again because you can't use EM. Is this correct?

I thought I would do a little research into this and only got more confused.

The only algorithm for an LL16 that I have on my computer is 0.01 ALPHA 7/1/2007

This version writes 03 to SOPT1! What version do you have?

Then I thought, "the QG8 has a multi-purpose reset pin let's see what it does there"

version 1.01, 9/14/2005 writes 02 to SOPT1 which is the same as the LL's SOPT1

Then I thought let's have a look at the GT16A (one I am using right now)

version 1.02, 6/1/2005 writes 03 to SOPT which is the same as the other's SOPT1 except that bit 0 is unimplemented! (The GT16A has a dedicated reset pin)

I have seen this in the past where new algorithms are based on close derivatives and then there are errors where somethings have forgotten to be changed.

Hopefully someone else can shed some light on this for you.

[J2MEJediMaster]

The thing to do is get this problem officially recognized and worked on by the engineers. To do that, you can file a service request. Click here to do that. Under the first drop-down menu choice (Category), select "Technical Request."

---Tom

[zenta · Accepted solution]

Hello,

I am very sorry for making this long troubleshooting with very strange posts in this forum. It was fine to program the device, but I couldn't believe that the Erase Module function doesn't go.

And so... 

We are able to connect to our device, were able to load the programm algorithm, were able to program the module. But while you are trying to erase the device, the voltage falls below 1,8V because of a resistor (100 Ohm) agains shorts, which was connected in serie with battery. The Erase function cannot be executed correct, he fills the Flash with 0x00.

Without the resistor you can erase,program, erase again, program again...everything is fine.

Thank you for your patience,

Cheers

zenta

P.S. @Peg I am sorry for confusing you, 0x02 in 9S8LL16.S8P is correct. (date of file is 20.02.08) At the beginning of troubleshooting, there was a Pull-Up at Reset-Pin..grrrr..

[peg]

Hi zenta,

Glad you got it figured out.

I was doubting that enabling the reset pin was doing anything for you.

Enabling it does nothing for assisting in entering background debug mode as you need to be already in debug mode to issue the command to enable the pin (Catch-22)

It seems P&E use BDFR for subsequent resets and so do not need the reset pin enabled.