Do you know a serial bootloader can interpret S19 files ? - HCS08AW60

[PatrickP]

Hello,

Do you know a serial bootloader can interpret S19 files ?

I use a HCS08AW60 and want to (for example) update software only by loading S19 file with SCI (with HyperTerminal or another board).

I read and test the AN2295 : Developer’s Serial Bootloader for M68HC08 and HCS08 MCUs and it work fine with a PC. But it needs the “PC Bootloader Master Software” to work.

I know my MCU Communication Speed and “just want to” load a S19 file via SCI. Then the Bootloader interpret S19 file and program flash memory.

Did anyone have documentation, idea, example or make a such bootloader ?

Best Regards,

Patrick.

Added p/n to subject.

Message Edited by NLFSJ on 2009-02-11 09:11 AM

[TurboBob]

Interesting idea.

This would make the bootloader a bunch bigger.  Perhaps this is not an issue for your application.

A few issues to think about:

  S19 files can be out of order, thus making the programming process fail.

  A host application can check the integrity of the file before sending it.

As far as I am aware,  there has not been a loader like this published here.

Bob

[bigmac]

Hello Bob,

Pardon my ignorance, but what data format do existing serial boot loaders use over the SCI link? The old evaluation boards (HC705) used to directly download S19 files into RAM.  This could be done using a simple terminal program.

I don't believe the the code to handle S19 file download was particularly complex or large. For the current case, to minimize RAM requirements, I would assume that the file would be handled line-by-line, with hardware flow control implemented.

Regards,
Mac

[TurboBob]

AN2295 sends the data in straight binary after processing the data a little bit (for the HC08AP the vectors are moved).  It is a command/response style interface.

For a unidirectional send, you could pace the data and assume it was processed properly.  The target could perform checksums and refuse to run the new program if it was incorrect.

Seems more dificult than using AN2295 though.

Bob

[peg]

Hi,

As far as I can see the biggest problem here is the potentially out of order nature of the S19 file format.
Mac, I think this is catered for in the old programmers by the fact that they were downloading into a full sized PROM image external RAM. That way out of order writes are handled.

With the limited RAM available internally you can't keep track of the entire FLASH map.

I just checked some random S19 files of mine, the second one I looked at had data that was not sequential.

[bigmac]

Hello,

I did not see out of sequence S19 data as a specific problem.  If the S19 file is handled line-by-line, each line has a specific flash address and the bytes within the line are sequential.  This would require a buffer size of typically 16 or 32 bytes.  Each line could then be programmed to its appropriate location in flash before the next line was fetched.  Thus the need for some form of handshake.

The flash programming would be considered incomplete until the final S9 record is received.

I seem to recall that I have previously done a quite similar thing, where an Intel hex file was downloaded, and the processed data image was stored within a serial EEPROM device.

Regards,
Mac



Message Edited by bigmac on 2009-02-12 11:58 AM

[peg]

Hi,

I guess I got hung up by wanting to burst programme it like AN2295 does. If you byte at a time programme the whole array then I guess it works.

Actually thinking some more, you can't use raw compiler/assembler output files because of the vectors requiring relocation. So if you are going to preprocess the S19 to achieve this you could also create a sequential S19 sized to suit the burst size (maybe even padded out to simplify). i.e. set the record length to 64 bytes. Now you can burst programme the whole array (under the bootloader).

[bigmac]

Hello,

I don't see why burst programming cannot be used for each S19 record (up to 16 or 32 bytes) since a RAM buffer would be used to hold the data.  Also I cannot see why it would be desireable to always burst program 64 bytes.  I would expect that the overall timing differences will be quite minimal for differing record sizes.

Presumably the boot loader will have primary control of the reset vector, and at least the SCI receive vector.  I would presume that any user code would need to at least take into direct account the method that the boot loader uses to redirect control to user program entry and user ISRs.  I can't see how this would be affected "raw output files" (S19) being downloaded.  Obviously, the user code will be specifically designed for resident boot loader compatibility.

For boot loader operation, I would imagine that two buffers would be necessary.  The first would be a circular buffer or a line buffer for SCI receive operation, of sufficient size for an unprocessed, maximum length S19 record.  The second buffer would contain the processed record, ready for the burst flash programming operation.

But perhaps I am being too simplistic!

Regards,
Mac





Message Edited by bigmac on 2009-02-12 05:08 PM

[peg]

Hello Mac,

I now see that after R'ing TFM I have held a misconception about how burst programming works for a long time. I always believed it had to be row aligned. This coupled with Bob's doubts led me off down this garden path. I have never done it, so never knew I was wrong until now.

About the vectors etc, The AN2295 bootloader accepts S19's that are generated without the knowledge that they will be programmed into the device by a resident bootloader. Doing it like this seems much easier than having to customise your code to suit the bootloader. Why re-invent the wheel and end up with something not as good/easy to use?

[PatrickP]

Thank you for all your ideas and suggestions.

It seems that there is still some work to be made.

Patrick.



 

[fabio]

I have written a bootloader for a commercial application and it reads directly the S19 file through the SCI.

Following a reset, the bootloader waits for some time for a specific boot sequence, if the correct sequence is received, it erases the FLASH and starts receiving the S19 file through the SCI. The code checks the checksum in the end of each text line and if it is correct it writes the binary to the FLASH and sends an ACK to the Delphi application running on the host. If the checksum does not match, it sends a NACK and the application sends the same string again.

This bootloader was completely written in C (ok, I had to put a single NSA inline instruction in the middle of the code!) and uses less than 1KiB of FLASH (which I think is not so bad for a C bootloader).

Regards,

[Sten]

I have been using a S-record bootloader based on AN2153 for several years already, and it works fine. AN2153 is originally written for 9S12DP256 but I have modified it also for 9S12DT128 and 9S12XDT256, and it can surely also be modified to run on 9S08-controllers.

Sten