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 ?
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.
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.
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.
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
formatting link
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 ?
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.
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.
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 ?
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.
That's right, I read $AD's from de FLASH/EPROM area.
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 !
Can't really tell ... I have tested some 15 or so MCU's from the same batch, they all respond the same however.
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.