Source-level Debugging

The use of symbols and source information can make debugging significantly easier. If there are only a few symbols to define, this may be done by hand, perhaps while viewing the link map and/or assembly listing file to determine symbol values. For large-scale use, however, it is convenient to generate the symbols automatically during the compilation, assembly and linking process. In the case of source level debugging, the automatic generation of line number information is the only practical method.

NoICE can load symbol and line information along with memory contents from some load file formats, such as Elf/Dwarf/Stabs, ImageCraft DBG, and IEEE-695.

While NoICE could have been made to load symbols and line numbers in other formats, this would have made the program larger, and would have restricted the number of formats supported. Instead, we decided to write small utility programs that process the output of various cross compilers, assemblers, and linkers. The output of this processing is a NoICE command file (.NOI file) containing DEF (define) commands for the symbols to be defined, and FILE and LINE commands for line number definitions. The command file may then be PLAYed by NoICE to define the symbols and line numbers. Thus, a new compiler or assembler may be supported simply by writing the appropriate utility.

The NoICE package includes symbol and line number processing utilities for a number of popular assemblers and compilers. The source code for most of these utilities is available to licensed NoICE customers, in case they wish to customize them, or write a similar utility for use with another assembler or compiler.

PLEASE NOTE: NoICE has been available in various forms since the DOS version of 1993. Some of the assemblers and tools mentioned below are 16-bit DOS or 32-bit Windows command line programs than may not run under current versions of Windows. If you are looking for an assembler, we recommend that you start with Alfred Arnold's AS

The utilities may be found in the \bin subdirectory of wherever you installed NoICE (usually c:\Program Files\NoICE\bin). At your option, you can add this directory to your Windows PATH, copy the utilities into a directory on your current path, or specify the location when you run the utilities.

If you run these utilities with no parameters, most will output a short description of syntax and available switches.

2500AD .DCF and .SYM

2500AD compilers can generate extensive debug information in the form of .DCF and .SYM files. The NoICE utility 2500NOI extracts information from both of these file types.

The command line to process the files is:

    2500NOI {switches} file {cmdfile}

where "file" represents the name of the .DCF or .SYM file, and "cmdfile" represents the output command file. If "cmdfile" already exists, the old file will be deleted and replaced by the new one. If cmdfile is omitted, output is to stdout.

There are several switches that control processing:

If "file" has the extension .SYM, only symbolic information is extracted. If "file" has the extension, .DCF, then both the .DCF and .SYM files are processed for line number and structure definitions as well as symbolic information.

As an example, suppose that you have a C source file called MYAPP.C and an 8051 target. Compile and link the program, producing output files MYAPP.HEX, MYAPP.DCF, and MYAPP.SYM. Next run

    2500NOI -P51 MYAPP.DCF MYAPP.NOI

This produces the NoICE command file MYAPP.NOI. Now run NoICE51, and give the commands

    PLAY MYAPP.NOI
    LOAD MYAPP.HEX

The PLAY command defines symbols and line number information. The LOAD command loads the program code.

The source code to 2500NOI is not included with NoICE, as it includes proprietary information about the 2500 AD file formats.

Alfred Arnold's AS Assembler

Alfred Arnold and colleagues have written an excellent free assembler that includes most of the target processors supported by NoICE, as well as just about every other processor architecture on the planet.

The assembler generates NoICE symbol (.NOI) files directly. However, in AS version 1.41r8 the addresses in the symbol files are decimal, and NoICE needs hex. This is NoICE's fault: addresses used to follow the RADIX preference until version 7.4, when NoICE changed to what seems the more useful convention of addresses always in hex.

The assembler source code was changed at the end of May 2000 to generate addresses in hex, but as of January 2006 there has been no official release containing these changes. However, the 1.42 beta seems to work just fine. Source code is also available.

ASPiSYS Assembler

ASPiSYS sells a variety of hardware and software. They offer free assemblers for the HC11 and HC08 that generate P&E Map files for debugging. You can process these using PEmapNOIfor use with NoICE.

The non-free version of their HC11 assembler can generate NoICE debug files directly.

Avocet AVMAC

Avocet (tm) makes a line of cross assemblers that target most 8 bit microprocessors. All share the same AVLINK linker.

Because AVMAC is a relocatable assembler, two actions are required to define source line information. First, the assembly listing file(s) must be processed to define the line numbers relative to the beginning of each memory segment in each file. Second, the link map must be processed to determine the absolute addresses of the segments for each source file. The link map is also processed for global symbol definitions.

AVOSRC: Source Line Processing

The NoICE utility AVOSRC processes an AVMAC listing file into a command file that defines FILE and LINE number information. The command line is:

    AVOSRC infile {cmdfile}

where "infile" represents the listing file output by AVMAC, and "cmdfile" represents the output command file. AVMAC listing files normally have the extension ".PRN". If "cmdfile" already exists, the old file will be deleted and replaced by the new one. If "cmdfile" is omitted, output is to standard output.

AVOSRC defines a source file line as "code producing" if the listing file shows an address, a line number, and at least one data value. When AVOSYM detects a code producing line, it generates a NoICE command of the form

    LINE nnn aaaa

where "nnn" is the number of the source line as shown in the listing file, and "aaaa" is the address offset of the line from the base of the current segment. Since AVMAC macro invocation lines are normally ($NOSHOWMACS) listed as comments, and macro expansions are not listed, AVOSRC will not classify macro lines as code producing.

AVOSRC relies on being able to detect SEG directives in the listing file in order to generate line number information relative to the appropriate segment. When AVOSYM detects a SEG directive, it generates a NoICE command of the form

    FILE filename.asm filename_segname

where "filename" is the name of the file being processed (without extension), and "segname" is the name of the segment specified in the SEG directive. The value of the symbol "filename_segname" is assumed to be defined by the output of AVOSYM operating on the link map file, as described in the next section. For this reason, when loading with NoICE, the command file(s) produced by AVOSYM must be played before those produced by AVOSRC so that the symbols will be given values before they are used. If these symbols are not defined, an error will result. Since SEG directives that are located inside macros or include files will normally not be seen, AVOSRC will not work correctly in such cases.

In most cases, INCLUDE files do not generate "code producing" lines as defined by AVOSRC, but are used to define macros and equates. If an INCLUDE file does produce code lines, then the processing by AVOSRC will depend on whether or not the contents of the INCLUDED file are visible in the listing file. If they are not visible ($NOSHOWINCS), then no line number information will be generated for the lines. If they are visible ($SHOWINCS), then incorrect line number information may be generated.

If processing of INCLUDED source lines is desired, AVOSRC could be modified to recognize the INCLUDE directive and build a stack of open INCLUDE files, since these may be nested. This is left as an exercise for the reader...

AVOSYM: Map and Symbol Processing

The NoICE utility AVOSYM processes the AVLINK map file into a command file that DEFINEs symbol and segment information. Use AVLINK with the -SM (show modules) and -SP (show publics) switches to generate an appropriate map. The command line to process the map is:

    AVOSYM mapfile {cmdfile} {-switches}

where "mapfile" represents the map file output by AVLINK, and "cmdfile" represents the output command file. AVLINK map files normally have the extension ".MAP". If "cmdfile" already exists, the old file will be deleted and replaced by the new one. If "cmdfile" is omitted, output is to standard output.

Optional switches are as follows:

The "-p" switch is intended to support paged memory. Since neither AVMAC nor AVLINK have any intrinsic support for paged memory, the user will have to link each overlay page separately, using the "-p" switch to place the symbols from each overlay in their appropriate page.

Normally, the map file will contain only public symbols. If desired, some or all source modules can be assembled using the AVMAC with the -AP switch or $ALLPUBLIC directive to make all symbols in the module public.

AVOSYM processes three portions of the map file. The first portion shows the start addresses and the lengths of the memory segments. These are labeled "RELOCATED SEGMENTS" and "ABSOLUTE SEGMENTS". AVOSYM generates commands of the form

    DEF segment_base hexvalue

where "segment" is replaced by the name of each segment with a non-zero length, and "hexvalue" is the start address shown in the map for that segment. These symbols are used to define other symbols as described below.

The second section of the map contains the names and values of all public symbols. This section is labeled "SYMBOLS -- CLASS 'M'" or "SYMBOLS -- CLASS 'N'". It is present only if the AVLINK -SP switch is used.

The third section of the map shows the offset and length of the portion of each segment that is defined by each source file. This section is labeled "MODULE DATA". It is present only if the AVLINK -SM switch is used. AVOSYM defines symbols of the form

    DEF module_segment segment_base + hexvalue

where "module" is replaced by a source file name, "segment" is the name of a segment of that module, and "hexvalue" is the offset shown in the map for that segment. If the AVOSYM -b switch is used, a DEFBASE command is generated instead of DEF.

When loading with NoICE, the command file(s) produced by AVOSYM must be PLAYed before those produced by AVOSRC. This is because AVOSYM will define symbols of the form module_segment that specify the base addresses of the segments of each source file. AVOSRC defines its line numbers as relative to these symbols. If these symbols are not defined, an error will result.

COFF Toolkit

COFF (Common Object File Format) comes from the land of Unix. COFF files contain symbol and debug information for C and assembler programs. Unfortunately, there is not real standard for COFF: every compiler and assembler seems to produce a slightly different format. COFFNOI.C is intended as a starting place from which you can derive a COFF processor for your tools. The source code to COFFNOI.C is available to registered NoICE customers.

If you modify COFFNOI to support a specific assembler or compiler, or if you would like assistance in doing so, please contact us.

The Zilog assembler ZMASM produces COFF-derived output files, which may be processed with the utility ZMASMNOI.

Cosmic C

Cosmic Software produces C compilers for the HC08, HC11, and HC12, as well as for a number of processors not supported by NoICE. Free size-limited demo versions is available.

The default debug output format is proprietary, but Cosmic provides conversion utilities CV695 to convert the proprietary format to IEEE-695, and CVDWARF to convert it to elf/dwarf. NoICE can LOAD either IEEE-695 or elf/dwarf, but we recommend that you use elf/dwarf if possible.

Note: the output of CV695 may incorrectly encode bitfields in reverse order in the IEEE-695 file. CV695 has a -rb option to change the order.

Note: for the HC08, the output of CVDWARF may generate stack offsets that are off by one byte. CVDWARF has a -so option to correct the offset. For more information, see https://www.cosmic-software.com/faq/faq41.php.

CUG 292 Assembler

The C Users' Group package 292 by Alan Baldwin is a set of free, relocatable assemblers and a matching linker. Source code is included. Supported processors are 6800/01/04/05/09, 68HC11, 68HC16, 6502, 8051, 8085, Z80, and H8.

We have modified version 1.7 of the assemblers and the linker to produce NoICE debug files. For each source file for which you want debug information, add the "-j" switch to your assembly command line. Then add the "-j" switch to your linker command line or command file to produce a .NOI output file.

As an example, suppose that you have an 8051 program called MYAPP.ASM. To assemble and link it, invoke a batch file containing the following lines:

    AS8051 -AOLFJ MYAPP.ASM
    echo -MSUJ > MYAPP.LNK
    echo -b DATA=0 >> MYAPP.LNK
    echo -b XDATA=0x8000 >> MYAPP.LNK
    echo -b CODE=0x1000 >> MYAPP.LNK
    echo MYAPP >> MYAPP.LNK
    echo -E >> MYAPP.LNK
    ASLINK -f MYAPP.LNK

ASLINK produces the NoICE command file MYAPP.NOI, and a hex file MYAPP.S19. Now run NoICE51, and give the command

    PLAY MYAPP.NOI

The PLAY command defines symbols and line number information. A command in MYAPP.NOI automatically LOADs the program code from MYAPP.S19.

You can download the modified version, including the source code. The original version is also available. It includes a number of test files not included in the revised archive.

If you are writing a free or shareware compiler, CUG292 makes a good assembler. The modified version includes a file describing how to generate debug information for use by NoICE.

Dunfield Development Systems

Dunfield produces assemblers, C compilers, and other goodies for a variety of microprocessors. Of interest to NoICE users are products for the 8051, 68HC11, 68HC12, 6805, 6809, 6502, 8085, and 8096.

Dunfield Micro-C is low-cost C compiler. It does not support long, float, enum, typedef, or bit fields. However, it does support structs and modern style (as well as K&R) function prototypes and is therefore far more capable than Small-C. Pointer arithmetic is non-standard, but quite functional.

Versions 3.15 and later of Micro-C can generate symbolic information for use by NoICE by using the new "-S" compiler switch. The NoICE utility MAPNOI processes the listing file containing this information. It produces a NoICE command file that contains FILE and LINE commands for source level debug, and DEFINE commands to define global, static, and automatic symbols along with their datatypes.

Version 3.15 of Micro-C should use MAPNOI, while versions 3.16 and later of Micro-C should use MAPNOI2. You should receive the proper program with your compiler.

As an example, suppose that you have a C source file called MYAPP.C and an 8051 target. Use the Micro-C command line (with additional switches as appropriate)

    CC51 MYAPP -CPLS

to compile, assemble, and generate a listing file with a symbol table. Then use MAPNOI to generate the NoICE command file:

    MAPNOI MYAPP

If Dunfield SLINK is being used, the appropriate commands are

    CC51 MYAPP1 -CAPS
    CC51 MYAPP2 -CAPS
    SLINK MYAPP1.ASM MYAPP2.ASM -S MYAPP.ASM
    ASM51 MYAPP.ASM -CFS
    MAPNOI MYAPP

In either case, MAPNOI will produce an output file MYAPP.NOI. Now run NoICE51, and give the command

    PLAY MYAPP.NOI

The PLAY command defines symbols and line number information. A command in MYAPP.NOI automatically LOADs the program code from MYAPP.HEX.

For assembler programs, the NoICE utility DUNSYM processes a listing file produced by ASMxx into a command file that contains FILE and LINE commands for source level debug, and DEFINE commands to define the symbols. The command line to assemble and produce a listing file containing a symbol table is:

    ASMxx sourcefile -fs

The command line to process the listing file is:

    DUNSYM listfile {cmdfile}

where "listfile" represents the listing file output by ASMxx, and "cmdfile" represents the output command file. If "cmdfile" already exists, the old file will be deleted and replaced by the new one. If "cmdfile" is omitted, output is to stdout.

Thus, for MYAPP.ASM and a 68HC11 target

    ASM11 MYAPP -fs
    DUNSYM MYAPP.LST MYAPP.NOI

This produces the NoICE command file MYAPP.NOI. Now run NoICE11, and give the commands

    PLAY MYAPP.NOI
    LOAD MYAPP.HEX

The PLAY command defines symbols and line number information. The LOAD command loads the program code.

Conditional (IF), INCLUDE, and MACRO processing are available using a separate Dunfield program called MACRO. The output of MACRO is assembled, and DUNSYM may be applied to the resultant listing file.

Elf / Dwarf / Stabs

Many current compilers, including GNU/GCC and Metrowerks CodeWarrior, can generate debug files using the Elf/Dwarf standard. Some compilers generate debug information in the Elf/Stabs format

NoICE versions prior to 8.8 used a utility program called ELFNOI to convert information from these files into a form usable by NoICE. This capability is now built into NoICE's LOAD command, so you can load Elf files directly. By default, these files will have a .abs extension. To see these files in the Load File dialog, change "Files to type" to "Elf Files".

Rainier Lamers' Embedded Pascal

Embedded Pascal is a low-cost Pascal compiler for the Z80 and 8051.

The NoICE utility EMPASNOI processes the .SYM files output by Embedded Pascal to extract symbol and line number information for source-level debugging with NoICE.

In Embedded Pascal, under Project Options:

• select "HEX" target
• check "Create symbol file"

As an example, suppose that you have a Pascal source file called MYAPP.PAS and an 8051 target. After compiling and linking your program, run

    EMPASNOI MYAPP.SYM

to produce the NoICE command file MYAPP.NOI. Now run NoICE, and give the command

    PLAY MYAPP.NOI

The PLAY command defines symbols and line number information. A command in MYAPP.NOI automatically LOADs the program code from MYAPP.HEX.

GNU GCC C Compiler

The Open Source GNU GCC C compiler is available for a number of targets supported by NoICE, including HC11, HC12, MSP430, and ARM. All of these generate Elf files. GCC430 generates debug information as Stabs, while the other compilers generate debug information using Dwarf. By default, these files will have a .abs extension. To see these files in the Load File dialog, change "Files to type" to "Elf Files".

NoICE's LOAD command can load Elf files directly.

You must use the appropriate compiler switches to generate debug information. Usually this is "-g" for the compiler (gcc). The debug switch for the assembler (as) differs from target to target. Consult your GNU documentation to see if you should use "-g", "--gdwarf2", "--gstabs", or some other switch.

As an example, here is an excerpt of a makefile from Feaser's Syn Code Editor (http://www.feaser.com/store/syn_hc12.php) for HC11 and HC12, modified to enable debug information in both C and assembly files (debug switches shown in bold):

	CFLAGS   = -m68hc12 -g -Wall -Os -fno-ident -fno-common -fomit-frame-pointer -mshort -fsigned-char -nostartfiles $(INC_PATH)
	CFLAGS  += -L$(TOOL_PATH)../lib/gcc-lib/m6811-elf/3.3.5-m68hc1x-20050515/m68hc12/mshort/ 
	LFLAGS   = -Wl,-u,-mm68hc12elfb
	OFLAGS   = -O srec --srec-len=32
	AFLAGS   = -m68hc12 -mshort --gdwarf2
	ODFLAGS  = -x

IAR Compiler and Assembler

IAR sells C compilers and assemblers for most of the microprocessors supported by NoICE. The IAR linker can generate a wide variety of output formats. The formats available differ by target architecture. The following list is in order of decreasing preference:

1. If your IAR compiler can generate Elf/Dwarf format, select that and LOAD the resultant file into NoICE.
2. If your IAR compiler can't generate Elf, but can generate IEEE-695 format, select that and LOAD the resultant file into NoICE. (If you do this, you may need to set the FRAMEPOINTER as appropriate for your processor.)
3. If your IAR compiler can't generate either Elf or IEEE-695, select the proprietary format called UBROF and follow the instructions below.

Please note that the free versions of the IAR compilers, including the MSP430 Quick Start, do not produce correct UBROF per the IAR documentation. The output of these compilers cannot be used with NoICE.

The NoICE utility IAR_NOI processes an UBROF file to extract symbol and line number information for source-level debugging with NoICE. IAR_NOI supports up to version 8 of UBROF. Later versions primarily add features for C++ that are not relavent for NoICE. If your compiler generates a later version of UBROF, you can adjust the settings to generate an earlier version.

• Open your project with the IAR Embedded Workbench. Select Project, Options from the menu to open the Options dialog.
• Select the Compiler, and select the Debug tab. Check "Generate debug information", and choose "file references".
• Select the Assembler, and select the Debug tab. Check "Generate debug information", and choose "file references".
• Select XLINK, and select the Output tab. Under Format, choose the "debug info". Notice the output file name (and override it if you desire). XLINK can produce a wide variety of debug formats. The default is the IAR proprietary UBROF format.
• Build your project.
• Run

      IAR_NOI myfile.dxx
  

  where "myfile.dxx" is the UBROF file output by XLINK. IAR_NOI will create files called myfile.noi and myfile.mot.

• Run NoICE, and PLAY myfile.noi. It will automatically LOAD myfile.mot.

UBROF files are supposed to contain information that specifies the processor type. However, this doesn't always seem to be the case. If you are using the 8051 with separate address spaces, you may need to tell IAR_NOI the processor type using the -P switch. For example,

    IAR_NOI myfile.dxx -P8051

If you are using banked memory, you must specify the banked range using the -B switch as -Blow-high. For example, a 68HC11 with banked memory between addresses 8000 and BFFF would specify

    IAR_NOI myfile.dxx -B8000-BFFF

A hint about structs: If you use the syntax

    typedef struct
    {
        char ch3;
        int  i3;
    } FOO;

    FOO varName;

to define a struct, IAR emits the structure definition wthout a name, and defines "varName" to be of that type. IAR_NOI assigns the anonymous struct type a name like "STRUCT_001", so that varName has a named datatype.

However, if you add a "tag name" in your typedef:

    typedef struct tag_FOO
    {
        char ch3;
        int  i3;
    } FOO;

    FOO varName;

IAR will emit the structure definition under the name "tag_FOO", and define "varName" to be of that type. This may be more readable during debugging.

Not all IAR assemblers produce source-level debug information. If you want to perform source-level debug of assembly modules produced an assembler that does not, IAR_NOI can extract the necessary information from the LST files. You must specify the path to the list file using the switch -L as:

    IAR_NOI myfile.dxx -Lc:\\somepath\\listdirectory

You must also define a public label of the form ?NOICE_BASE_XXXX at the beginning of each code segment XXXX in each assembly module. For example,

    rseg RCODE
    public ?NOICE_BASE_RCODE
   ?NOICE_BASE_RCODE:

   AsmFunction:
       dec a
       bne AsmLocal
    ...

Note: there seems to be a remarkable amount of difference in the UBROF produced by IAR compilers for different processors. Our testing has been performed with the compilers available to us. If you encounter problems, please contact us.

ImageCraft C

ImageCraft produces a low-cost C compiler and assembler for the ARM, 68HC08, 68HC11, 68HC12, and MSP430 as well as other processors not supported by NoICE. Version 6 and later of the compiler can generate debug files in the ImageCraft .DBG format. NoICE can LOAD the .DBG files to extract symbol and line number information for source-level debugging. This is required for source-level debugging. An .S19 or Intel hex file contains only program data. The .DBG file contains the debugging information. When using the ImageCraft IDE, select "Options" from the "Project" menu. Select the "Compiler" tab. For a Motorola/Freescale processor, if you want to debug only C modules, select output format "S19 with Source Level Debugging" For a Motorola/Freescale processor, if you want to debug both assembly (.S) and C modules, select output format "S19 with ASM/Source Level Debugging" For the MSP430, set Output Format to "Intel HEX w/ DBG Debugging". If available, (Professional Version only), select "V1.1" for "ImageCraft Debug Format". Structure and union information is only available if V1.1. is selected. To produce a debug file from the command line or a make file, use the "-g" compiler switch.

Select the "Target" tab. The dialog will be different for processors other than the 68HC12. Be sure to specify the exact processor and memory configuration appropriate to your target. If you are using expanded memory on the 68HC12, you must select "Linear" for "S2 Record Type". Otherwise, the S-records produced will not be loaded correctly by NoICE.

Build your project (myproject.prj in our example here). Then run NoICE and LOAD myproject.dbg. NoICE will load the debug file, and automatically LOAD myproject.S19 as well.

Earlier versions of NoICE required a utility program, ICCNOI, to convert DBG format into NOI format. ICCNOI is no longer required.

Note: For compiler versions 3.6 and later, the linker switch "-g" generates a NoICE command file containing source line and global symbol information. However, this debug information does not include automatic (stack-relative) symbols or data type information. The file thus produced will have a ".CMD" extension, rather than the standard ".NOI" extension. If you PLAY this file, you must also LOAD the associated .S19 file. If you are using version 6 or later of the ICC compiler, we recommend that you LOAD the .dbg file rather than using the .cmd file.

I/O Port Symbols

ImageCraft installs #include files that define I/O port addresses for many common targets. The definitions are such that you can use port names in expressions:

    foo = P1IN;

This is done by means of #defines of the form:

    #define P1IN  (*(volatile unsigned char *) (0x0028))

However, the #defines do not result in symbols in the debug file, which means that you can't use the port names in NoICE. The NoICE utility Msp430Equates.exe processes ImageCraft MSP430 .h files and produces a command file that contains DEFINE commands to define symbols for the ports. Run

    Msp430Equates file.h

where file.h is the equate file. This will generate file.noi. Now run NoICE, and give the command

    PLAY file.noi

to define symbols for the ports.

ImageCraft includes .h files with a similar format for some (but not all) HC12 parts, and Msp430equates may be used on these files as well. The #define format for other HC12 parts and most ARM parts are not compatible with Msp430equates.

Introl C Compiler

Introl provides a utility called I695 to convert their ICOFF format to IEEE-695. You can get the latest version from the Introl FTP site.

Before loading an Introl IEEE-695 file for the 68HC11, you must set

    FRAMEPOINTER SP+1

The most common place to do this is in NOICE11.NOI.

As an example, suppose that you have a C source file called MYAPP.C. Compile and link the program, and run I695.EXE to generate MYAPP.695. Now run NoICE, and give the command

    LOAD MYAPP.695

The LOAD command loads the program code as well as debug information.

Note:We have seen cases where the Introl-produced IEEE-695 file contains invalid datatype information. If you experience this, you may prefer to use our utility IntrolNOI.exe to convert ICOFF files to NoICE commands. After compiling and linking your program, run

    IntrolNOI {switches} file.ext

where "file.ext" represents the ICOFF file. Two output files will be produced, with the same name as the input file, but different extensions. The output command file will have the extension ".NOI", and the output hex file will have the extension ".HEX".

The output file file.noi may be PLAYed by NoICE. It will automatically LOAD file.hex.

There are several switches that control processing:

The output command file will be file.noi, and the output hex file (if generated) will be file.hex

It appears that Introl is no longer in business. They were formerly located at

Karl Lunt AS11 or AS12 Assemblers

Karl Lunt is the author of popular free assemblers for the 68HC11 and 68HC12. These are not macro assemblers, and the output is not relocatable, but the price is right.

The NoICE utility LuntNOI processes a listing file produced by ASxx and produces a command file that contains FILE and LINE commands for source level debug, and DEFINE commands to define the symbols. The command line to assemble and produce a suitable listing file is:

    ASxx file.asm -Lfile.lst

This produces output files file.S19 and file.LST. Next run

    LuntNOI file.lst {switches}

where file.lst is the list file output by the ASxx assembler. LuntNOI generates file.noi as the output command file to be PLAYed by NoICE, and file.dbg as the output debug source file.

Append the switch -B to show code bytes in the debug source.

As an example, suppose that you have a 68HC12 program called MYAPP.ASM. To assemble it run

    AS12 myapp.asm -Lmyapp.lst

This produces output files myapp.s19 and myapp.lst. Next run

    LuntNOI myapp.lst
or
    LuntNOI myapp.lst -B

This produces the NoICE command file myapp.noi. Now run NoICE, and give the command

    PLAY myapp.noi

The PLAY command defines symbols and line number information. A command in myapp.noi automatically LOADs the program code from myapp.s19.

MetaLink Assembler

MetaLink (tm) is a manufacturer of In-circuit Emulators for the 8051. They also offer an 8051 assembler, a version of which (ASM51 version 1.2h) is available as advertising freeware on various Web sites as ML-ASM51.ZIP. The output is not relocatable, but it has INCLUDE and MACRO capability, and the price is right. ASM51 can produce MetaLink debug files (.DBG) directly. However, this format does not seem to be publicly available.

The NoICE utility METASYM processes a listing file produced by ASM51 version 1.2h into a command file that contains FILE and LINE commands for source level debug, and DEFINE commands to define the symbols.

The line numbers printed in MetaLink listing files do not represent the line numbers in the source file if INCLUDE files or MACROs are used. Rather, the printed line numbers show aggregate lines as if the INCLUDED file or MACRO expansions were in line. Since we must be able to correlate addresses in the listing file with line numbers in some real file, METASYM must produce a debug file containing this "aggregate source". This is the file on which source debugging occurs. The command line to process the listing file is:

    METASYM listfile cmdfile debugfile

where "listfile" represents the listing file output by ASM51, "cmdfile" represents the output command file, and "debugfile" represents the output debug source file. If "cmdfile" or "debugfile" already exist, the old file will be deleted and replaced by the new one.

As an example, suppose that you have an 8051 program called MYAPP.ASM. To assemble it run

    ASM51 MYAPP

This produces output files MYAPP.HEX and MYAPP.LST. Next run

    METASYM MYAPP.LST MYAPP.NOI MYAPP.DSM

This produces the NoICE command file MYAPP.NOI and the debug source file MYAPP.DSM. Now run NoICE51, and give the commands

    PLAY MYAPP.NOI
    LOAD MYAPP.HEX

The PLAY command defines symbols and line number information. The LOAD command loads the program code.

Metrowerks CodeWarrior

Metrowerks CodeWarrior, generates debug files using the Elf/Dwarf standard. By default, these files will have a .abs extension. To see these files in the Load File dialog, change "Files to type" to "Elf Files".

NoICE's LOAD command can load Elf files directly.

MiniIDE IDE and Assembler

MiniIDE is a free IDE, assembler, and loader for the 68HC11 and 68HC12 from GTEK.

The NoICE utility MiniIDE_noi processes a listing file produced by the MiniIDE assemblers into a command file that contains FILE and LINE commands for source level debug, and DEFINE commands to define the symbols.

In the MiniIDE "Options" dialog, select the "Assembler" tab. Be sure that "Generate listing file" is checked, and that "all" symbols is selected. After assembling, run

    MiniIDE_NOI myfile.lst

where "myfile.lst" is your list file. This produces the NoICE command file myfile.noi. Now run NoICE, and give the command

    PLAY myfile.noi

The PLAY command defines symbols and line number information. A command in myfile.noi automatically LOADs the program code from myfile.s19.

MiniIDE S19 files do not specify the program start address. To specify one yourself, either numerically or as a symbol run

    MiniIDE_NOI myfile.lst -sstarthere

where "starthere" is replaced by your start location or symbol.

MiniIDE LIST files do not clearly distinguish between the main file and the contents of include files. For best results, include files should begin with "NOLIST" and end with "LIST". If you want to generate info for include files, run

    MiniIDE_NOI myfile.lst -i

However, this may case errors if NOLIST or IF is used in the main file.

Motorola/Freescale Freeware Assemblers

Over the years, Motorola/Freescale (tm) has offered various free assemblers for most of their microprocessor line. Some of these were absolute assemblers, but the price is right. They are available on the Motorola/Freescale Freeware Web site, and on various other sites. Of interest to NoICE users are AS5 for the 6805, AS9 for the 6809, and AS11 for the 68HC11. Revised versions AS11NEW, etc. are also available.

NOTE: if you are using the Karl Lunt AS11 or AS12 assembler, you should use LuntNOI rather than MOTSYM.

The MCUEZ assembler generates Elf/Dwarf debug files. NoICE can LOAD these files. Note that the pre-built elf/dwarf files included with some examples are in an invalid format. Re-assemble and link the examples to get good files.

The NoICE utility MOTSYM processes a listing file produced by Asxx and ASxxNEW into a command file that contains FILE and LINE commands for source level debug, and DEFINE commands to define the symbols. The command line to assemble and produce a suitable listing file is:

    ASxx sourcefile -l s >listfile

The command line to process the listing file is:

    MOTSYM listfile {cmdfile}

where "listfile" represents the listing file output by ASxx, and "cmdfile" represents the output command file. If "cmdfile" already exists, the old file will be deleted and replaced by the new one. If "cmdfile" is omitted, output is to stdout

As an example, suppose that you have a 68HC11 program called MYAPP.ASM. To assemble it run

    AS11 MYAPP.ASM -l s >MYAPP.LST

This produces output files MYAPP.S19 and MYAPP.LST. Next run

    MOTSYM MYAPP.LST MYAPP.NOI

This produces the NoICE command file MYAPP.NOI. Now run NoICE11, and give the commands

    PLAY MYAPP.NOI
    LOAD MYAPP.S19

The PLAY command defines symbols and line number information. The LOAD command loads the program code.

The freeware assemblers have neither INCLUDE, MACRO, nor IF. They can, however, assemble multiple source files specified on the command line. In this case, the listing appears as if the files were concatenated before assembly, and the line numbers shown are aggregate line numbers. Thus, this feature should not be used. If it is desired to split the source into pieces, the DOS copy command could be used to concatenate the files before assembly, and MOTSYM applied to the resulting file.

OMF51 for the 8051

A format called OMF51 is widely supported by compilers and assemblers for the 8051. The original standard was released by Intel and is available on the Web. Keil has extended OMF51 to add support for data types and additional information not supported by Intel OMF.

OMF51NOI reads OMF51 files and extracts symbol and line number information according to the Intel definition. Documented Keil extensions will generate appropriate NoICE equivalents. Unknown extensions are ignored.

The command line to process an OMF file is:

    OMF51NOI {switches} omffile

where "omffile" represents the OMF51 file. Two output files will be produced, with the same name as the input file, but different extensions. The output command file will have the extension ".NOI", and the output hex file will have the extension ".HEX".

There are several switches which control processing. The defaults correspond to Keil generic pointer bytes.

Note: in previous versions of OMF51NOI, the defaults were CODE=0xC, DATA=0x0, XDATA=0xD, BITDATA=0xB. The defaults were changed in order to allow NoICE to dereference Keil generic pointers. If you prefer the old values, you will need to specify the appropriate switch values.

As an example, suppose that you have a C program called MYAPP.C. Compile and link the program, producing the OMF51 output file MYAPP. Next run

    OMF51NOI MYAPP

to produce the NoICE command file MYAPP.NOI and hex file MYAPP.HEX. Now run NoICE, and give the command

    PLAY MYAPP.NOI

The PLAY command defines symbols and line number information. A command in MYAPP.NOI automatically LOADs the program code from MYAPP.HEX.

Both Keil and Franklin define one byte, two byte, and three byte (generic) pointers. OMF51NOI generates "<*", "*", and ">*" pointer commands, respectively, for these pointers. OMF51NOI also sets SMALLPOINTERSIZE 1 and LARGEPOINTERSIZE 3, via commands in the output .NOI file.

NoICE will display and edit generic (three byte) pointers using the 00:0000 format. If you use the default switches for CDB2NOI, and have configured your target monitor to use these same pages, you can expand a WATCH of such a pointer and see the referenced data in whatever memory space it resides.

P&E Map File

P&E sells BDM dongles and other hardware and software. To support their debuggers, they have defined a debug file format called P&E Map Files. A number of free and commercial assemblers and compilers can produce this format.

The P&E format contains line number and symbol information, but does not contain symbol datatype information.

The NoICE utility PEmapNOI processes map files in the P&E format to extract information for source-level debugging with NoICE.

The command line to process a P&E Map file file.ext is:

    PEmapNOI file.ext

The output file file.noi may be PLAYed by NoICE. Because P&E Map files do not contain the program image, you must LOAD the hex file yourself.

PseudoSam Assemblers

PseudoCode corporation formerly offered free and commercial versions of the PseudoSam assemblers for a variety of microprocessors. They seem no longer to be in business. However, the free versions are widely available on the Web.

The NoICE utility SAMSYM processes a listing file produced by PseudoSam Axx into a command file that contains FILE and LINE commands for source level debug, and DEFINE commands to define the symbols.

The command line to process the listing file is:

    SAMSYM listfile {cmdfile}

where "listfile" represents the listing file output by Axx, and "cmdfile" represents the output command file. If "cmdfile" already exists, the old file will be deleted and replaced by the new one. If cmdfile is omitted, output is to stdout.

As an example, suppose that you have a 8051 program called MYAPP.ASM. To assemble it run

    A51 MYAPP

This produces output files MYAPP.OBJ and MYAPP.LST. Next run

    SAMSYM MYAPP.LST MYAPP.NOI

This produces the NoICE command file MYAPP.NOI. Now run NoICE51, and give the commands

    PLAY MYAPP.NOI
    LOAD MYAPP.OBJ

The PLAY command defines symbols and line number information. The LOAD command loads the program code.

SDCC (Small Device C Compiler)

SDCC is a free open source compiler for the 8051, Z80, and HC08. Source code is available. Versions 2.1.8 and later can produce debug information files with a .CDB extension by means of the --debug switch.

The NoICE utility CDB2NOI extracts symbol and line number information from .CDB files. The command line to process the CDB file is:

    CDB2NOI {switches} file.cdb

where "file.cdb" represents the debug file output by SDCC. An output file called "file.noi" will be produced. If "file.noi" already exists, the old file will be deleted and replaced by the new one.

There are several switches which control processing. The defaults correspond to SDCC generic pointer bytes.

Note: in previous versions of CDB2NOI, the defaults were CODE=0xC, DATA=0x0, XDATA=0xD, BITDATA=0xB. The defaults were changed in order to allow NoICE to dereference SDCC generic pointers. If you prefer the old values, you will need to specify the appropriate switch values.

As an example, suppose that you have a C source file called MYAPP.C. Use the SDC51 command line (with additional switches as appropriate) to compile, assemble, and generate a debug file:

    SDCC --debug -IC:\sdc51\inc -LC:\sdc51\lib\small MYAPP.C

Then use CDB2NOI to generate the NoICE command file:

    CDB2NOI MYAPP.CDB

If you are linking several files, run CDB2NOI only on the final CDB file. For example:

    SDCC -c --debug -IC:\sdc51\inc -LC:\sdc51\lib\small MYSUBS.C
    SDCC --debug -IC:\sdc51\inc -LC:\sdc51\lib\small MYAPP.C MYSUBS.REL
    CDB2NOI MYAPP.CDB

In either case, CDB2NOI will produce an output file MYAPP.NOI. Now run NoICE51, and give the command

    PLAY MYAPP.NOI

The PLAY command defines symbols and line number information. A command in MYAPP.NOI automatically LOADs the program code from MYAPP.IHX.

SDC51 define one byte, two byte, and three byte (generic) pointers. CDB2NOI generates "<*", "*", and ">*" pointer commands, respectively, for these pointers. CDB2NOI also sets SMALLPOINTERSIZE 1 and LARGEPOINTERSIZE 3, via commands in the output .NOI file.

NoICE will display and edit generic (three byte) pointers using the 00:0000 format. If you use the default switches for CDB2NOI, and have configured your target monitor to use these same pages, you can expand a WATCH of such a pointer and see the referenced data in whatever memory space it resides.

Speech Technology TASM Assembler

Speech Technology Incorporated formerly sold a table-driven assembler with tables for a wide variety of microprocessors. The assembler is now supported by another company. TASM does not produce relocatable output, but it does have the ability to incorporate multiple files via #include, which may be used as a "poor man's linker".

The NoICE utility TASMNOI processes a listing file produced by TASM version 3.0 into a command file that contains FILE and LINE commands for source level debug, and DEFINE commands to define the symbols.

The command line to process the listing file is:

    TASMNOI listfile {cmdfile}

where "listfile" represents the listing file output by TASM, and "cmdfile" represents the output command file. If "cmdfile" already exists, the old file will be deleted and replaced by the new one. If cmdfile is omitted, output is to stdout.

As an example, suppose that you have a 8051 program called MYAPP.ASM. To assemble it run

    TASM -51 -l MYAPP.ASM

This produces output files MYAPP.OBJ and MYAPP.LST. Next run

    TASMNOI MYAPP.LST MYAPP.NOI

This produces the NoICE command file MYAPP.NOI. Now run NoICE51, and give the commands

    PLAY MYAPP.NOI
    LOAD MYAPP.OBJ

The PLAY command defines symbols and line number information. The LOAD command loads the program code.

TASM allows #include files to be nested up to six levels. Because of the way it parses list file information, TASMNOI cannot deal with #include files nested beyond three levels.

Data Sync Engineering Cross-32 Assembler

Data Sync Engineering sells a table-driven assembler with tables for a wide variety of microprocessors. Cross-32 does not produce relocatable output.

The NoICE utility UASMNOI processes a listing file produced by Cross-32 version 4 into a command file that contains FILE and LINE commands for source level debug, and DEFINE commands to define the symbols.

The command line to process the listing file is:

    UASMNOI listfile {cmdfile}

where "listfile" represents the listing file output by Cross-32, and "cmdfile" represents the output command file. If "cmdfile" already exists, the old file will be deleted and replaced by the new one. If cmdfile is omitted, output is to stdout.

Because the listing file gives no indication of lines produced by include files or macros, source-level debug is with respect to the listing file rather than the assembly source file.

As an example, suppose that you have a 8051 program called MYAPP.ASM. Assemble it, producing output files MYAPP.HEX and MYAPP.LST. Next run

    UASMNOI MYAPP.LST MYAPP.NOI

This produces the NoICE command file MYAPP.NOI. Now run NoICE51, and give the commands

    PLAY MYAPP.NOI
    LOAD MYAPP.OBJ

The PLAY command defines symbols and line number information. The LOAD command loads the program code.

Zilog ASM800, ZASM, and ZMASM

Zilog (tm) has several cross assemblers for the Z8, Z80, Z180, and Z800 on their web site, at

The older assembler, ZASM, (available ZIPped as SW_ZASM.EXE) includes a number of object file processing utilities, including MNM, which generates symbol listings. Switches specify the listing format, and whether the symbol file should include only global symbols, or all symbols.

The NoICE utility Z800SYM converts the MNM symbol file into a command file that DEFINEs the symbols. Command lines are:

    MNM -o symfile file.lnk

where "file.lnk" is the MUFOM format output from the linker, and "-o symfile" specifies that the output should be directed to "symfile". The "-l" switch specifies that local symbols should be included.

    Z800SYM symfile outfile

where "symfile" represents the symbol file output by MNM, and "outfile" represents the output command file. If "outfile" already exists, the old file will be deleted and replaced by the new one.

Line number processing for source debug is currently not supported for the Zilog assembler.

The more recent Zilog assembler ZMASM produces COFF format output files with an extension of ".LD". The NoICE utility ZMASMNOI processes these files to extract information for source-level debugging with NoICE.

Use the -g switch in ZMASM and ZLD, then run:

    ZMASMNOI {switches} file.ld

Switches:

As an example, suppose that you have a Z80 program called MYAPP.ASM. Assemble and link it, producing output file MYAPP.LD. Then run

    ZMASMNOI -H MYAPP.LD

This produces the NoICE command file MYAPP.NOI and a hex file MYAPP.HEX. Now run NoICEZ80, and give the command

    PLAY MYAPP.NOI

The PLAY command defines symbols and line number information. A command in MYAPP.NOI automatically LOADs the program code from MYAPP.HEX.