Creating My Own Application to Flash 8-bit MCU

[indrahig]

Hi, I'm new to this forum.

Currently I'm working on a CDI (Capacitive Discharge Ignition) for 4-stroke motorcycle using 8-bit MCU S08SG8.

I'm using codewarrior v6.3, C language, MCU S08SG8-MTJ (20-pin) dan DEMO9S08SG8.

That demo board is used to flash the MCU through USB cable (from PC to demo board) and 6-pin ribbon cable (from demo board to my CDI board).

I'm planning to create my own application using Delphi language for giving my customer a freedom to change advance angle vs speed of the CDI, and flash that data into my CDI board from that application.

What I need are:

1. USB DBM multilink to replace that demo board. Maybe this USB-ML-12 will do.

     And I also need this library, so my application can flash the MCU using that USB multilink.

2. Those advance angle vs speed data are store in my C source code file (main.c).

     So I need to compile my source code to accomodate that change. But I want to do it within my own application,

     is it possible? I'm thinking about running a command-line or something.

So, do you think that USB multilink and the library will be sufficient for my application?

And what do I need to compile my source code before flash itu into my CDI board?

Hope It clear enough. I really appreciate any help given.

Thanks,

Indra Gunawan

[indrahig]

Thank you bicmac and rocco for your answers.

I get the big picture, but I don't know the technical detail yet.

To sum up, the connection between a PC and my board will be:

Computer -- USB cable -- USB to serial chip/module - MCU connected through SCI pins

That solution suits my need.

But now, there are a lot things I have to research, which are:

1. USB to Serial chip/module => FTDI chip FT232R or MM232R module

2. How to connect that chip into my MCU

3. How to communicate to MCU from my application, so I can put data and main firmware into MCU flash (through VCP driver)

4. How to separate the data from my main source code

5. How to read that data into main MCU firmware

So far, those are things I have in mind. Hard work for sure

I'll post any results from my research.

Regards,

Indra Gunawan

[bigmac]

Hello Indra, and welcome to the forum.

A potential alternative method, that may be simpler for the customer, might be to utilize the SCI module of the MCU as the customer interface.  A "standard" terminal program would be used within the host computer.  The MCU code would be able to parse the new data, and then update the flash data block with the new data.

The exact approach will depend on how many data points need to be stored.  It should be possible to manually enter each data point, and perhaps also to accept a downloaded data stream from an ASCII text file.  The default data settings would be programmed when the code was initially programmed.

Of course, this method does not give the opportunity to update the application code itself, only the data block.  If you also need this capability, a further alternative could be to use a MCU resident bootloader to directly handle the download of S19 files, also using the SCI interface.  The re-programmable data would be represented by some additional S19 records, that would be appended to the main S19 file.  The latter file would not initially include any records for the data.

Regards,

Mac

[rocco]

Hi Indra,

Mac offers an excelent alternative, and I would expand on it.

I have done exactly what he suggests, but have included a FTDI USB-to-serial chip on my board as well. So I can access the MCU through its serial port from any computer with USB as a virtual comm-port.

Like you, I have tuning parameters that are adjustable by the customer. I have a small program that runs under windows that allows those parameters to be downloaded into the MCU from an Excel spreadsheet. They can be updated at any time, without affecting the operating firmware.

I also have bootloader code in the MCU that allows the operating firmware to be updated through the same USB port.

The BDM protocol is not simple, and neither is the electrical interface, compared to a serial port plus USB chip. It also is more expensive. The advantage of the BDM approach is that you need no additional firmware in your MCU, but that will be outweighed by the added complexity on the host side. Communicating with a virtual comm-port is trivial, whereas determining how to talk to the BDM will be difficult.