Downloading- Writing software for embedded systems

Downloading

Having modified libraries, linked modules together and so on, the question arises of how to get the code down to the target board. There are several methods available to do this.

Serial lines

Programs can be downloaded into a target board using a serial comms port and usually an onboard debugger. The first stage is to convert the executable program file into an ASCII format which can easily be transmitted to the target. This is done either by setting a switch on the linker to generate a download format or by using a separate utility. Several formats exist for the download format, depending on which processor family is being used. For Motorola processors, this is called the S-record format because each line commences with an S. The format is very simple and comprises of an S identifier, which describes the record type and addressing capability, followed by the number of bytes in the record and the memory address for the data. The last byte is a checksum for error checking.

S0080000612E6F757410

S223400600480EFFFFFFEC42AEFFF00CAE00002710FFF06C0000322D7C00000002FFFC2D27

S22340061F7C00000004FFF8222EFFF892AEFFFC2D41FFF4222EFFFC92AEFFF42D41FFF83A

S21E40063E52AEFFF06000FFC64EB9004006504E5E4E754E4B000000004E71E5

S9030000FC

An example S-record file

The host is then connected to the target, invokes the download command on the target debugger and sends the file. The target debugger then converts the ASCII format back into binary and loads at the correct location. Once complete, the target debugger can be used to start the program.

This method is simple but slow. If large programs need to be moved it can take all day — which is not only an efficiency problem but also leads to the practice of patching rather than updating source code. Faced with a three hour download, it is extremely tempting to go in and patch a variable or routine, rather than modify the program source, recompile and download. In practice, this method is only really suitable for small programs.

EPROM and FLASH

An alternative is to burn the program into EPROM, or some other form of non-volatile memory such as FLASH or battery backed-up SRAM, insert the memory chips into the target and start running the code. This can be a lot quicker than downloading via a serial line, provided the link between the development system and the PROM programmer is not a serial link itself!

There are several restrictions with this. The first is that there may not be enough free sockets on the target to accept the ROMs and second, modifications cannot be made to read only memory which means that patching and setting breakpoints will not function. If the compiler does not produce ROMable code or, for some reason, data structures have been included in the code areas, again the software may not run.

There are some solutions to this. The code in the ROMs can be block transferred to RAM before execution. This can either be done using a built-in block move command in the onboard debugger or with a small 4 or 5 line program.

Parallel ports

This is similar to the serial line technique, except that data is transferred in bytes rather than bits using a parallel interface — often a reprogrammed Centronics printer port. While a lot faster, it does require access to parallel ports which tend to be less common than serial ones.

From disk

This is an extremely quick and convenient way of downloading code. If the target is used to develop the code then this is a very easy way of downloading. If the target VMEbus board can be inserted into the development host, the code can often be downloaded directly from disk into the target memory. This technique is covered in more detail later on.

Downloading from disk can even be used with cross-compilation systems, provided the target can read floppy disks. Many target operating systems are file compatible with MS-DOS systems and use the IBM PC as their development host. In such cases, files can be transferred from the PC to the target using floppy disk(s).

Ethernet

For target systems that support networking, it is possi-ble to download and even debug using the Ethernet and TCP/IP as the communications link. This method is very common with development hosts that use UNIX and is used widely in the industry. It does require an Ethernet port though. Typically, the target operating system will have a communica-tions module which supports the TCP/IP protocols and allows it to replace a serial line for software downloading. The advan-tage is one of far greater transfer rates and ease of use, but it does rely on having this support available within the operating system. VXWorks, VMEexec, and pSOS⁺ can all cover these types of facilities.

Across a common bus

An ideal way of downloading code would be to go across a data bus such as PCI or VMEbus. This general method has already been briefly explained using an extra memory board to connect ROMs to the bus and transfer data, and the idea of adding the target boards to the host to allow the host to download directly into the target. Some operating systems can already provide this mechanism for certain host configura-tions. For those that do not, the methods are very simple, provided certain precautions are taken.

The first of these concerns how the operating system sees the target board. Unless restricted or told otherwise, the operating system may automatically use the memory on the target board for its own uses.

This may appear to be exactly what is required as the host can simply download code into this memory. On the other hand, the operating system may use the target memory for its own software and free up memory elsewhere in the system. Even if the memory is free, there is often no guarantee that the operating system will not overwrite the target memory.

To get around this problem, it may be necessary to physically limit the operating system so that it ignores the target memory. This can cause problems with memory man-agement units, which will not allow access to what the operat-ing system thinks is non-existent memory. The solution is either to disable the memory management, or to use an oper-ating system call to get access to the physical memory to access and reserve it.

With real-time-based operating systems, I would rec-ommend disabling the MMU, thus allowing the host to access any physical memory location that the processor generates. Without the MMU, the CPU can access any address that it is instructed to, even if this address is outside those used by the operating system. This is normally not good practice but in this case the benefits justify its use. With UNIX, the best way is to declare the target memory as a shared memory segment or to access it via the device /dev/mem.

There are occasions when even these solutions are not feasible. However, it is still possible to download software using a modification to the technique. The program is loaded into the host memory by the host. The target then moves the code across the VMEbus from the host memory space to its own memory space. The one drawback with this is the problem of  memory conflicts. The target VMEbus memory must not con-flict with the host VMEbus memory, and so the host must load the program into a different location to that intended. The program will have been linked to the target address, which is not recognised by the host. As a result, the host must load the program at a different physical address to that intended. This address translation function can be performed by an MMU which can translate the logical addresses of the target memory to physical addresses within the host memory space. It is usually possible to obtain the physical address by calling the operating system. This address is then used by the target to transfer the data. The alternative to this is to write a utility to simply load the program image into a specified memory loca-tion in the host memory map. After this has been done, the target CPU can transfer the program to its correct memory location.

One word of warning. It is important that there are no conflicting I/O addresses, interrupt levels, resets and so on that can cause a conflict. For example, the reset button on the target should only generate a local reset and not a VMEbus one, so that the downloading system will not see it and immediately start its reset procedure. Similarly, the processor boards should not be set up to respond to the same interrupt level or memory addresses.

This method of downloading is very quick and versatile once it has been set up. Apart from its use in downloading code during developments, the same techniques are also applicable to downloading code in multiprocessor designs.