Customizing a NoICE Classic Monitor for Your Target Hardware

This section applies only if you are using the NoICE Classic Monitor. If you are using BDM (HC12 or MC9S08) or JTAG (ARM or MSP430), this section does not apply to you.

The task of supporting a new target hardware platform is relatively easy. The starting point is the supplied NoICE target monitor for your processor. If your target hardware currently uses a hex monitor such as Buffalo, you may wish to refer to the source code for that monitor for details about hardware initialization, UART usage etc.

Further information is available about the NoICE Classic Monitor, about reset and interrupt processing, and about support for particular target hardware, including SBC's and eval boards.

Source code for the monitors may be found in the "monitors" subdirectory of wherever you install NoICE. The default location is C:\Program Files\NoICE\monitors.

If you prefer not to customize the monitor yourself, customization. is available for a fee.

The target monitors are written such that hardware-dependent code is isolated to a few locations in the source file. The areas to be examined and changed as required are these:

1. Target monitor ROM location, ROM_START. This will depend on where the processor begins execution, on the memory technology being used, and possibly on requirements for other ROM-resident code. If a ROM/RAM/UART board is installed, the monitor will most likely reside in that ROM.
2. Target monitor RAM location, RAM_START. The monitors require approximately 100 bytes of RAM; less if the stack sizes can be reduced, or if a smaller communications buffer is acceptable. The communications buffer size, COMBUF_SIZE, must be at least 19 bytes or the size of the processor's register block, whichever is larger. Download performance will be improved if a larger value is used (typically, 35 to 100 bytes). Monitor RAM should be located such that it does not inconvenience the project being developed. If a ROM/RAM/UART board is installed, it may be convenient to use the top or bottom of the RAM on that board. Target Monitor Stack. The monitor requires a small amount of stack space for its operation. At reset, the monitor initializes the stack pointer to INITSTACK (MONSTACK for the 8051). This value should be adjusted to match your hardware configuration and RAM layout.

   As provided, most target monitors switch to a monitor stack upon entry to the monitor via breakpoint, and switch to the user stack to execute user programs. If your RAM is limited, you may with to eliminate the stack switching. Search the monitor for references to REG_SP, INITSTACK, and MONSTACK and replace as appropriate.

   The 8051 and 6502 have 8-bit stack pointers and do not switch stacks.

3. Target hardware initialization. This is the most involved portion of porting the monitor. If the target processor is a single-chip micro with onboard peripherals, the prototype target monitor will probably contain most of the initialization code already. In any case, the initialization code developed here will likely be reused in the startup code for the final application.
4. Target Monitor UART. The UART to be used for target communications must be initialized, and the basic transmit and receive routines written. If the target processor contains a built-in UART, the standard target monitor is probably written to use it. In some cases, however, the application to be debugged requires dedicated control of the UART. For example, the UART may be used for RS-485 communications. In this case, you may want the NoICE monitor to use another UART. Some of the provided monitors include code for the 8250 and Zilog SCC.
5. Interrupt re-vectoring and vector initialization. The standard monitors take control of the reset vector, and a software interrupt for breakpoint if one is available. The other interrupts are generally re-vectored through a region of user code space. This adds some time to interrupt service, but is generally acceptable.

   When the monitor is first started, it initializes the interrupt region of download RAM to point to default interrupt handlers within the monitor. Thus, if an interrupt occurs for which the user code has not provided a handler, the default handler will cause entry into the monitor as if a breakpoint had been executed. The identity of the interrupt will be displayed as the processor state in the NoICE title bar.

   There is a drawback to this operation, however. If the target is reset after you download your program, the monitor will overwrite your program's interrupt vectors with the defaults. Thus, you must download after every target reset. If you prefer not to do this, you will need to modify your target monitor so that it does not initialize the interrupt region of download RAM.

   • For the Z80, 8085, 8096, and 8051, delete the dummy interrupts at DUMMY_INTS, and the loop which copies DUMMY_INTS to USER_CODE.
   • For the 68HC11, 68HC12 and 65(C)02, delete the code which initializes RAMVEC.
6. Breakpoint Instruction. If the target processor has a single-byte software interrupt instruction, it is convenient to use it as the breakpoint instruction, as a single byte breakpoint may be placed at any desired RAM location. However, if the target has no such instruction, or if the instruction is being used by the application code, or if the monitor does not have access to the interrupt vector for the instruction (as may occur during testing of the target monitor using another debug monitor), then a multi-byte breakpoint instruction may be used. Typically, the multi-byte breakpoint instruction will be a call to a monitor subroutine, which will push processor registers so as to simulate an interrupt. In most cases, the prototype target monitor will have appropriate code for the breakpoint instruction.

Testing a Customized Target

Test the modified target monitor by connecting its serial port to that of a PC. Turn on the target, and then run NoICE. If you are lucky, NoICE will talk to your target immediately. if not, you will get several beeps, and an indication of a communications error. In the latter case, first verify that NoICE is set to use the correct serial port and baud rate.

If you don't already have one, go to Radio Shack (or similar emporium of your choice) and buy an "RS-232 Mini-Tester". This device has a bi-color LED for the seven most common RS-232 signal lines. It is of great assistance in verifying that your cable is correctly wired, and that your target is driving the correct line.

Enable communications debug via Show Comm on the Options menu. Now issue the VERSION command to send a FN_GET_STATUS request to the target. Both the request and any reply are shown in hex. The hex values (if any) displayed can assist you in debugging your target monitor. The most common problems are bad cables and mismatched baud rates (unless, of course, you happen to make a programming error...).

Most of the communications functions can be exercised individually via keyboard commands:

VERSION will exercise FN_GET_STATUS, and display any results, including the target's identification string.

REG followed by carriage return will exercise FN_READ_REGS. Any returned values will be displayed in the register window. A common error is to forget to return 16 bit registers least significant byte first. Check the displayed registers to see if this is the case.

REG followed by a register name and a value will exercise FN_WRITE_REGS. In order to verify that the register was accepted by the target, follow this command by R to read back the registers from the target.

EDIT followed by an address will exercise FN_READ_MEM. to read one byte at the specified address. It is often useful to read the first byte of the target monitor, or some other location with known contents. DUMP or UNASM will use FN_READ_MEM to read multiple bytes.

EDIT followed by an address and a value or values will exercise FN_WRITE_MEM to write the specified values to the specified address. Since FN_WRITE_MEM verifies the write, you should attempt to write both RAM and PROM in order to insure that the monitor verifies correctly.

IN followed by an address will exercise FN_IN to input a byte from the specified address. This should be tested even if your target does not have specific I/O instructions.

OUT followed by an address and a value will exercise FN_OUT to output a byte to the specified address. This should be tested even if your target does not have specific I/O instructions.

BREAK followed by an address will exercise FN_SET_BYTES twice, to temporarily insert and remove a breakpoint. In order to test the ability to set multiple bytes with a single FN_SET_BYTE, you must set several breakpoints, and then issue a GO command to insert them all.

GO will exercise FN_RUN_TARGET. If an address is specified, it will be sent to the target via FN_WRITE_REGS before FN_RUN_TARGET is issued. If breakpoints have been set, they will be sent to the target via FN_SET_BYTES before FN_RUN_TARGET is issued. A reply to FN_RUN_TARGET will only occur if the target returns to the monitor after beginning execution. This may be arranged either by inserting a breakpoint, or by assembling a breakpoint instruction (typically a software interrupt) into the code to be executed on the target.

Monitors for Particular Target Hardware

Customized NoICE monitors exist for a number of popular target boards. The following are included in the NoICE distribution. Source code may be found in the "monitors" subdirectory of wherever you install NoICE. The default location is C:\Program Files\NoICE\monitors.

• EMAC Micropac 535 (8051)
• Marvin Green's BOTBoard2 (68HC11)
• Dallas Semiconductor DS5000T (8051)

Rhombus One Pin UART

The NoICE monitor requires a serial interface to the PC host. In many cases, you can use the UART on the target processor. However, in some applications this UART may be connected to an RS-485 port or other application hardware and not be available to the monitor. In such cases, you could hack a second UART and RS-232 transceiver onto your debug board, or use a pair of port pins for a bit-twiddled serial port.

An attractive alternative is the One Pin UART, available from Rhombus www.rhombusinc.com, 1909 Old Mountain Creek Rd., Greenville, SC 29609. This device allows a single bi-directional I/O pin to function as a full duplex RS-232 port. It connects with clip leads to the target's power, ground, and port pin, and has a DB-25 connector for a PC serial cable.

Source code for Get and Put character routines are provided for a number of processors, including the 8051, 68HC11, AVR, and PIC. These routines can be substituted for the GetChar and PutChar routines in the NoICE monitors.