| Author |
Message |
Roy Rutten
Guest
|
 Posted:
Wed Nov 30, 2005 5:15 pm Post subject:
HC08 monitor mode, security problem |
|
|
Hi,
I would like to program FLASH memory of a HC908AZ60 controller via the
monitor function of the controller. Reading/writing RAM works fine. However,
bypassing the security so that I can write FLASH does not seem to work in
any way. I tried 8 x $00 as well as 8 x $FF. Also, applying a RESET after
entering monitor mode and then trying to bypass securtiy doesn't seem to
have any effect.
The controllers I use are new, so I assume the security bytes are $00 or
$FF. If this is not the case, is there a way to reset these security bytes ?
Thanks a lot.
Regards,
Roy |
|
| Back to top |
|
 |
Grzegorz Mazur
Guest
|
| Posted:
Wed Nov 30, 2005 5:15 pm Post subject:
Re: HC08 monitor mode, security problem |
|
|
Roy Rutten wrote:
| Quote: | Hi,
I would like to program FLASH memory of a HC908AZ60 controller via the
monitor function of the controller. Reading/writing RAM works fine. However,
bypassing the security so that I can write FLASH does not seem to work in
any way. I tried 8 x $00 as well as 8 x $FF. Also, applying a RESET after
entering monitor mode and then trying to bypass securtiy doesn't seem to
have any effect.
The controllers I use are new, so I assume the security bytes are $00 or
$FF. If this is not the case, is there a way to reset these security bytes ?
|
There is no need for security bytes when you use high-voltage monitor
mode entry. Simply tick "ignore security feature" in the dialog used to
start the communication.
Also, read the messages displayed during monitor initialization. Most of
error conditions are described there. |
|
| Back to top |
|
|
Simon Clubley
Guest
|
| Posted:
Thu Dec 01, 2005 12:10 am Post subject:
Re: HC08 monitor mode, security problem |
|
|
In article <438dbaf3$0$11074$e4fe514c@news.xs4all.nl>, "Roy Rutten" <roy.rutten.remove.this@xarmac.nl> writes:
| Quote: | Hi,
I would like to program FLASH memory of a HC908AZ60 controller via the
monitor function of the controller. Reading/writing RAM works fine. However,
bypassing the security so that I can write FLASH does not seem to work in
any way. I tried 8 x $00 as well as 8 x $FF. Also, applying a RESET after
entering monitor mode and then trying to bypass securtiy doesn't seem to
have any effect.
The controllers I use are new, so I assume the security bytes are $00 or
$FF. If this is not the case, is there a way to reset these security bytes ?
|
On other members of the HC908 family that I use, you enter monitor mode after
failing security, and can load and execute a mass erase program from RAM
which resets the security code back to all $FF's.
However, since you say that these microcontrollers are new, the security
sequence should be $FF in all locations. This prompts me to ask if you are
using a Motorola supplied programmer or have built your own circuit and
programmer ?
If you are using your own programmer, I would check to make sure that your
programmer really is sending the correct sequence.
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
If Google's motto is "do no evil", then how did we get Google Groups 2 ? |
|
| Back to top |
|
|
Roy Rutten
Guest
|
| Posted:
Thu Dec 01, 2005 3:50 pm Post subject:
Re: HC08 monitor mode, security problem |
|
|
Thanks Simon for your response.
| Quote: | Hi,
I would like to program FLASH memory of a HC908AZ60 controller via the
monitor function of the controller. Reading/writing RAM works fine.
However,
bypassing the security so that I can write FLASH does not seem to work in
any way. I tried 8 x $00 as well as 8 x $FF. Also, applying a RESET after
entering monitor mode and then trying to bypass securtiy doesn't seem to
have any effect.
The controllers I use are new, so I assume the security bytes are $00 or
$FF. If this is not the case, is there a way to reset these security
bytes ?
On other members of the HC908 family that I use, you enter monitor mode
after
failing security, and can load and execute a mass erase program from RAM
which resets the security code back to all $FF's.
|
I used P&E's prog08sz to clear the entire module (according to the help
file, including the security bytes). It provides the necessary flash
programming routines for the AZ60. It seems to do this without any errors.
However, I still can't bypass security after doing this.
| Quote: | However, since you say that these microcontrollers are new, the security
sequence should be $FF in all locations. This prompts me to ask if you are
using a Motorola supplied programmer or have built your own circuit and
programmer ?
If you are using your own programmer, I would check to make sure that your
programmer really is sending the correct sequence.
|
We use our own test board, but the monitor part is according to the AZ60
manual. Programming and accessing RAM works fine. So I would say, monitor
mode is active and baudrates are correct. Also, we used the scope to see
what was really being send, this appeared to be OK.
Furthermore, we tested several HC908 controllers, they respond all in the
same way however.
Roy |
|
| Back to top |
|
|
Rafael Deliano
Guest
|
| Posted:
Thu Dec 01, 2005 5:15 pm Post subject:
Re: HC08 monitor mode, security problem |
|
|
| Quote: | P&E's prog08sz
However, I still can't bypass security after doing this.
Configuration in the P&E software is correctly set ? |
Baudrate is normally not a problem ( assuming the AZ60 has the
correct quartz and not a slightly-off clock )
"Target Hardware Type" has 8 options, some ( "Power controlled via
DTR" ) want hardware handshakes.
"Target MCU Security bytes" has to be set to the expected
security string. For a blank device usually all FF.
Assuming the security-string fails: you bypass it and
mass-erase the chip. The P&E will set
his reference for the security-string in RAM ( or on disk )
to FF automatically.
Assuming you program via P&E the FLASH including the
vector-area where the security bytes are: the P&E
will copy that pattern to his reference set in "Target MCU Security
bytes".
Trouble will be accessing a programmed controller: one has
to enter the string in "Target MCU Security bytes" if necessary
manualy or select it if its already there.
MfG JRD |
|
| Back to top |
|
|
Simon Clubley
Guest
|
| Posted:
Thu Dec 01, 2005 5:15 pm Post subject:
Re: HC08 monitor mode, security problem |
|
|
In article <438ec76e$0$11072$e4fe514c@news.xs4all.nl>, "Roy Rutten" <roy.rutten.remove.this@xarmac.nl> writes:
| Quote: |
We use our own test board, but the monitor part is according to the AZ60
manual. Programming and accessing RAM works fine. So I would say, monitor
mode is active and baudrates are correct. Also, we used the scope to see
what was really being send, this appeared to be OK.
|
Using a scope seems to clinch that the correct sequence is been sent.
Although I picked up on the fact that you had actually entered monitor mode
with failed security, I had at the back of my mind the possibility that some
of the security sequence may not be making it to the AZ60 intact as I had
various weird failures when I first did my programming board.
I note that there is a AZ60 and AZ60A variant. Have you checked to see which
one you are actually using and if there is a programming difference between
the 2 variants ?
The only other suggestion that I can make is to try downloading the Special
Edition version of CodeWarrior from
http://www.metrowerks.com/MW/Develop/Embedded/HC08/Default.htm
which is available free of charge and try using that with your board.
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
If Google's motto is "do no wrong", then how did we get Google Groups 2 ? |
|
| Back to top |
|
|
Roy Rutten
Guest
|
| Posted:
Fri Dec 02, 2005 4:25 pm Post subject:
Re: HC08 monitor mode, security problem |
|
|
| Quote: | We use our own test board, but the monitor part is according to the AZ60
manual. Programming and accessing RAM works fine. So I would say, monitor
mode is active and baudrates are correct. Also, we used the scope to see
what was really being send, this appeared to be OK.
Using a scope seems to clinch that the correct sequence is been sent.
Although I picked up on the fact that you had actually entered monitor
mode
with failed security, I had at the back of my mind the possibility that
some
of the security sequence may not be making it to the AZ60 intact as I had
various weird failures when I first did my programming board.
I note that there is a AZ60 and AZ60A variant. Have you checked to see
which
one you are actually using and if there is a programming difference
between
the 2 variants ?
|
We use the AZ60. I checked, programming via monitor mode is the same for the
AZ60 and the AZ60A.
Thanks for the link ... didn't know it was free of charge. We already use
Codwarrior, but this version is about 4 years old already. However, both the
old version and the new version did not succeed in bypassing the security.
Strange ...
Regards,
Roy |
|
| Back to top |
|
|
Guest
|
| Posted:
Fri Dec 02, 2005 5:15 pm Post subject:
Re: HC08 monitor mode, security problem |
|
|
Hi,
One significant inconvenience I found when working with the HC908
family is that if there are any errors in establishing a connection a
complete reset is required including removing power - just pulling
reset low is not enough. The power must be brought down to a few
hundred millivolts or the next attempt will not succeed.
This is documented and is part of the security measures.
On one low power project I temporarily put a low value resistor across
the power so that I could reset in a reasonable time.
kevin |
|
| Back to top |
|
|
Roy Rutten
Guest
|
| Posted:
Fri Dec 02, 2005 5:15 pm Post subject:
Re: HC08 monitor mode, security problem |
|
|
| Quote: | We use the AZ60. I checked, programming via monitor mode is the same for
the
AZ60 and the AZ60A.
If the programmer treats them as the same device, then the routine that is
loaded into the AZ60's RAM to do the mass erase must detect if it's
running
on a AZ60 or a AZ60A because looking at the datasheets/application notes
shows that various registers such as the FL1CR/FL2CR are located at
different
addresses on the 2 variants.
|
You are right, there are some differences in the area of mass erasing. But
what I ment with programming via monitor mode above was using the basic
commands suchs as Read, Write, IRead, IWrite, ReadSP, Run.
| Quote: | My only other suggestions are:
1) What are you actually getting back from the EPROM area when you try to
read it ? On the variants that I use, you get $AD back when you fail
security.
|
That's right, I read $AD's from de FLASH/EPROM area.
| Quote: | 2) You could always write a little mass erase routine of your own in
assembly
language using the algorithm in the datasheet and load/execute that from
RAM
if your programmer will let you do that.
3) Does your programmer do a verify pass on the mass erase/programming
code it's loaded into the AZ60's RAM before it has the monitor execute it
?
I'm wondering if this code is getting corrupted during the loading
process.
|
I just got things working (a bit) ! I used P&E's Prog08sz to mass erase the
MCU. Appearantly it does this without any warnings or errors. What I've been
trying to do until now is to bypass security after mass erase, which does
not seem to work. However, after loading the flash-programming routines in
RAM (after mass erasing), programming of FLASH seems to be possible, even
without bypassing the security! I don't know if that is the regular way to
do it (must have been misreading a lot of things then ...) but anyway, I'm
not stuck anymore !
| Quote: | Other than that, are you sure that you haven't just got a faulty batch ?
|
Can't really tell ... I have tested some 15 or so MCU's from the same batch,
they all respond the same however.
Thanks for your help !
Regards,
Roy |
|
| Back to top |
|
|
Simon Clubley
Guest
|
| Posted:
Fri Dec 02, 2005 5:16 pm Post subject:
Re: HC08 monitor mode, security problem |
|
|
In article <43902110$0$11061$e4fe514c@news.xs4all.nl>, "Roy Rutten" <roy.rutten.remove.this@xarmac.nl> writes:
| Quote: |
We use the AZ60. I checked, programming via monitor mode is the same for the
AZ60 and the AZ60A.
|
If the programmer treats them as the same device, then the routine that is
loaded into the AZ60's RAM to do the mass erase must detect if it's running
on a AZ60 or a AZ60A because looking at the datasheets/application notes
shows that various registers such as the FL1CR/FL2CR are located at different
addresses on the 2 variants.
(I've written a Linux based programmer for a couple of HC908 devices, and in
order to keep things simple, I would probably have treated the variants as
different devices).
[Before anyone asks, the programmer would need a lot more work doing to
it before I could release it for general use so it's not available.]
Have a look at application note AN2215 for details of the differences between
the variants.
| Quote: |
Thanks for the link ... didn't know it was free of charge. We already use
Codwarrior, but this version is about 4 years old already. However, both the
old version and the new version did not succeed in bypassing the security.
|
Only the Special Edition is available for free.
My only other suggestions are:
1) What are you actually getting back from the EPROM area when you try to
read it ? On the variants that I use, you get $AD back when you fail security.
2) You could always write a little mass erase routine of your own in assembly
language using the algorithm in the datasheet and load/execute that from RAM
if your programmer will let you do that.
3) Does your programmer do a verify pass on the mass erase/programming
code it's loaded into the AZ60's RAM before it has the monitor execute it ?
I'm wondering if this code is getting corrupted during the loading process.
Other than that, are you sure that you haven't just got a faulty batch ?
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
If Google's motto is "do no wrong", then how did we get Google Groups 2 ? |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in