srec9s12 converts srecords from the form used by the gnu-mc68hc11/hc12 tools to the form needed for downloading. It can also download flash, eeprom, and ram data directly through a D-BUG12 based BDM pod. It runs on Linux and Cygwin on top of windoze. Downloads are more than an order of magnitude faster than using either NoICE12 or Hyperterm when tested on Cygwin over XP with a belkin usb-serial adapter. Download time is about 1 minute for a 200K file at 115200 baud.
Download and installation information is near the bottom of this page.
Options are specified in the form "--name=value". For boolean arguments, a 0 is false and a 1 is true, "--name" is equivalent to "--name=1".
Input File name. If unspecified or "-", use stdin.
Output File name. If unspecified or "-", use stdin.
No translation is performed on input.
Input addresses are interpreted as simple 16 bit addresses. Currently treated like banked addresses. All RAM, EEPROM, and FLASH is accessable. This is the form used internally.
Input addresses are banked. Addresses between 0x4000 and 0xFFFF are translated into page 3E,30, and 3F. Note that 0x301000, for example, refers to internal RAM not the flash at 1000 bytes into page 30 which is correctly refered to as 0x309000.
Input addresses are in motorola linear format 20 bit addresses. MC9S12DP256 flash is addressed from 0xC0000 to 0xFFFFF. Internal RAM and EEPROM are not addressable.
(default) Input addresses are in the perverse offset 0x10000 form used by the gnu-m68hc11 tools.
Input is in motorola srecords.
Output addresses are interpreted as simple 16 bit addresses. Note: currently does not reverse the translation performed by the CPU16 input map.
Output addresses are banked. No translation.
(default) Output addresses are in motorola linear format 20 bit addresses. Internal RAM and EEPROM are not addressable.
(default) Output addresses are in the perverse offset 0x10000 form used by the gnu-m6811 tools.
(default) Output motorola srecords.
Produce hex and ascii dump of data.
Enable debugging.
Print the value of the arguments after parsing.
Print a summary of command line options.
Send data to the BDM Pod via serial port instead of to outfile.
Serial port to send data to. Typically /dev/ttyS0, /dev/ttyS1, /dev/com1, /dev/com2, /dev/cua0, /dev/cua1.
Set baud rate to communicate with the Pod. Pod must have previously configured to reset to this baud rate using a terminal emulator.
Show date being sent to or from the pod. Does not affect the actual hex data which is controled by echo_hex.
Number of bytes per srecord line.
This is the string encoded in the header record of the file.
Hex lines are terminated with a newline.
Hex lines are terminated with a carriage return.
Hex lines are terminated with a carriage return line feed.
Download a custom flash programming routine instead of using FLOAD. Note that performance is actually better if you use the optimized FLOAD driver instead of this option.
XTAL oscilator frequency in hertz on the target CPU. Required if you use the downloaded custom flash programming routine; incorrect value could result in improper programming or damage to the chip.
Do not perform a bulk erase before programming. This will probably cause fload to choke.
(default) Perform a bulk erase before programming.
read serial port after each character. This can significantly slow performance.but can speed response to XON/XOFF.
Number of milliseconds to delay after sending each delay_interval lines during hex transfers.
Number of lines between delays. The LOAD command requires a delay_interval of 1 so it will override this value. FLOAD works faster with a value of 2.
At the end of each slurp_interval lines, the program will read the serial port to check for XON/XOFF, progress characters, and error messages.
Number of nulls to send after each character.
Number of nulls to send after each line.
Enable XON/XOFF processing at the OS kernel serial driver level. Decreases response time to XON/XOFF but slows performance.
Ignore XON/XOFF characters. This can increase performance. Requires appropriate delay settings to keep from overloading D-BUG12.
Issue a fflush() after each character. This can seriously hurt performance.
Issue a fflush() after each line. This can hurt performance.
Use line buffered output for the serial port and stderr. One operating system call will be made for each line sent.
Tell stdio to not buffer the output to the serial port and stderr. One operating system call will be made for each character sent. This can seriously hurt performance.
(default) Use a 4096 byte buffer for output. Other values up to 4096 can be used.
(default) display hex data after each value. Default = on.
Number of milliseconds to delay after sending the first (S0 header) line of srecord data to the Pod. This is when D-BUG12 apparently does its inialization.
Number of milliseconds to delay after sending a load or fload command to the pod, to allow it to do any needed initialization before streaming data.
This sets the command used to download FLASH data.
This sets the command used to download RAM data.
This sets the command used to download EEPROM data.
This sets the start address of RAM. Data between ram_start and ram_end will be downloaded using the flash_load_command. Currently must be specified in decimal. RAM data will be downloaded after FLASH and EEPROM so data won't be overwritten by BDM helper routines.
This sets the end address of RAM. Currently must be specified in decimal.
This sets the start address of EEPROM Data between eeprom start and eeprom_end will be downloaded using the eeprom_load_command. Currently must be specified in decimal.
This sets the end address of EEPROM Currently must be specified in decimal.
This sets the start address of FLASH Data between flash start and ram_end will be downloaded using the flash_load_command. Currently must be specified in decimal.
This sets the end address of FLASH Currently must be specified in decimal.
This should work with any D-BUG12 v4.x based BDM pod including the MiniDragon+, Some Technological Arts models, the Motorola EVB in pod mode, and any MC9S12DP256 development board with a BDM out connector and an appropriately configured version of D-BUG12 loaded. You should be able to get this program to download code on a development board without BDM but there are serious limitations to which areas of memory you can use in this case and you must be careful not to bulk erase or otherwise overwrite the flash. Due to limitations of the monitor, you won't be able to debug programs in flash without a BDM pod.
bash$ srec9s12 --input_file=m6811-elf-objcopy-format.s19 --send_to_pod --pod_port=/dev/ttyS0 # Linux bash$ /cygdrive/c/windows/system32/mode.com com4: baud=115200 parity=n data=8 stop=1 dtr=on rts=on odsr=off idsr=off xon=off bash$ srec9s12 --input_file=m6811-elf-objcopy-format.s19 --send_to_pod --pod_port=/dev/com1 --line_delay=0 --slurp_interval=128 # Cygwin bash$ srec9s12 --input_file=m6811-elf-objcopy-format.s19 --output_file=motorola_format.s19 bash$ srec9s12 --input_file=motorola_format.s19 --input_map=3 --send_to_pod
This program should port easily to most UNIX compatible systems.
This program works under Cygwin on Windoze eXtra Pain. Some versions may not support termios emulation properly and you may need to use the DOS mode command to configure the serial port. If you have kernel level xon/xoff processing enabled and you interrupt the program after an XOFF character, the program will not exit (windoze limitation). Hitting the reset button on the pod will give you the required XON character. To compile, use "make CYGWIN=1".
This program should work with little modification other than changing include files.
Requires the symbol table package by Mark Whitis. http://www.freelabs.com/~whitis/software/symbol/
. This has been included in the tarball.On windoze, requires Cygwin. http://www.cygwin.com/
If you have trouble, try resetting the BDM pod. If you manually reset the target, you will also need to reset the BDM pod.
I have written a flash downloading program for the DBUG12 based pods which is an order of magnitude faster than using NoICE or hyperterm with the FLOAD command. However, I didn't get the speed the way I expected to.
For a 213K program, 115200 baud, 4Mhz target CPU clock:
So, it is looking like the problems I was having had to do with windoze serial port performance. I am using a belkin usb to serial adapter but it seems to be able to handle 115200 baud, though perhaps there are some latency issues for flow control. Hyperterm is configured not to delay after each character or each line but it still takes about 1 second per line of srecord data (that should only take 6.25ms to send).
If I had known it was a serial perfomance issue, I wouldn't have bothered writing a custom flash helper routine and the interface to it. Oh well, I will need a good flash routine later anyway. It is currently slower than fload because of the extra interacion need.
Oddly, however, it looks like DBUG12 only sends XOFF once, apparently after the first line of the transfer (the S0 header record) and before the first line of data. It looks like DBUG12 foolishly delays initialization until after the first line of data. By sending a dummy header line and a delay, it looks like ascii-xfr can be used at full speed. Well, full speed for ascii-xfr, which is about half full wire speed. Apparently there is a default delay which you can eliminate by specifying "-l0", though it still doesn't run as fast as my program can push data without delays.
A slight modification in my program will send the entire file in 33 seconds but it does overload DBUG12 fairly quickly (5120 bytes of data (not ascii) into the file) even with flow control in the kernel. With flow control handled in the application, I can see that D-BUG sends an XOFF character for every 40 binary bytes of data on average before it dies. With that mod, it sends 6383 data bytes, not ascii characters, per second. That change eliminated an unintended 2ms delay (plus context switching and scheduling delays) at the end of each line. Since Linux schedules in 10ms intervals, that delay in reality would be at least 10ms and more if other processes wanted attention. A single line of data takes about 6.25ms to send. The delay was originally to aid in recognizing a command prompt.
I optimized the delays so it used a 10ms delay every other line of hex data and that worked in preliminary tests. Basically, this was a trick to allow me to effectively achieve delays shorter than the Linux process scheduling interval ("jiffie" clock). With flow control handled at the application level, I could see i was getting one XOFF/XON pair for every pair of lines at that rate, perfectly synchronized, so I may have succeeded in more than just statistically matching the delay on one particular machine.
Basically, DBUG12 cannot handle 115200 full speed even with efficient handling of XON/XOFF characters. Perhaps they forgot that a typical PC has a 16 byte hardware FIFO (better serial ports, which I don't have, have 256 byte hardware FIFOs) which means you can receive quite a few characters after you send an XOFF at any baud rate.
Under Cygwin, I was able to duplicate the dismal performance of other programs. It seems that while you can send data at high speed out the serial port, you can only do so if you are not reading data back. Windoze has traditionally had such poor interrupt latency that it is notorious for losing characters without the aid of hardware FIFOs. If you are doing XON/XOFF (apparently at either application or system level), you effectively render the FIFO useless and be subject to either the windoze latencies or, perhaps in this case, the USB latencies.
To complicate matters, you can't use usleep() under windows/Cygwin. It has a granularity of 1 second instead of 1 microsecond (actually 10ms on Linux). ven worse, if you specify a delay of less than 1 second, you get NO DELAY at all which violates the requirement that usleep delay NO LESS THAN the specified interval. nanosleep() however, does appear to work properly.
Also, under windoze+Cygwin with the usb to serial adapter if you do not try to read a character (xon/xoff, "*", or error message) after each hex write, you end up blowing D-BUG12s doors off. The usb serial adapter apparently has a lower per character latency than Linux. D-BUG12 appears to even get its doors blown off without even sending an XOFF character or perhaps it is just the extra time before responding to the initial XOFF character (maybe it sends it mid line instead of end of line).
The performance of your terminal emulator could potentially affect download speed with srecords echoed to display. Time to cat a 200K file to screen:
This is a preliminary version that has not been extensively tested or completed. Error checking is minimal. If you download to EEPROM or RAM, it will say download failed because D-BUG12 does not output an asterisk for each line but instead about 1 every 16 lines.
bash$ mkdir /dist bash$ cd /dist bash$ wget http://www.freelabs.com/~whitis/software/srec9s12/srec9s12-0.01.tar.gz bash$ cd /usr/local/src/ bash$ tar zxvf /dist/srec9s12-0.01.tar.gzz bash$ cd srec9s12/0.01/ bash$ cd symbol bash$ make clean bash$ make bash$ cd .. bash$ make clean bash$ make bash$ make install
bash$ mkdir /dist bash$ cd /dist bash$ wget http://www.freelabs.com/~whitis/software/srec9s12/srec9s12-0.01.tar.gz bash$ cd /usr/local/src/ bash$ tar zxvf /dist/srec9s12-0.01.tar.gz bash$ cd srec9s12/0.01/ bash$ cd symbol bash$ make clean bash$ make bash$ # ln `libsymtab.so': File Exists bash$ cd .. bash$ make clean bash$ make bash$ make install