boot51.doc

Free 8051 asm compiler for linux new host platforms: Win32 and Linux macro processing dramatica

RESET51 is not running under Windows NT, 2000, and XP!

For batch file operation, a reset line is highly recommended! If you don't
have it, you will always have to press the reset button of the target system,
before invoking BOOT.BAT. Since this may easily be forgotten, it is better
to automate this step.


SLEEP
-----
waits until BOOT-51 has output <chars> characters of its sign-on message
at a given <baudrate>:

        SLEEP <baudrate> [<chars>]

SLEEP is a simple delay program, which is waiting as long as it takes to
output <chars> characters with the specified <baudrate>. However, SLEEP
takes into account, that BOOT-51 will never send more than one character
per ms, even at very high baudrates.
The default value of <chars> is 70, which is slightly more than the total
length of the BOOT-51 sign-on message.

Example 3:      SLEEP 300
----------
                Waits until BOOT-51 has fully output its sign-on message
                at 300 Baud.



III.4 Shell Script Operation under Linux
----------------------------------------
If serial I/O is only used for program upload, shell script operation may be
the most convenient way of testing with the shortest turn-around cycles.
The sample script file below, shows the principles of operating BOOT-51 from
a PC, running under Linux, with shell commands:

#!/bin/sh
stty 9600 sane clocal -crtscts -hupcl </dev/ttyS1      # until stty 1.16
# stty -F /dev/ttyS1 9600 sane clocal -crtscts -hupcl  # stty 2.0 or later
reset51 /dev/lp0
sleep 1
asem $1.a51
echo "U" >/dev/ttyS1
cp $1.hex /dev/ttyS1
echo "G 8000" >/dev/ttyS1

In this example, serial I/O is done over serial port /dev/ttyS1, and the
target system can be reset over printer port /dev/lp0.
First of all, the serial port /dev/ttyS1 is initialized to the desired
baudrate of 9600 Baud, 8 data bits, 1 stop bit, no parity and no handshake
with the stty command. (If your stty is version 2.0 or later, better use
the new command syntax with the -F option, as shown in commentary!)
Then the reset51 program provided is executed to reset the target system via
printer port /dev/lp0. After that, the sleep command waits until BOOT-51 has
recovered from reset, fully output its sign-on message, and is ready for a
command.
Now ASEM-51 is invoked to assemble the application program.
When finished, the BOOT-51 upload command 'U' is echoed to /dev/ttyS1, and
the Intel-HEX file is also simply copied to that serial port.
Finally the application program is started at address 8000H with the
command 'echo "G 8000" >/dev/ttyS1'.
To test an application program myprog.a51 with the above shell script
(stored in a file test51), simply type

        test51 myprog

at the shell prompt, and see what you get.
Of course this was only a minimized example! In general you will not only
have to modify serial port, baudrate, reset port, and start address for
your local requirements, but also to do something for plausibility checking
and error handling.
For this, the more sophisticated script file boot has been provided.
It allows an easy change of all configuration parameters with any ASCII
editor. For further information see the commentary inside boot.
In principle, boot contains only those configuration data!
(The actual work is done by another script upload provided, which is
 invoked by boot. If your stty command is version 2.0 or later, better
 use the script file upload.new instead!)
A program myprog.a51 can now be assembled, uploaded and started with

        boot myprog

To get the boot script running, ensure that you have full read/write
access to the serial port used as upload device!
If a printer port is employed as reset device, the reset51 program requires
root privileges!  (see below)

Finally, the reset51 program provided, may be worth a detailed explanation:
When invoked, reset51 forms a reset pulse of the duration <pulsewidth> at
the D0 and D1 outputs of a PC printer <port>, or at the DTR output of a
serial <port>:

        reset51 /dev/<port> [<pulsewidth>]

Legal <port> values are:  lp0, lp1, lp2,
                          ttyS0, ttyS1, ttyS2, ttyS3,
                          cua0, cua1, cua2, cua3,
                          null

Under Linux with kernels 2.0.x the printer ports are assigned to fixed
I/O base addresses (lp0 = 3BCH, lp1 = 378H, lp2 = 278H).
From kernel 2.2.0, the parport layer has been introduced, providing dynamic
printer port assignment. If your 2.2.x kernel doesn't contain parport layer
support or the /proc file system, you should recompile it respectively.
This should also make PCI bus printer ports available as reset devices.
reset51 can only handle the four standard PC serial ports ttyS0 thru ttyS3.
(However, the boot script described above should also work with non-standard
 serial ports, because it operates them with the stty command only!)
The serial ports ttyS0 and cua0 are equivalent, and so are ttyS1 and cua1,
and so on.
If /dev/null is specified as <port>, reset51 delays only for <pulsewidth> ms.

The optional parameter <pulsewidth> is the duration of the reset pulse in ms.
Legal values are:  1 <= <pulsewidth> <= 65535.  (default is 50)
When invoked without parameters, a help screen is displayed.
In case of error, reset51 returns the exit code 1, 0 otherwise.
When executed, reset51 forms a positive pulse at D0 (pin 2), and a negative
pulse at D1 (pin 3) of a PC printer port, or a "high" pulse (-12 V !!!) at
the DTR output of a serial port respectively.
If the default pulse width of 50 ms is too short to reset the MCS-51 board,
specify a greater pulse width.

Since reset51 needs direct access to I/O ports, it requires root privileges!
To make it available for all users, set the owner to "root" and set the
"set-user-id"-bit:

        chown root reset51
        chmod u+s reset51

For shell script operation, a reset line is highly recommended! If you don't
have it, you will always have to press the reset button of the target system,
before invoking the boot script. Since this may easily be forgotten, it is
better to automate this step.



III.5 The BLINK Program
-----------------------
When BOOT-51 is customized and blown into an EPROM, and the target board
is connected to the host PC, it would be nice to verify, whether the whole
configuration is working together correctly. This can be done with a short
test program that performs a well-defined action when started.
For this purpose the tiny assembly program blink.a51 has been provided.
It simply toggles the logic level of a port pin (roughly) once a second
(great if connected to a LED) to verify, whether all the components in
the chain

    assembly -> serial interface -> target system <-> bootstrap program

are working together correctly.
It can be adapted to your requirements with little efforts:

1. If your target system carries a LED that can be switched with a
   bit-addressable port pin, please change the BIT symbol LEDPIN
   accordingly. Then the program will make the LED blink.

   If your LED can only be switched with a non-bit-addressable
   port pin (say bit 2 of a port P6), simply replace the statement
   "CPL LEDPIN" by "XRL P6,#00000100B" or something like that.

2. Change the program start address START to the location, where
   user programs are usually loaded on your target system.
   The program code itself is position-independent!

If there is no LED on your target system, connect the port pin to
a volt-meter. This may also do. Aside of P0 and P2 you may use every
port with LEDs or spare outputs. Now the command

        boot blink

should reset the MCS-51 board, assemble the test program, upload it to the
target system, and finally start it. If the LED is blinking, everything is
now perfectly installed and ready for daily work.
If not, you should read the next chapter!



IV. Troubleshooting
--------------------
Of course, you have read all the previous chapters carefully (haven't you?),
and you have checked (and double-checked) your hardware, but the damn thing
is not willing to work!
If you don't have an idea what may still be wrong, here are some typical
cases from my own experience:



IV.1 General Trouble
--------------------
These are problems that may occur on all host platforms:

 1. The RESET51 program terminates without any error, but the target system
    is not reset.
    The (reset) cable may be plugged into the wrong (printer) port.
    First of all try the other ports.
    There may also be something wrong with the cable itself.
    Employ the BOOT-51 User's Manual and the circuit diagram of the target
    board, and check the cable.
    Furthermore, the reset pulse may be too short.
    Specify a greater pulse width.
    You may also decrease the reset capacitor of the MCS-51 system.

 2. The target system is reset all the time.                            _____
    When tailoring the reset cable, you may have mixed up the RESET and RESET
    lines. Simply interchange them.

 3. In batch (or script) mode everything seems to work fine on the PC, but
    on the target system you get absolutely nothing.
    Try the interactive mode and reset the target system. If nothing happens,
    you may have mixed up the receive and transmit lines of the target board.
    If you get some garbage, the baudrates and/or serial data formats of the
    target system and the PC are probably different.
    Configure your terminal emulation program correctly, and change BOOT.BAT
    (under MS-DOS) or the boot script (under Linux) accordingly.
    (correct data format: 8 data bits, 1 stop bit, no parity)

 4. Everything is working fine in batch (or script) mode, but when you try
    to upload the same HEX file in interactive mode, BOOT-51 aborts with the
    error message "unexpected character".
    Check the ASCII upload configuration parameters of your terminal
    emulation program. It has to terminate every line with a CR and/or LF
    character, and it must not send any pace characters!
    Of course it is always best, to send the HEX file exactly as it is.



IV.2 Trouble under MS-DOS
-------------------------
These are problems that are specific to DOS-based host platforms, including
Windows 3.1x. Most of it also applies to Windows 9x systems.

 1. When initializing the serial port, the DOS MODE utility aborts with an
    error message like:  "function not supported on this computer", or
    "invalid parameter", or something like that.
    On most PCs, the BIOS doesn't support baudrates greater than 9600 Baud.
    MODE itself doesn't support baudrates greater than 19200 Baud.
    However, most terminal emulation programs can operate at baudrates of up
    to 115200 Baud.

 2. The RESET51 program aborts with "port not found".
    The PC-BIOS didn't recognize the printer or serial port specified.
    Try another port or check your PC hardware.

 3. The RESET51 program aborts with "hardware failure".
    The PC-BIOS has recognized the specified port, but the data latch
    (printer port) or modem control register (serial port) doesn't work.
    Try another port, or check the defective port.

 4. The PC hangs when data are sent over the serial interface in batch mode.
    The RS-232 cable may be plugged into the wrong COM-port.
    First of all, try the other ports.
    There may also something be wrong with the modem control signals.
    (See chapter "II.3 Tailoring the Cables".)

 5. It works in interactive mode, but the PC hangs, if data are sent in batch
    mode.
    There _is_ something wrong with the modem control lines! Employ the
    BOOT-51 User's Manual and check the RS-232 cable at the PC side connector.

 6. When invoked, the MS-DOS MODE command hangs, or fails to change the
    previous baudrate, although it terminates without error.
    Remove all networking and communication drivers and TSR programs from
    your CONFIG.SYS and AUTOEXEC.BAT files, reboot, and try it again.
    There is plenty of quick'n dirty software, doing something strange
    with the BIOS interrupts!



IV.3 Trouble under Linux
------------------------
The most popular problems under Linux are permission conflicts and wrong
(or no) configuration. Problems may even change with the version number
of the Linux kernel!
Note that some changes suggested here will lower your systems security
against attackers who have login access to your machine. Direct access
to hardware ports and security do not mix well.
On some distributions changes in the /dev directory might be detected
by periodically run jobs and automatically reverted to the old state.

 1. The boot script aborts with the error message

    ./upload: /dev/ttyS1: Permission denied

    (or something like that).
    You don't have read/write access to the serial port in use (ttyS1).
    If you are the only user of this computer, you can log in as root,
    and simply allow read/write operations for all users:

          chmod a+rw /dev/ttyS1

    If there are more users who have access to the system, better define
    a new group called "embedded" (or something) in /etc/group and add all
    users who need access to this port. Finally do

          chgrp embedded /dev/ttyS1
          chmod o-rw,ug+rw /dev/ttyS1

 2. The boot script hangs on any attempt to output an Intel-HEX file to
    a particular serial port.
    There may be an I/O address or interrupt conflict, or the serial ports
    are not configured correctly, or not at all.

    Make sure that every serial port uses a base I/O address and an IRQ
    that does not conflict with any other hardware installed in your system.
    (For example, port ttyS3 at 0x2e8 conflicts with an 8514 graphics card!)
    Check the BIOS setup menu for on-board peripherals, as well as the jumper
    settings of all the legacy (ISA) boards.
    Watch the console output when Linux is booting. There are messages like

          ttyS00 at 0x03f8 (irq = 4) is a 16550A

    A log file is usually kept in /var/log. The file name depends on the
    Linux distribution and version. Look for boot.msg, bootlog, or something.
    Linux doesn't really auto-probe the serial ports. It assumes standard
    port addresses and IRQ numbers. If your hardware doesn't match this
    default configuration, it will not work. In this case you have to
    configure your serial ports manually with the setserial command, e.g.

          setserial -v /dev/ttyS0 port 0x3f8 irq  4 autoconfig
          setserial -v /dev/ttyS1 port 0x2f8 irq  3 autoconfig
          setserial -v /dev/ttyS2 port 0x3e8 irq  9 autoconfig
          setserial -v /dev/ttyS3 port 0x2e8 irq 10 autoconfig

    Unfortunately the best place where to put these commands, in order to
    execute them during system boot, depends on the Linux distribution.
    For most Linux distributions, /etc/init.d/serial is a good choice!
    SuSE distributions kept it in /sbin/init.d/serial until version 7.0.
    For detailed information on serial port configuration refer to the
    setserial man-pages and the Serial-HOWTO.

 3. The boot script aborts with an error message like

         resetting target system ...
    @@@@@ access denied: /dev/lp0 @@@@@

    on a system with a 2.2.x (or later) kernel, or with

         resetting target system ...
    @@@@@ no root privilege @@@@@

    on a system with a 2.0.x (or earlier) kernel.
    The reset51 program needs root privileges for direct access to I/O ports!
    If you are the only user of this computer, you can log in as root,
    and simply allow to run reset51 as root for all users:

          chown root reset51