Tool for downloading S-record file through OpenSourceBDM.dll ?

[osorakunakamori]

Does anyone know of any open source tools which can be used to download .s19 target executables using OpenSourceBDM.dll ? I imagine that such a tool has to take the input .s19 file and transform it into essentially a sequence of wb and wblock commands to the dll. I have seen the type of dll commands required by using the debug version of the dll, programming a target device using CW, and looking in the resulting usbdm_dll.log file. Does anybody have any knowledge or experience with anything capable of this? Thanks!

[pgo]

Dear osaraku,

This is not as easy as you might think.  The BDM does NOT do the programming of the target.  It only allows the downloading of code to the ram and its execution.

The programming is done by downloading a flash programming routine to the target RAM along with the data to program (in several pieces).  The downloaded routine is then executed to program the target.  In effect the target programs itself.  This makes the BDM very simple.

The required program is target specific ie. each different target requires a customised program.

Codewarrior contains dozens of different files containing these details.  It might be possible to re-use this effort with another program BUT it would not be open source I think!

If you want to program a specific type of device it would be possible to develop a purpose built program to do this from scratch using the above process.

bye

[osorakunakamori]

Dear pgo,

Thanks for the info. I understand what you are saying ... there is a lot of (potentially chip-specific) complexity above and beyond merely translating a sequence of s-records into a sequence of commands to the dll. To put it another way, the dll knows nothing about flash, or a particular device, or programming algorithms. All it knows is how to send commands (expressed by function-call entry points to the dll) into messages representing BDM commands, which are delivered via USB to the BDM pod, and from there converted to commands on the BDM interface (i.e. BKGD etc) which are ultimately processed by the BDM of the target device. The commands are low-level things such read/write byte/block/reg etc. The higher layer (above the dll) makes use of these services to implement flash programming, debugging, etc.

A couple of questions about parts of the USBDM distribution:

In the USBDM_DLL directory, there's a file called MassErase.txt. What is this file for ... i.e it looks like a script file of some sort for flash erasing, but what software can process it?

Also in the USBDM_DLL directory, there's a file FlashImage.h which obviously contains executable code. If I understand correctly, this is produced from an s-record file using the HexToC utility. What is the purpose of building an executable (s-record file) into a C array in this way?

Thanks again for all your help, and the terrific work!

[pgo]

Dear Osaraku,

Answers below:

A couple of questions about parts of the USBDM distribution:

In the USBDM_DLL directory, there's a file called MassErase.txt. What is this file for ... i.e it looks like a script file of some sort for flash erasing, but what software can process it?

====

This was an example script to mass erase (unsecure) a particular chip.  I forget which one .  It's just a list of commands to the Flash control registers I believe. It's used with Test_USBDM.exe.

Also in the USBDM_DLL directory, there's a file FlashImage.h which obviously contains executable code. If I understand correctly, this is produced from an s-record file using the HexToC utility. What is the purpose of building an executable (s-record file) into a C array in this way?

 ====

There are two places where similar things are done:

1) For historical reasons, the RS08 programming & erasing is actually done by the BDM - not a good choice!   The programs to do this are embedded in the Source code for the BDM firmware but are originally generated from Codewarrior projects.

2) Flash.h contains embedded copies of the BDM firmware for the JMxx versions of the USBDM.  The DLL can update the BDM if it detects old firmware.  I prefer embedding rather than reading them in from a separate file - Only one (larger) DLL file is required.

The above is a semi-automated process as you have understood.

bye

[osorakunakamori]

Dear pgo,

I have been working on some simple code for downloading s-record files to certain targets (for now HCSO8 and JM128). The code, still in its infancy, is written in C#. I've been able to program QE8, JM60 and JM128 targets.

At first, my code simply used OpenSourceDLL API to write a byte-at-a-time (HCS08) or longword-at-a-time (JM128) to target flash. Each of the writes was wrapped in the appropriate register writes to do flash programming. This worked, but was really slow for larger executables (it took 9 minutes to download an 87K JM128 executable). 

I have sped this up considerably by arranging to send blocks of data to the BDM pod where they are temporarily cached, and then have the pod wrap each byte or longword transfer to target in appropriate flash control register writes. The speed up was enormous. For the 87K JM128 executable, programming time was cut to 25 seconds. To achieve this, I added new pod commands based on existing block write commands, but modified to perform flash programming instead of simple memory writes.

Clearly, Hiwave etc have an even more sophisticated (and much faster still) method of downloading whereby a bootloader with appropriate flash programming algorithm is downloaded first into target RAM, and then blocks of data are written to target RAM, and from there to target flash by the bootloader. I have not gotten to this level yet.

I am definitely interested on making my code and changes available to the community, but how best to do this? What sort of process is there for incorporating changes into the main USBDM release?

Thanks. 

[pgo]

Dear Osakaku,

I'm sorry but I can't agree that the approach you have used is appropriate.  In fact, in the next version of the USBDM code I have removed the code that programs the RS08 devices because it used an  approach similar to that you are using!

It is very important that the BDM code be generic - It should not need to know very much detail about the target device.

I think an appropriate approach is to limit the permitted operations to those provided by a generic BDM i.e. the ability to write code to RAM and control execution on the target.  It is quite doable to then use these features to program the target without the BDM firmware having to be modified in any fashion.

Suggested approach:

Write a small function in the target assembly language that is able to program a buffer from RAM to flash.

1 - Download the above to target RAM.

2 - Download a block of data to target RAM

3 - Execute the program in the target and poll for execution completion.

Repeat steps 2 & 3 as required.

An approach similar to the above is used by the RS08 programming code in the next version of the USBDM code.  The only modification is that some of the work is done by the BDM due to the very small amount of RAM available in some RS08 devices.  This modification is not needed for other targets.

The advantage of this approach is that  new devices can be added without any changes to the BDM software - either the DLLs or the BDM firware!

Finally, what is the difficulty in using the existing Codewarrior software to program devices?

bye

Message Edited by pgo on 2009-10-30 02:24 PM

[osorakunakamori]

Dear pgo,

I completely understand what you saying, and agree that the BDM pod and the BDM DLL should merely provide access to a target's BDM. Other functionality, such as flash programming, should be implemented using services thereby provided, but written in some external application.  And I completely agree that the approach we both have described (download bootloader to target RAM, and then use it to program possibly multiple blocks of data into flash) is the best approach. Not only does it keep target-specific flash programming algorithms out of the BDM but it allows the use of the target's burst-mode programming option. Unfortunately, I don't yet understand enough to write the bootloader, especially since it has to run from RAM on a target device that hasn't executed anything yet. What I mean to say is that I needed to get some basic flash programming working quickly, and the approach I took was the simplest thing that could possibly work. I am very much hoping to eventually use the bootloader approach.

Why am I not using CodeWarrior? I need to be able to program and otherwise diagnose target devices (using BDM functionality) from a third-party application, without any manual intervention, modal dialogues, or GUIs popping open. This is for a factory provisioning type application. I couldn't find CodeWarrior API's available via DLL, or a way to invoke Hiwave programmatically without having its GUI pop open. Therefore I wrote my own version of downloader which is basically an s-record parser which makes use of the USBDM DLL.

I agree that the simple additions I have made to the DLL and pod firmware are not ultimately desirable (ie once I get the bootloader approach working), but they have allowed me to produce a working s-record downloader fairly quickly. In the spirit of the GPL, I thought I should at least discuss these changes in this forum.

Thanks. 

[pgo]

Dear Osoraku,

Eventually I will be posting the Ver 2 of USBDM.  I suggest you have a look at how the RS08 programming is now done.  It should be relatively straightforward to adapt this approach to other targets hopefully without some of the complications introduced by the RS08 RAM size (like programming 8 bytes at a time!)

Good luck.

bye

[darknight]

Hi,

Perhaps this tools is what you need ?

take a look, you can change the directory of hiwave.exe

by defaut it's "C:\Program Files\Freescale\CodeWarrior for Microcontrollers V6.3\prog"

and select a connection to upload s19 file.

 send me a feedback

best regards

( ps: work with .net framwork 2 )

Message Edited by darknight on 2009-11-14 08:17 PM

s19 Tools.zip

Message Edited by t.dowe on 2009-11-16 09:09 AM

[osorakunakamori]

Dear darknight,

Thanks for your post. I haven't taken a look yet; based on your description I assume it programmatically invokes hiwave.exe with the .s19 file you specify. Is it able to prevent the hiwave GUI or other dialogs from appearing?

The tool I have been writing is written in C# 3.0 for .Net 3.5. It does not use hiwave at all, but does its own s-record parsing, and communicates directly with OpenSourceBDM.dll and pods built from the wonderful open source design. It can program s-record files, but also program specific flash (or RAM) locations which is useful for programming device specific serial numbers, hard-coded network addresses and the like. It also exposes memory block-read interfaces. All of this functionality is intended to enable production level download and testing of devices and the circuits they are embedded in. 

Thanks. 

[Miki99]

Dear Osoraku Nakamori,

I do agree that invoking CW programming software  frequently is not best option. Open Source BDM should be able to support third party software or open source programming software. I am occupied quite time with such idea but never had crytical time to start. Would you be able to share your programming software (sources) or you plan to do commercial app.

Regards,

Miki99

[darknight]

Dear osoraku,

I'm not familiar with usb and dll, so I found this solution,

but I wanted do in the same idea that you explain. 

I'll try to do this for learning, the soft is in VB.net 2008 express,

and there was a long way to go for me )