FlexScan consists of several components, some are optional, some are mandatory. Some you can simplify or redesign. That is up to you. Click on a component to view the schematics, and read a description of it, etc. The components are:
Once you have the hardware, you can start working on the software part. The following paragraphs and pages should give you an idea to get started on your scantool project.
The Scan OS is FlexScan's operating system and is stored inside the CPU. It takes care of providing comfortable access to the hardware like LCD-Screen or keyboard, but also allows easy access to the various automotive data streams. I used the Atmel AT89S8252 CPU, because it has 2K of on-chip data flash memory, and the 8K flash program memory can be programmed in-circuit with the proper download cable and software. But FlexScan does not rely on any 8252 features and will also work with a regular 8052 CPU.
Scan OS is currently about 6.5K in size and is stored inside the CPU's internal ROM. The internal ROM has a total of 8K, so there is still space if you have any suggestions or additions you would like to see added to the OS.
The OS consists of several largely independent parts. Each part contains a set of routines that provide services like reading the ECM, printing output on the display, etc. These are fully documented on these pages, but if you find one of them is buggy, please let me know so I can fix this in a future release.
Using the OS routines is simple. Each routine has a fixed entry in a jumptable. The entries are also called vectors. Simply define these addresses in your application source (or use the supplied assembly equates) and call the proper vectors. It's that simple. These vectors are guaranteed to remain fixed with possible future versions of Scan OS. Other functions may be added in later versions of Scan OS though. Scan OS provides a version number for this reason, so that software can query the operating system version and call only the functions that this version of the OS provides.
The Scantool provides a socket for a 27C256 type 32K EPROM. This EPROM is used to store the application program. The application program is the actual scantool program. This is a lot of memory, considering that all the dirty work is being taken care of by the operating system. All you basically need to write is some glue code, lots of string to show to the user, and some data tables to decode "your" data stream.
If you want to have more than one application or want to be generally more flexible, there is another approach that FlexScan/Scan OS support: you can install a 32K RAM instead of the EPROM in the socket. The board supports both, you just need to change two jumpers on the circuit board. With the RAM instead of EPROM you can load just about anything you like into the application RAM. The beauty part is, that the scantool doesn't care if a program was written for the EPROM or not, once it is in RAM, it runs just like its EPROM counterpart. But, how do you get the program into the RAM (which is not battery backed)?
The answer is the "FlashStick". This is a removable media that can be used to store an application. If a FlashStick with a valid file header is found by ScanOS, it will copy the program from the stick to the RAM and execute it there. The stick is about 1/2"x1.5" in size, and you can build it yourself for about $5. No proprietary connectors, nothing bulky, nothing expensive. Memory sizes may vary from 1 to 32K, depending on the requirements of your application or memory prices (currently a 16K chip costs about $5.50, an 8K part is around $3.)
So, if you want to use one existing application and don't care about developing, put the program in an EPROM, plug it in and forget it. But if you want to write applications, or want to do different things with your FlexScan, go with the FlashStick port. You can have as many FlashSticks as you like in your pocket, and can even put more than one application onto one FlashStick (sufficient space provided), and supporting the FlashStick port costs only about $2 extra in parts.
An application uses the services provided by the Scan OS to implement the scantool functionality. ScanOS supports standard 16-40 character wide LCD displays with 2 lines. If portable application programs are desired, a display width of 16 characters should be assumed.
After reset, Scan OS will check if a 32K RAM or EPROM is installed. If there is no RAM, it will look for an application program to be installed in the EPROM socket. If an application is found, the OS executes the application program. Otherwise a message is displayed on the LCD display and the CPU halts.
If a RAM is installed, ScanOS checks the FlashStick port for an installed stick. The stick is searched for an application, and in the future the user can maybe even select from a list of several applications. If only one application is on the stick, it is copied into RAM and executed automatically. Currently, ScanOS only supports one application per stick, and the FlashStick memory is copied in its entirety to the start of RAM.
If no FlashStick is installed, or the FlashStick contains no usable data, a message is displayed on the LCD display and the CPU halts.
To get a file into the FlashStick in the first place, press and release the "*" and "#" keys simultaneously while the startup copyright message is displayed. This puts the device into download mode. The CPU sets the serial port to 9600 Baud, 8N1, and waits for an Intel HEX file to be downloaded through the serial input pin. With a simple inverter/level shifter (like a MAX232 or MC1489) a PC can be connected directly to the ALDL/UART input of FlexScan. You must use an inverter though, if you connect the PC's output to FlexScan directly, download will not work! There is no handshake, but the FlexScan CPU is quick enough to handle the download on the fly. Any (error) messages will appear on the LCD-screen, the CPU will not send anything back to the PC. When the entire file has been received, you have a choice of executing the file in RAM as if it was an EPROM (which is great for debugging!), or have it transferred to a FlashStick. If the contents are to be copied to the FlashStick you can select between several memory types of different sizes. Once the proper device has been chosen, the the appropriate number of bytes from the start of RAM are copied into the FlashStick. If programming has been successful, you may copy the data into another Stick. It couldn't be any simpler (I hope).
Since all of these memories together account for less than 64K, the memory model has been somewhat simplified. The Operating System uses the following memory model for all functions that require a pointer.
| Address range | Memory |
| $0000-$00FF | internal 256 bytes RAM |
| $0100-$1FFF | Scan OS 8K internal ROM (not accessible from user program) |
| $2000-$27FF | internal 2K EEPROM (if the 89S8252 is used) |
| $2800-$3FFF | reserved |
| $4000-$7FFF | reserved for 16K expansion RAM |
| $8000-$FFFF | external 32K RAM/EPROM, access as data or program memory |
This way accesses to data contained in data or program memory or internal RAM can all be treated the same.
The operating system uses register bank 3 for some interrupts, banks 0-2 are available for the application program.
The OS uses a number of locations in RAM starting at address 32 ($20). The RAM usage of the current OS can be determined with the function GetOSRamTop. This is the address of the first location available to the application program. Currently this is address 64 ($40). The top 64 addresses are used as stack space. All other internal RAM addresses are available for the user program.
| Offset | Description |
| 0, 1 | Magic Number, must be $A5, $02 for executable files |
| 2, 3 | Load Address, high byte first (usually $8020) |
| 4, 5 | Program Length, high byte first |
| 6, 7 | CRC (if used), high byte first |
| 8 | Flag byte: compressed, autoexec, copy-protected |
| 9 | Decompression Mode |
| 10, 11 | Date: YY (7 bits), MM (4 bits), DD (5 bits) |
| 12, 13 | Address of next file on media (0 for the last file in chain) |
| 14, 15 | reserved for future use, set to 0 |
| 16-31 | Zero-terminated application name |
If the magic number is present, ScanOS will check flag byte 1 to determine if a CRC check should be performed. If bit 0 of flag byte 1 is set, the CRC check is performed over program length bytes starting from Load Address. The resulting CRC is compared against CRC and the program execution begins at location Load Address if the CRC was correct. In case of an incorrect CRC, the calculated CRC is output and execution halts.
During program development bit 0 of flag byte 1 should be clear to disable the CRC check altogether. When the development is finished, the CRC check should be enabled and the program run. The error message will contain the CRC to be put into the application program header for proper CRC checking.
The reserved portion of the header along with the application name may be used by future ScanOS versions to allow several applications to occupy the same EPROM and to allow selection at boot time and should be set to zero. Unused entries should equally be set to zero.
Click here to go to the Operating System Function Summary
Here is a short tutorial to get you started with FlexScan and ScanOS. It is not meant to be exhaustive, but it should give you an idea of how simple FlexScan and ScanOS make scantool experiments. The tutorial tries to cover all bases, but will only give you a general idea of what you can do and how to do it. For complete coverage of the ScanOS functions, please refer to the Operating System Function Summary.
If you have any suggestions or additions that would be useful, please let me know and I'll try to implement them if I think they're useful.
There have been
visitors to this site since May 31, 2000.