Initializing High-Speed TINI Systems

Flash Limitations

Flash is generally the limiting factor in high-speed TINI designs. The best commercially available flashes have an access time of 55ns. The following chart shows how that relates to DS80C400 CPU speed and the AM29LV081 flash¹:

TINI OS Memory Requirements

To run the TINI Java™ Runtime (the TINI OS) on the DS80C400, there must be at least 512K RAM on CE0 (address 0) and another 512K of code space on CE2 (address 400000h). On the TINIm400, the code space is implemented as flash, but it could just as easily be implemented as RAM.

The problem with RAM for application code is that it is initially blank, and is erased if the power is removed, a battery dies, or some other external event wipes its contents. TINI applications will typically be used for remote monitoring and control, making field updates very inconvenient if a device loses its code. The solution is to copy an image of the application into the RAM from a flash that lies outside the normal TINI memory map.

An Alternate Memory Map

Consider the following memory map for a high-speed TINI.

Figure 1. Possible memory map for a high-speed TINI system.

This memory map shows two 512K RAMs at the locations required by the TINI OS (one at address 0 and one at address 400000h). It also contains an additional flash at address 600000h. This flash contains an initialization application that is responsible for:

• Initializing the heap
• Copying the firmware and application image to address 400000h
• Transferring control to the TINIOS

Making the Firmware Run Faster

Now that we have our custom TINI hardware designed, we need to alter the firmware to run at a faster speed.

The TINI firmware shipped with the TINI Software Development Kit is pre-programmed to run at a crystal multiplier of 2 on a 14MHz crystal. High-speed TINI systems typically run at a multiplier of 2 or 4 on a 14MHz or 18MHz crystal. The TINI firmware can be altered for different crystal speeds and multipliers using the TBINFixer tool. Run this application with no arguments to see the command line options. Typically, only the crystal multiplier (-m option) and the crystal value (-c option) will need to be changed. Use the file tini400.tbin from the TINI SDK as the input file for this application.

Startup Application

With the firmware altered to run at a faster crystal multiplier, we can now turn our attention to the program of initializing our TINI system to execute out of the RAM. A typical startup application presented here is written in assembly and built with free tools (macro and a390) that come with the TINI Software Development Kit.

For this startup application, we chose to store our TINI firmware and Slush application as TBIN³ files in the flash. As a result, our startup application will need to handle the parsing of the TBIN file format. The benefit of this is that the TBIN format stores all the address information for its data, making the startup application somewhat more general purpose.

The file init.a51⁴ shows an initialization application that reads some TBIN files stored in the flash and copies them to the RAM, then transfers execution to the RAM. The code is general-purpose, although three locations might require some adjustment for different memory configurations:

• TBIN_GLOB_ADDRESS equ 600000h
  This is the address where the TBIN files are stored. The image that resides here should be built using the BuildTBIN application (see the next section).
• EXECUTE_ADDRESS equ 400000h
  For the TINI Java Runtime, this address should stay 400000h (it can change for applications written in C). After the initialization application is complete, an LJMP to this location will be executed to transfer application control.
• org 6F0000h
  The org statement for the application specifies the location of the code.

Developers should consider a few issues in the current init code:

• Serial Debug: The initialization application configures timer 2 to generate baud rates for serial port 0. (The application contains some equates for tuning the baud rate.) It outputs information on each TBIN record that is being copied to the RAM. All the serial routines can be removed without affecting the functionality of the init code.
• Unrolled copy: The function Copy256 contains a partially unrolled 256-byte copy (unrolled as 16 loops of 16 single-byte copies). This is good for performance, but increases code size. If code size is more important than startup delay, this is a good place to look first.
• POR Checking: The init code does not check for a POR before it copies the TINI firmware and application. However, this may be desirable if the TINI application intentionally resets without cycling power. In this case, the application could skip the copy and go straight to code execution. Note that it is advisable to distinguish between intentional and unintentional watchdog resets. An unintentional watchdog reset may mean an improperly functioning TINI, in which case reloading the application code worth considering.
• RAM Erase: The startup code also performs an erase of the first 64 kilobytes of RAM to make sure the system has a clean start. This action may be removed if the RAM at CE0 is battery-backed. This startup code is included because on power-up many TINI systems assume that the file system needs to be reinitialized.

	macro init.a51
	a390 -l -Ftbin -d -p 400 init.mpp

The BuildTBIN Application

The BuildTBIN application is a Java application that takes one or more TBIN files and formats them into one file, usable by the startup application presented in the prior section. As our high-speed application will copy Slush and the TINI firmware from address 600000h to its proper location, the command line for BuildTBIN looks like this:

 java BuildTBIN 600000h file_to_load.tbin slush400.tbin tini400.tbin

The BuildTBIN application takes the input TBIN images and treats them as binary data, rewrapping it into another TBIN file targeted for a different address. There is a complication: the startup application needs to know how many TBIN records are included. This is not a problem with loader programs such as JavaKit and MTK, which look for the EOF (end-of-file) to determine when there are no more TBIN records. To solve this problem, the output TBIN file includes as its first byte a count of the number of TBIN records in the file. Because a TBIN file can include more than one TBIN record, the BuildTBIN application must parse each input TBIN file to count how many records it includes.

Figure 2. The BuildTBIN program takes input TBIN files, adds a 'count' byte, treats the whole thing as a binary stream, and outputs a new TBIN formatted file. As each TBIN record contains some overhead, note that the output file may contain up to 9 TBIN records, although the input files contained only 8.

The TBIN file format is described at: http://files.dalsemi.com/tini/ ds80c400/c_libraries/tbinformat.html. The source for the BuildTBIN tool is available at http://files.dalsemi.com/tini/ds80c400/tools/buildtbin.

If you would also like to include non-TBIN data in your final TBIN image, you can translate any binary data to the TBIN format using the tool Bin2TBIN. The source for this tool is available at: http://files.dalsemi.com/tini/ds80c400/tools/bin2tbin.

Conclusion

The approach presented here for initializing high-speed TINI systems is one of many possible solutions. This article and the code accompanying it are meant both as a solution and as an education on solving the problem. By adding a little more RAM and flash, a stable, high-speed TINI can be realized to take full advantage of the abilities of the DS80C400 processor.

Relevant Links

• High Speed User's Guide Supplement: http://files.dalsemi.com/tini/ds80c400/tools/DS80C400
• DS80C400 Data Sheet
• Discussion Forum
• Source code for the application note: http://files.dalsemi.com/tini/appnotes/highspeed/highspeed_initcode.zip

作者

Kris Ardis

Kris Ardis是ADI公司数字事业部的常务董事。他于1997年加入ADI公司，最初担任软件工程师，拥有两项美国专利。Ardis目前负责处理器业务，拥有德克萨斯大学奥斯汀分校计算机科学学士学位。