Attached is a stand-alone Flash programming utility for HCS08 devices.
I have tested it on a range of devices and I have found no (more) bugs. However, no guarantees are given!
the P&E USB BDM Multilink uses a completely different driver (probably proprietory to P&E), so you would have to find a similar flash utility from their website or build / buy a USBDM device to use pgo's programmers ...
Here is a list of sources for compatible hardware copied from pgo's documentation:
all the best,
Hi, I try to program a MC9S08AC60 with internal oscillator, when I try to program, a message says "Programing of the target flash failed! Reason: Failed to read from target", when I use Multilink dont have any problem, and codewarrior with usbdm also is ok, but when I try to use the flash programmer give me that error, the MC9S08AC60 is supported? thanks
Sorry I don't have a MC9S08AC60 to test so I can't guarantee it works. However I have tested USBDM with MC9S08A128 without problems and unless I've missed something the programming stuff appears similar.
When you use the stand-alone programmer and click the Detect Chip button is the the device detected and can you select the MC9S08AC60 device in the device drop-down box?
The link at http://opax.swin.edu.au/~3340694/USBDM/USBDM_Programmers/html/ discusses V2 of USBDM_Programmers. Have you posted the source code for V2 yet? I'm having trouble locating it. Thanks very much.
thank you again for another great utility!
The only problem I run into is that the stand-alone flashprogrammer seems not able to unsecure chips.Even using the reset line and cycling the target power doesn't succeed -- it gives an error that it can't communicate with the target.
In the Hiwave debugger when launched from Codewarrior 6.3 also one has to first explicitly choose the "Unsecure" command in the HCS08 Open Source BDM menu in order to be able to reprogram a target.
Is there some way to achieve this automatically when needed by modifying the command files, and how could one unsecure chips with the standalone utility (i.e., have the standalone utility do what the unsecure.cmd does from Hiwave) ?
Many thanks and best regards!
The programming utility should unsecure the chip without any special action required.
It really sounds like a connection problem rather than an unsecuring problem.
Can you provide the following information and I will try to figure out what is happening:
I found that it was my mistake : I was not correctly setting the Clock type and parameters!
The Flash Programmer is Version 1.0.3,
BDM firmware 2.0
BDM hardware is one I made myself with a JM60.
With a HCS08QE128 (SDID 0x1.015) or HCS08AC128 (SDID 0x0.01B) the SDID is read, but the device type is not recognized and so the Clock type is left on "External" which doesn't work. If I set it to S08ICSV3 it's ok for the QE128, and the AC128 uses S08ICGV4.
With a HCS08LG32 the device type is correctly set, so the clock is also configured automatically after clicking on "Detect SDID".
With the correct clock settings, all three work fine, even with a secured chip.
So, my apologies for taking your time...
When using the USBDM from Codewarrior 6.3 or 6.3.1 and Hiwave.exe with Open Source BDM dll v. 3.05, with a CF1 device a secure chip is automatically unsecured without any additional steps, but with the three HCS08 parts I tried one has to first manually select the "Unsecure..." command from the "HCS08 Open Source BDM" menu, otherwise one gets the error message "Error while loading diagnostic algorithm to target system. The chip may be secured or the derivative selected may be wrong."
But this is not a big deal, and it may be due some configuration setting I missed in the command files, but in case it's of any interest, I attach three gdi log files -- one of the failure when trying to program a secured device, one of the sucessful unsecure command, and one of the success programming of the unsecured device.
Many thanks for providing this great tool!
Glad that worked out but be aware that the published version of the programmer does not support paged devices (e.g. HCS08QE128). It may be able to program the default memory map but not any banked areas. This is the reason they were not in the configuration file and hence not automatically recognized. I also did not check the functionality at all. The next version will support banked devices.
The lack of automatic support for secured devices in the debugger is a limitation of the GDI dlls provided with Codewarrior and there is little that I can do to change this.
When released, the USBDM version for Codewarrior V10 (Eclipse) will erase secured devices automatically as it implements the GDI layer from scratch.
the programmer seems to do fine with the unbanked flash of the HCS08QE128 and HCS08AC128
With the HCS08LG32 it works for small programs, but when I try to flash around 20k bytes of code it loses contact and gives an error message: "Programming of hte target flash failed ! Failed to read from target."
Programming the same 20k byte code from Codewarrior 6.3 via Hiwave.exe with the same USBDM and target hardware connection works fine -- in fact it's about the same speed as the PEMicro USB BDM Multilink.
Probably most users will be working from within Codewarrior anyway.
Will your Eclipse USBDM also work with the Linux version of Codewarrior V10 ? That would be a whole other ballgame, with new USB drivers and all ...
I have an issue with the S08 Flash Programmer.
Right now I am working with a MC9S08SE8 and it sets the trim value so that I
get half the expected bus clock rate (4 MHz). I can get around the problem
by setting BDIV in ICSC2 to divide by one instead of the default value of
divide by two. The factory programmed value for NVICSTRIM was $6C; the
value programmed by S08 Flash Programmer is $BB. Do you have any insight
I've had a look at this and I can't see anywhere a factor of two could come in. It is only possible to trim the internal clock over a limited range. I don't think it would be possible to be out by a factor of 2. The values you give would not result in this large a change.
For the test chip I used the programmer gives the following results:
A value of 0xB7.0 for a trim frequency of 31.25kHz.
A trim value of 0x6C.1 results in a trim frequency of 39kHz.
According to the SE8 data sheet the factory trim value is for 39kHz which would agree with the latter of the above values and the value you gave for the factory value on your chip. Since the default trim for the USBDM programmer is 31.3 kHz I would not expect the value to be the same. I believe this indicates that the programer is finding the correct trim value.
Are you sure you are setting the DRS & DMX32 values correctly? Alternatively, If you want a 39kHz trim value select that in the programmer.
Let me know if I'm looking at this incorrectly.
PS. The above tests were done with the latest version available here:
DRS and DMX32 are at the reset values of 00
I just got the flash programmer for USBDM ( I use a Witztronics ). I have worked in the past with QG8, QE8, & SH8 versions. Just starting a project with the 9S08SE8. Before now I was using a version of AN2496 to set the trim. Quite tedious.
I set the flash programmer for 31.25kHz and get a value similar to what you got but the bus clock is 4 MHz not 8 MHz unless I change BDIV. My SCI and timer routines all expect 8 MHz. At first I though that the flash programmer was giving me totaly bogus trim values until I set my terminal program to 4800 baud instead of expected 9600 baud. Working perfect at slower baud rate. Changed BDIV from default of 1 to 0 ( divide by two to divide by one ) and everything works fine.
Did you check your bus clock when you set trim on SE8?
The job of calibrating the trim is to produce a value stored in flash that when applied will result in a particular internal oscillator frequency. This is mainly to allow for variation in the manufacturing process of this low-cost design. It can only be varied over a small range (< x2). What the bus frequency is is dependant on many other settings not expressly set in this process. If all of these settings are left at default then there will be a default trimmed frequency for a particular model. Is it possible you are confusing the CPU frequency and the buss frequency?
Hello pgo & Peg,
Yes I know the CPU frequency is twice the bus frequency.
Since my last message I took a different 9S08SE8 with a different production lot and programmed the trim with the tedious AN2496 method. With this method the trim value for this chip was $24 and the bus clock was 8 MHz with all default values for the Internal Clock Source. Everything was good except for the time it took to set up.
Then I used the S08 Flash Programmer to set the trim. It set to $C5 and the resulting bus clock was 4 MHz or exactly half what was desired. As I said in an eariler post I can get back to 8 MHz by changing BDIV in my application program but I don't really want to do this because I also want to use the serial bootloader for most of my development work.
One thought ..... this chip has Version 3 of ICS. Is there something about this latest version that we are missing?
It would be quite possible for me to have wrongly configured the clock in the programmer but I don't believe this would result in the situation you have described.
The SE8 automatically copies the factory trim to the clock trim reg (according to the manual anyway). If you don't do anything to the clock what is the default bus frequency you measure on the chip - I would expect this to be 5MHz?
After trimming to 32.25kHz and changing the BDIV to 0, I would then expect a bus clock of 8MHz from an ICSOUT clock freq. of 16MHz. This is what you have described but you seem to be expecting to achieve this with BDIV set to 1?
I really think there is something wrong with your AN2496 method - A trim value of $24 sounds too low. Consider that the factory value you gave earlier was $6C (for a factory trim of 39kHz) - A value of $24 would indicate that the internal clock is being trimmed to a very high frequency outside of the permitted range of operation (31.25 — 39.06 kHz).
Doe the AN2496 support trimming ICSV3?
AN2496 was written six years ago for an early member of the family the 9S08GB/GT which used the Internal Clock Generator which is quite different from the Internal Clock Source used in newer CPUs. Basically you repeatedly send the "@" character at 9600 baud to the 9S08 which uses the timer to measure the waveform. The time will be initally incorrect and the software adjusts the trim, ICSTRM, until the measured period is correct. Then it writes that value to NVICSTRIM at $FFAF. I had to rewrite the software considerably for the Internal Clock Source.
I have used this to set the trim on 9S08QG8, 9S08QE8, 9S08SH8 and now 9S08SE8. In all cases the Reference Manual states that the reset default of BDIV in register ICSC2 is 01 which divides the clock by two. I have used this with quite a few chips now and it works. It just is a bother and time consuming to set up.
Once again on this chip I got a bus clock of 8 MHz with a trim of $24 without changing default BDIV and I also got a bus clock of 8 MHz with a trim of $C5 and changing BDIV to 00 which divides the clock by one.
I believe you!
BUT I think that you are running the clock out of spec to achieve this. A Trim value of $24 is very low given the other numbers mentioned. The clock is certainly running at >39kHz considering that the factory trim value (for 39kHz) is $6C.
The whole reason the reset value of the BDIV is /2 is so that the bus frequency will never be out of spec even with an untrimmed clock. It is not intended that the maximum specced bus frequency is achievable with this setting.
Perhaps you could post a general clock trim question on the HCS08 discussion board to get some input on what is the typical trim value for this chip and what is the required set-up to achieve an 8MHz bus clock. We both might learn something
I decided to try your HCS08 Flash Programmer with some other chips. Here are my results:
9S08QG8 trim= $9D no change of BDIV to get 8 MHz bus
9S08QE8 trim= $A2 no change of BDIV to get 8 MHz bus
9S08SH8 trim= $BD no change of BDIV to get 8 MHz bus
9S08SE8 trim= $C5 BDIV must be changed to get 8 MHz bus
Most of my programs need a predictable bus clock so SPI and timers work properly. Suppose I want do a short production run of several dozen chips and they happen to be from different manufacturing lots. It looks like sometimes your program will give me a trim value whereby BDIV must be changed ..... and sometimes should not be changed. If that is the case then sometimes my application will work .... and somtimes it won't.
Could your program and least be changed so that a warning is given when the default values can't be used?