HCS08 Flash Programmer for USBDM

[pgo]

Dear All,

Attached is a stand-alone Flash programming utility for HCS08 devices.

Features

• Command line usage is available for batch files.
• GUI usage is available for interactive use.
• Supports most HCS08 chips (Paged memory is not supported).
• Trimming of internal target clock to specified frequency.
• Programming of security options to leave the chip unsecured or secured after programming.
• May be used to unsecure chips (by mass erase).
• The code has been written in a modular fashion. It should be straightforward to re-use the flash programming code to create other custom programming utilities.

I have tested it on a range of devices and I have found no (more) bugs.  However, no guarantees are given!

bye

1. Installation_1_0_3.zip

2. Source_1_0_3.zip

Message Edited by t.dowe on 2009-12-08 09:28 AM

[pgo]

Dear Roger,

For comparison I used the latest version of the BDM programmer to download compiled versions of the program below to the following chips:

SE8, trim value $B7.0

QG8, trim value $B3.1

The program can do 2 things - Produce a square wave at a cycle-counted speed (400kHz => 8MHz bus clock) or send a single character out the serial port.  Uncomment the testClockPeriod() line for the square wave.  This is similar to the program that I used to test the clock trimming on all the supported chips.

For both chips the square wave was at 399kHz as expected for a 8MHz bus clock.

I also measured the baud rate in each case to be 9600 baud.

The program sets the BDIV to 0 as I believe is required for 8MHz bus speed on these chips.

I'm at a loss why your results are different for these two chips.  They have the same type clock system and SCIs and the programmer-calculated trim values are similar as expected.  Why should the execution results differ?

Are you using the latest version programmer available as indicated above (This should be irrelevant since its the clock trim value that is the sticking point) ?

Does the programmer auto-detect the chip type correctly?

Could you try these two programs on your chips?

bye

#include <hidef.h>      /* for EnableInterrupts macro      */#include "derivative.h" /* include peripheral declarations */typedef unsigned char U8;#define PORTD  PTCD     // Test Port Data register#define PORTDD PTCDD    // Test Port Data Direction register#define LED1 (1<<1)     // Test pins#define LED2 (1<<0)// Clock Trim values in Flash - dummy values overwritten by flash programmerstatic const volatile U8 NV_FTRIM_INIT  @0x0000FFAE = 0xFF;  // LSBstatic const volatile U8 NV_ICSTRM_INIT @0x0000FFAF = 0xFF;  // MSBvoid initClock( void ) {   if (NV_ICSTRM_INIT != 0xFF) {     //  Only trim & update clock if Trim values have been programmed to Flash.     //  Enabling x1 clock divider on untrimmed device may be out of bus clock spec.     ICSSC       = NV_FTRIM_INIT;    // Trim the internal clock     ICSTRM      = NV_ICSTRM_INIT;     // Set 8/16 MHz bus clock assuming 31.25 MHz trim     ICSC2 = 0;                    // BDIV=0,RANGE=0,HGO=0,LP=0,EREFS=0,ERCLKEN=0,EREFSTEN=0     ICSC1 = ICSC1_IREFSTEN_MASK;  // CLKS=0,RDIV=0,IREFS=1,IRCLKEN=0,IREFSTEN=0   }}void testClockPeriod(void) {   PORTDD = LED1|LED2;  // Set as outputs   asm {     lda   #LED1  Loop:     // 10 bus cycles low     sta    PORTD             // 3     eor    #LED1|LED2;       // 2     nop                         // 1     nop                         // 1     bra   Loop                  // 3                        // 10 => 20 cy for 2 interations     // 20 bus cycles @  4MHz bus freq. => 200kHz, 5.00 us     // 20 bus cycles @  5MHz bus freq. => 250kHz, 4.00 us     // 20 bus cycles @  8MHz bus freq. => 400kHz, 2.50 us     // 20 bus cycles @ 10MHz bus freq. => 500kHz, 2.00 us     // 20 bus cycles @ 16MHz bus freq. => 800kHz, 1.25 us     // 20 bus cycles @ 20MHz bus freq. =>   1MHz, 1.00 us  }}#define FBUS (8000000UL)#define FBAUD (9600)void initSCI(void) {   SCIBD = FBUS/16/FBAUD;   SCIC2 = SCIC2_TE_MASK;}void sendChar(char ch) {   for(;;) {      SCID = ch;      while (!SCIS1_TDRE) {      }   }}void main(void) {   SOPT1          = SOPT1_STOPE_MASK|SOPT1_BKGDPE_MASK;  // Watchdog off, STOP enabled, BKGD pin enabled,  initClock();//  testClockPeriod();  initSCI();  sendChar('A');}

[RogerSchaefer]

Hi pgo,

I am using a version of the BDM programmer I downloaded from Witztronics and installed a few days ago.

The HCS08 Flash Programmer auto detects all the chips correctly.

If I were sure that the Flash Programmer would ALWAYS require that a 9S08SE would need to change the default BDIV there would be no problem.  I would just write my application programs to do that.  But as I interpret your comments from eariler posts that would depend on Freescale manufacturing consistency.  In other words, SOMETIMES I would need to change BDIV when using it and SOMETIMES I WOULD NOT need to change BDIV.

In all the chips I listed in my last post, when I set the trim with your program and determined what to do with BDIV the SCI worked fine and the timers worked exactly as expected.  So the clock is OK

I will use your program, its easier than the alternative but I guess I will need to take extra testing steps and perhaps rework.

Roger

[pgo]

Dear Roger,

I don't believe the results are consistent with a spread in the manufacturing process. 

For the reasons I've given earlier I am quite confident that the value calculated for the trim are correct - but this does not necessarily mean that there isn't abug somewhere in the programmer that is causing the problem.  For example, the programmer has to modify the NV_FTRIM location to incorporate the FTRIM value.  It might be possible that it is doing this wrongly and causing some of the other bits to be set.  It might even be calulating the trim correctly but not programming it to memory correctly.

I would very much appreciate if you could provide a minimal test case (C or assembler but with the resulting S-record file for reference) that works on the QE8 but not on the SE8.  I can then chase down what is the reason for the different behaviour.  I understand that you may not have the time do do this.

bye

PS I provided the S-record files for the test case given earlier in the Zip file attached to my previous post if you wish to try these on your chips.

[RogerSchaefer]

Hi pgo,

You don't have any bug in calulating or programming trim to memory except I feel it should be exactly twice as fast in the case of the 9S08SE8.

I have attached an assembly program called "Backbone" which I use as a starting point for my programs.  It has IO, math,timer and other such routines but all it does at this stage is output "Hello World" to the serial terminal at 9600 baud and blink a LED a few times.

With the QE8 you will get "Hello World" at 9600 baud but because of the trim on the SE8 you will have to set your terminal program to 4800 baud or you will only see garbage.

To see a photo of the hardware the QE8 is running on click here:  http://www.rasmicro.com/QG8_Board.htm

Sorry don't have any photo of SE8 board yet.

Roger

[pgo]

Dear Roger,

I'm quite puzzled about the two programs you have provided.

The QE8 code sets the BDIV value to 0 at line #40 of MCUinit.asm so would have a 8MHz bus clock.

The SE8 code sets the BDIV value to 1 at line #55 of MCUinit.asm so would have a 4MHz bus clock.

I was unable to get a result using the S-record files provided - there appeared to be no activity on the Tx pins.

I converted the source code so that it would assembly with the codewarrior software and as you indicated the communication was at 9600 & 4800 baud for the QE8 & SE8 respectively after clock trimming - but this is due to the different BDIV values as indicated above.

So I really don't understand why you think there is a problem with the trimming.

Am i missing something obvious?

bye

[RogerSchaefer]

Hi pgo,

Its been about 15 months since I last worked with the 9S08QE8.  Now that I think about it I do recall that I had some trouble determining the trim for that chip and did wind up setting BDIV to 0.  I am sorry that I forgot that and I do apologize.

On the other hand I am quite sure I don't have to change BDIV on the 9S08QG8 and 9S08SH8 to get 8 MHz.  ( Actually I do change it on the 9S08SH8 but that is to get a bus clock of 16 MHz which is possible with that chip. )

So as it stands now it seems that with chips that use Internal Clock Source Ver 1 or 2 we do NOT change BDIV but with chips that use Internal Clock Source Ver 3 we DO have to change BDIV to 0.  Will that apply to other chips as well?  For example, later this year I plan to start on a project with a 9S08SV16 which uses ICS Ver 3 as well.  Will I expect to need to change BDIV with it also?

There is still the unresolved question is this due to the version of the ICS or is it due to Freescale manufacturing variability?

********************************

On a totally different topic my source was assembled with the P&E assembler and you said you converted it so that you could use Codewarrior.  I was under the impression that the two assemblers were quite different.  Is there some method to make the conversion an easier task?

Roger

[pgo]

Dear Roger,

The programmer only sets the clock trim .  I am confident that it is setting the the trim so that the internal oscillator is operating at the given frequency (usually 31.25kHz or 39kHz depending on the 8/16 or 10/20MHz chip operation).

The relation between the internal oscillator and bus speed depends on the clock setting AND the particular Clock System  used by the chip.  A rough guide as follows:

The ICSV1 was intended for operation with 8/10 MHz bus speed chips and has a FLL factor of 512.  8/10MHz operation requires BDIV=0.

The ICSV2 was introduced for 16/20MHz bus speed chips and has a FLL factor of 1024, so for the same clock settings operates at twice the bus speed of the 8/10 MHz chips using ICSV1.  For 8/10MHz bus operation (unusual situation for a chip designed for 16/20MHz operation) it is necessary to set the BDIV=1.

Finally the ICSV3 chip has a programmable FLL factor so can operate like a ICSV1 or ICSV2 - by default it looks like a ICSV1 chip.  BDIV=0 gives 8/10MHz operation.

The above assumes you don't change the DRS or DMX32 bits which modify the FLL factor.

The following has some examples:

http://opax.swin.edu.au/~3340694/USBDM/USBDM_Programmers/html/

One further note - Freescale describe their chips based on the clock speed not the bus speed.  So the SE8 is described as a 20MHz CPU but the max bus speed is 10MHz.

I hand converted the code for the Codewarrior assembler. I know of no automatic method for doing so.

Bye

[RogerSchaefer]

Dear pgo,

Thank you; I think I now understand the differences between the versions of ICS.

But that still leaves me with a problem.  For a couple of reasons, I want to load the "AN2295 Developer's Serial Bootloader" with the OSBDM and then use the Serial Bootloader to load my code.  On the chip where I set the trim to $24 ( on 9S08SE8) and made no changes to default values I could use the Serial Bootloader just fine.  But you maintain that even if it happened to work OK with that one chip it was because it was running out of spec range.  If you are correct then it would seem that the author of the "AN2295 Developer's Serial Bootloader" has made an error with the 9S08SE8 distribution of the program.  I would think that it would have been tested at least once before distribution.  I also would think that most folks are using the P&E programmer to load code and set trim.

I wonder what trim value the P&E programmer gives for a 9S08SE8.  I don't own one; do you?

Roger

[pgo]

Dear Roger ,

for reference, using a P&E Multilink V2 and trimmed to 31.25kHz:

QG8 trim B2.1

SE8 trim B7.1

These compare favourably with the figures given above for USBDM.

Bye

[RogerSchaefer]

Dear pgo,

OK Thank you very much for all your effort.

Now it seems that I have to get the AN2295 Developer's Serial Bootloader modified if I wish to use it.

Once again,

Thanks,

Roger

[mov]

Hi, pgo!

Thank you for great work!

When i try to recompile source of FlashProgrammer - i got an error in line #include "USBDM_API.h" - no such file. Can you add this header to sources for me and other peoples, who whish recompile project.

Regards, mov.

[pgo]

Dear mov,

The header file is part of USBDM available here:

USBDM - Version 2 (JS16/JMxx Versions)

I prefer to distribute it in this way as it should track any changes in the DLL.

You will probably need the DLL to link against as well.

bye

[mov]

Dear, pgo!

  Thank you for fast reply!

  Yes, i need the DLL to link. But i can't find configuration "USBDM Debug DLL" in project "USBDM_DLL_V2" which the referenced in the project "FlashProgrammer". When i try to link library from 

"1. Installation_1_0_3" - got some errors "undefined reference to " `USBDM_ConfigureDialog'  and `USBDM_GetErrorString'. The same error occurs when i try to link renamed DLL's from USBDM_DLL_V2 project. Looks like a missing declarations in "USBDM_API.h".

Please help me with this problem.

[pgo]

Dear mov,

Sorry!  I overlooked the fact that the programmer software has a later version of the USBDM.dll.

Attached is the required header file (I hope) along with corresponding DLLs to ensure that they are consistent.

bye

[mov]

Thank you very much, pgo! Now building done ok.

mov

[osorakunakamori]

Dear pgo,

Wow! Very nice work. This is terrific!!

Question - what do you think it takes to enhance it to support JM128 flash programming?

Thanks 

[pgo]

Dear osoraku,

Do you mean  MCF51JM?

I haven't looked at coldfire V1 yet.  I'm currently doing a HCS12 version.

It wouldn't be too hard I expect.  It depends on how uniform the Flash and Clocks are between the different Coldfire chips.  There are also some memory configuration issues that don't exist in the HCS08 chips.

So - on the list but not very soon.

"The list"

Paged memory support for HCS08 (e.g. AC128) - done but needs more thorough testing

HCS12 programming - partially done but has some issues with non-uniform BDM interfaces and security.

Coldfire V1 - not started.

 bye

Message Edited by pgo on 2010-02-09 10:37 AM

[osorakunakamori]

Dear pgo,

Another question - does the flash program in the constant byte array "flashProgram[]" come from the coldfire project in HCSO8_FlashProgramming? I was trying to compare the code in the s-record file to the bytes in the array ... they start out the same but soon diverge. What process did you use to create the contents of flashProgram[] ?

Thanks. 

[pgo]

Dear Osaraku,

The source code for the routine is provided as part of the Codewarrior project (HCS08_FlashProgramming.rar) included in the Zip file.

It's based on some app note on Flash programming or something - I can't remember!  It's pretty trivial though.

I don't know what "coldfire project in HCSO8_FlashProgramming" is

bye

[osorakunakamori]

Dear pgo,

Oops .. I meant "Codewarrior project in (directory) HCS08_FlashProgramming".

My point was just that I don't understand why the code in the s-record file for this project doesn't match the code in your constant byte array. Thus I was trying to figure out how one gets the proper definition of the constant byte array from the output of the Codewarrior project. Doea it need massaging in some way?

Thanks! 

[pgo]

Dear osaraku,

From memory, there is some pre-amble code that's commented out and it's relocated to origin $0000.   It may have another origin for testing.

The code is further patched on-the-fly by the C program execution. The table (dc.w?) in the assembly code is the list of addresses needing patching.

I hope this is clear.

bye

Message Edited by pgo on 2010-02-10 06:09 PM