Questions regarding AN2153

[sricker]

CW pro v4.6, HCS12DG256, 25Mhz Bus

I am using the assembly source from AN2153, slightly modified as a bootloader that will reside in the last 4k of Flash ($F000-$FFFF). I have an external network device (an XPort, by Lantronix) on SCI0.

I intend to be able to upgrade the firmware on any of my devices over the LAN. The Xon Xoff software flow used in AN2153 could become an issue due to how the XPort determines what data is included in a packet. It simply uses time ( >12mS between bytes = done, go ahead and send ) between incoming bytes from SCI0. There is an option to use "special" character sequences to indicate the end of a packet. I don't want to use this because the technique seems fundamentally flawed since I don't know what data might be sent and could inadvertently segment data.

To get to the question,

How do I calculate the time it takes to program a byte to Flash so that I can determine whether a particular data rate will require flow control. I'm thinking if I can program faster than I can recieve, I no longer need flow control, just the acknowledge at the end of an SRecord which means everything is good and proceed to send the next record.

I could put a scope on my board and toggle a bit to actually measure this, but I think it would be good to know how much time is attributed to the program cycle based on the clocks.

[mjbcswitzerland]

Hi
I don't know AN2153 but I have developed a loader/debugger according to AN2548 (2k serial monitor for HCS12). This works at 115k with 256 blocks so 115k BAUD can be programmed with no problems.
If you set the BAUD rate for your LAN/Serial converter to this or lower then nothing else should be necessary. Also set the LAN/serial converter serial interface to do no flow control.
I have also developed LAN/RS232 converters and generally it is typical to configure them to send TCP packets EITHER when a certain defined number of characters have been collected OR if there has been no received characters for a certain amount of time - this is a compromise between transmission delays (reaction time) and TCP transmission efficiency (avoiding lots of small packets). If you are connecting the LAN/serial converter directly to the SCI of the HCS12 you will just see a constant stream of characters (at the configured BAUD rate) as if the HCS12 were connected directly to the COM port of the PC sending the data.

The serial monitor (AN2548) uses simple handshaking at the protocol level and sends the data in binary form. If your loader requires SRECs then it will usually have no handshaking (I haven't seen SRECs being acknowledged but this could be possible) but the BAUD setting is in any case the simplest way to control throughput so there shouldn't be any difficulties.

There is another approach which you could consider. It is possible to programm and do quite powerful debugging if you connect to the BDM rather than the SCI (this will also require no code to be loaded in the HCS12). I don't know how flexible the XPort is to embed application code to do this though. If you are doing it seriously on a slightly larger scale then it is possible to do this by adding a M9S12NE64 rather than an Xport (it is also possible to plug one on to the BDM connector of only required temporarily - the circuit is also very cheap and requires less current that the XPort (about 50% less at 10Base-T). I have also programmed Network capable BDMs for the HCS12 based on the NE64, meaning that any HCS12 device on the network can be debugged and of course software can be loaded to it.

If you do have a demo board for the NE64 you can load free software to it to convert it to a Browser controlled BDM with upload capability - it needs a three wire cable to connect to the target board so is VERY easy to build. See the following application note:
http://www.utasker.com/docs/NE64/uTasker_NE64_BDM-0.01.PDF
The software for it can be downloaded from
http://www.utasker.com/software/ne64/BDM_ne64_B1.0.zip

The uTasker project is open source so can also be modified to suit specific requirements if required.

Regards

Mark Butcher

[sricker]

Hi Mark,

I have been in contact with you before regarding uTasker and I received the links to it. The NE64 will probably not work for us stand-alone because we need CAN, it could however replace the XPort as an ethernet "co-processor", hadn't thought of that........hmmm.

We do currently use the BDM with a PEMicro module. The reason we are adding the bootloader is so that firmware can be upgraded in the field by the user without a BDM module and especially without physically opening any boxes. Since I wrote this email we have had success with a simple GUI that allows one to select the s19 file and download it. We are even going to add the ability to program mulitple units on a network simultaneously.

Regarding AN2153, it has buffered interrupt driven serial comms and uses software flow control, I should know today if it (the flow control) is necessary at the communication speeds we will use. It also sends a character as an acknowledge of a good record after each one.

when you wrote this:

If you set the BAUD rate for your LAN/Serial converter to this or lower then nothing else should be necessary. Also set the LAN/serial converter serial interface to do no flow control.

do I understand you correctly that the flash is programmed faster than the incoming data? Even at 115kb?

Thanks for your help and I will look into using NE64 with uTasker as replacement for XPort!

Shawn

[mjbcswitzerland]

Hi Shawn

I can't say that the FLASH is actually programmed faster than a certain character time but there is no problem sending 256 bytes at 115k. It may be that the individual bytes (actually words because the HCS12 FLASH can not probram bytes) are first saved in a buffer and then a larger block programmed or it can be that they are programmed as soon as being received (in which case the receiver doesn't get blocked long enough to lose any characters).

My impression is that the programming of individual words in the HCS12 is very fast and it can "probably" keep up with that at 115k. If it proves to be wrong, simply reduce the BAUD until it is reliable. The fact is that whether the flow control is performed with handshaking of simply by reducing the BAUD it will not result in a faster or slower solution. Fast BAUD and long delay before handshake allows next block to be sent will give (approx.) the same throughput as setting the best suited BAUD....

Regards

Mark