HC08GZ, Erase device problems

[Bloodhound]

Hi All,

This problem just started happening, not sure what caused it, but now when I try to erase / program the device using the Softec inDART in the Softec Dev board it fails.

With the Datablaze program I tell it to Mass Erase the part, it says it does it sucessfully, when I then do a blank check it fails. Unfortunately this stops programming too because it says the part is not blank.

If anyone is familiar with this software can they please give me any pointers as to what I might have done?

Edit: When I try to read the device it tells me the security bytes are set!, well, if they are, it wasn't done by me on purpose. Either way, the Mass Erase function I mention above should be clearing them.

Thanks,

Ross

Message Edited by Bloodhound on 2007-09-25 11:31 AM

[Bloodhound]

Well I am getting more and more confused.

The 908GZ Data sheet states:

"The mass erase operation clears the security code locations so that all eight security bytes become $FF (blank)." So surley I can rule that out?

The erase part I can do, it tells me the erase completed ok, I've scoped PTA0 and there is ineeded data activity so I am assuming the programmer is getting a valid message back from the CPU to say that everything was erased.

The very next step I do is a blank check to which it fails

That does not make sense unless the software is telling me a bogus erase ok message?

Cheers,

Ross

[peg]

Hi again Ross,

Again I am unsure about the Softec product, but you should be able to upload the flash, possibly to a s19 file which you can then examine to see if it is blank (all FF's) or where it is going wrong.

Are you advising the software of the correct family/derivative?

Are you gaining access to the device as if it were blank?

[Bloodhound]

Thanks Peg,

The only operation I can do is Erase (and it passes), any attempt to read, program, verify etc results in failure because it says the security bytes are set. This is a new HC08 out of the packet BTW.

Definately chosing the correct family type.

I must mention and I did forget eariler (sorry) that I can communicate with it in the development board fine, in the application board is where the problem is. So the problem may very well be in the target board. I don't know enough about the HC08 comms but I would have though if a device reports as erased then it truley is erased. And if there were a real comms issue then all operations would fail.

Thanks,

Ross

[peg]

Ah!, OK,

Then you need to check that you have the correct monitor mode entry conditions.

Refer to the table that you should find in the Development Support chapter of the datasheet. It is table 20-1 in my copy. For example you need PTA1 low, a 8MHz xtal and baudrate set to 7200 if it is indeed blank. More conditions are required otherwise. This is all taken care of for you on a development board.

[Bloodhound]

, it looks to be some quirk in the Softec programmer. All of a sudden it started doing the same thing on the development board.

Seems it works perfect (erasing and programming) on both development and end product PCB's if the following sequence is done -

1 - Plug USB port in to InDart interface.

2 - Power up device with CPU on board.

3 - Start software.

Any other sequence results in the same failures I've been having.

Hope this might help someone else who ever comes across this same problem.

Thanks,

Ross

[peg]

Hi,

If the interface pod does not control the power to the MPU then, yes, you probably do need to power the pod (with the USB cable?) before you power up the MPU.

To enter monitor mode the MPU must come up out of a POR with the correct monitor mode conditions present. With the pod unpowered these conditions may be undefined.

Maybe this is the actual problem?

[Bloodhound]

I am a little lost on this.

If the security bytes are required to erase / program the device does that mean once you program a device unless you have the original .s19 file with the unlock code then you can't do anything further? Surely not.

My issue is, that I tell the software to mass erase, it says it does, but then when I try to program it I am told it needs to be erased

Thanks,

Ross

[peg]

Hi Ross,

I don't know the details of how to do it with Softec product, but....

The security only needs to be sent/passed to gain access to a programmed chip to read/monitor/debug it. There should be a way to access the chip without security and then mass erase it.

With the P&E product you tick a box that says "IGNORE security failure and enter monitor mode". Once connected you can only mass erase. Now you can start again.

[Nabla69]

Hello Ross,

On the HC08, the security bytes are matching the Interrupt addresses.
Therefore, by using interrupts you are programming these security bytes.

To get the security key, just ask the programmer to extract the securit key from the S19 (S-Record) you used to program the part with.

See your device datasheet in Security part of the Development Support chapter:

20.3.2 Security
A security feature discourages unauthorized reading of FLASH locations while in monitor mode. The host can bypass the security feature at monitor mode entry by sending eight security bytes that match the bytes at locations $FFF6–$FFFD. Locations $FFF6–$FFFD contain user-defined data.
NOTE
Do not leave locations $FFF6–$FFFD blank. For security reasons, program locations $FFF6–$FFFD even if they are not used for vectors.

During monitor mode entry, the MCU waits after the power-on reset for the host to send the eight security bytes on pin PTA0. If the received bytes match those at locations $FFF6–$FFFD, the host bypasses the security feature and can read all FLASH locations and execute code from FLASH. Security remains bypassed until a power-on reset occurs. If the reset was not a power-on reset, security remains bypassed and security code entry is not required. See Figure 20-17.

This is page 312 of the GZ60 datasheeet, if you wish to read more.

Alberta