The complete tool name is a three-part hyphenated string. The first part indicates the processor or processor family (‘mn10300’). The second part indicates the file format output by the tool (‘elf’). The third part is the generic tool name (‘gcc’). For example, the GCC compiler for the Matsushita MN10300 is,
‘mn10300-elf-gcc’.

The MN10300 package includes the following supported tools:

MN10300 Series Evaluation board.

Both targets run in little-endian mode.

C:\cygnus\gnupro\i386-cygwin32\mn10300-elf\ecos-98r1p3

SET PROOT=C:\cygnus\gnupro\i386-cygwin32\mn10300-elf\ecos-98r1p3
SET PATH=%PROOT%\H-i386-cygwin32\bin;%PATH%
SET INFOPATH=%PROOT%\info
REM Set TMPDIR to point to a ramdisk if you have one
SET TMPDIR=C:\TEMP

For the Sourceware release of eCos, ensure that the Unsupported Tools for eCos are also installed. Assuming these are installed in their default location in

C:\cygnus\gnupro\i386-cygwin32\i386-cygwin32\unsupported-98r1p2

then add the environmental setting:

SET PATH=C:\cygnus\gnupro\i386-cygwin32\i386-cygwin32\unsupported-98r1p2\H-i386-cygwin32\bin;%PATH%

Programs->Cygnus eCos->eCos Development Environment.

This will bring up a window running "bash", and your Windows environment will be automatically set up.

For Bourne shell compatible shells:
 

-mmult-bug

static object_t myobj __attribute__((init_priority (30000) ));

The syntax is slightly different if the object takes any arguments to its constructor:

static object_t myobj __attribute__((init_priority (30000) )) = object_t(arg1, arg2);

The numeric priority can be from 1 to 65535, with 1 being the highest priority, and 65535 being the lowest. The default priority for objects without this attribute is 65535. Constructors with a higher priority are guaranteed execution before constructors with lower priority.

In all cases, you must provide the argument ‘-finit-priority’ to the compiler on its command-line for it to recognize this attribute when you are compiling your C++ source files.

If you are using eCos, be warned that eCos uses initialization priorities internally. Ensure you choose an appropriate priority level so that other eCos subsystems will have initialized before you refer to them in your own constructor.
 
 

The GNUPro C and C++ compilers can now optionally remove these unnecessary functions from the final image. They also ensure that any shared global data is removed that is only referenced by functions that are removed. This can be done by including the options ‘-ffunction-sections’ and ‘-fdata-sections’ on the command-line, when you invoke the C or C++ compiler. The ‘-ffunction-sections’ option removes unnecessary functions, and the ‘-fdata-sections’ option removes unnecessary data.

In addition, when classes define virtual methods in C++, it is possible to remove any unused methods from the final image by passing the option ‘-fvtable-gc’ to the C++ compiler on its command-line.

In all cases, you must also supply a command-line option when linking. If invoking the linker ld directly, use ‘--gc-sections’ on its command-line; alternatively, if you are using the preferred method of linking your executable, using the form
‘gcc -o <program name> <file1>.o <file2>.o’, then also pass the option ‘-Wl,--gc-sections’ on the compiler command-line, for example:
 

Stack frames for functions that take a variable number of arguments look like:

Any argument, more than 8 bytes in size, is passed by invisible reference. The callee is responsible for copying the argument if the callee modifies the argument.

‘d0’ and ‘d1’ are used for returning other scalars and structures less than or equal to 8 bytes in length.

If a function returns a structure that is greater than 8 bytes in length, then the caller is responsible for passing in a pointer to the callee which specifies a location for the callee to store the return value. This pointer is passed as the first argument word before any of the function’s declared parameters.

The assembler does not support "user defined instructions" nor does it support synthesized instructions (pseudo instructions, which correspond to two or more actual machine instructions).

For detailed information, see MN10300 Series Instruction Manual.

There are two ways for GDB to talk to an MN10300 target. Each target requires that the program be compiled with a target specific linker script.

In some operating systems, such as eCos, a single program may have more than one thread of execution. The precise semantics of threads differ from one operating system to another, but in general the threads of a single program are akin to multiple processes, except that they share one address space (that is, they can all examine and modify the same variables). On the other hand, each thread has its own registers and execution stack, and perhaps private memory.

GDB provides the following functions for debugging multi-thread programs

info threads

When your program has multiple threads, you can choose whether to set breakpoints on all threads, or on a particular thread.
 

If you do not specify ‘thread <threadno>’ when you set a breakpoint, the breakpoint applies to all threads of your program.

You can use the thread qualifier on conditional breakpoints as well; in this case, place ‘thread <threadno>’ before the breakpoint condition, as the following example shows.
 

Conversely, whenever you restart the program, all threads start executing. This is true even when single stepping with commands like ‘step’ or ‘next’. In particular, GDB cannot single-step all threads in lockstep. Since thread scheduling is up to your debugging target’s operating system (not controlled by GDB), other threads may execute more than one statement while the current thread completes a single step. In general other threads stop in the middle of a statement, rather than at a clean statement boundary, when the program stops.

You might even find your program stopped in another thread after continuing or even single stepping. This happens whenever some other thread runs into a breakpoint, a signal, or an exception before the first thread completes whatever you requested.

The MN10300 simulator is not designed to match timing characteristics of its target board. For example, the CPU module uses a single clock cycle for all instructions, its memory is infinitely fast, and its simulated serial I/O is infinitely fast. Furthermore, a number of obscure or inapplicable functions were omitted from the simulated peripherals. The simulator is just complex and accurate enough to run eCos programs.

Volatile registers: d0, d1, a0, a1

Saved registers: d2, d3, a2, a3

Special purpose registers: sp, pc, ccr, mdr, lar, lir

Memory is 4mb starting at location ‘0x48000000’. The stack starts at the highest memory address and works downward. The heap starts at the lowest address after the text, data and bss.

--board=BOARD

HAL configuration, for various download methods

In most circumstances, you should not download to simulator ignoring devices. If you use this download method, the binaries built with this configuration will not run on the target board; they can only run on the simulator. Likewise, binaries built to run on the target board will not run on the simulator.

In some cases, you may want to use a simulator specific configuration to try to work around problems with the device drivers or with the simulator itself.

Simulator clocks and timers sometimes appear to be running very slowly, even when there are apparently no active threads. Delays that should only be in seconds can run to minutes. These delays occur because the eCos kernel idle thread is running intensively, and the simulator emulates it faithfully. With the SIM configuration, however, the eCos kernel realizes it is in a simulated environment, and can therefore adjust the clock settings to be more realistic.

For example, suppose you are debugging a ROM monitor in the simulator invoked from GDB (we’ll call this GDB1), and you have downloaded an application to it from a second GDB session (which we will call GDB2). The second GDB session, GDB2, would simply consider the simulated target as a remote target and nothing more. Now suppose that in GDB2 you set a breakpoint in the program. The breakpoint will be physically set in GDB1. So when the breakpoint is reached, instead of the breakpoint being handled by the ROM monitor as if it was a real target, the breakpoint will be interpreted by GDB1 as if you had asked GDB1 to set a breakpoint in the ROM monitor code. This may not be your desired intention. To solve this, you can tell GDB1 not to process breakpoints itself, but to let the simulated target process them.

To do this, use the following command:
 

For example the command ‘handle SIGTRAP pass nostop noprint’ tells GDB to not stop the simulated target at a breakpoint, or even to print that it has been stopped. Instead, the command tells GDB to pass the information back to the program. You can modify the command to use with other signals and exceptions.

Note: if you use the aforementioned command, you will no longer be able to set breakpoints in the ROM monitor code (as in the example). You may be able to work around this problem by using conditional breakpoints. Please consult the GDB manual on how to use conditional-breakpoints.

The ambiguities discussed in this section are not a problem when you are using the standalone simulator. In such a case, the standalone simulator is the only target program that can handle the exception

While this approach offers the desired functionality, it is has a few disadvantages. The simulator is not only slow to execute code compared with real hardware, but simulation of the ROM monitor also slows the downloading of code to approximately the speed of a serial port. In addition, since the simulator must run continuously to execute CygMon, it can interfere with the performance of GDB. If there is insufficient memory for both programs to be in memory together, there may also be delays due to memory paging.

This technique uses TCP/IP for communication between the simulator and GDB, so you must ensure that the TCP/IP protocol stack is installed on your machine.

To run CygMon in the simulator, type the following command at the command line:

mn10300-elf-run --board=stdeval1 --sockser-addr=localhost:XXXX cygmon.rom

Where ‘XXXX’, is an unused TCP port number on your computer. A value of 1234 usually works, but any number between 1024 and 65535, which does not result in an error will do. The executable, ‘cygmon.rom’ can be found in the directory, ‘loaders/mn10300-stdeval1’ within the eCos installation.

This has started the simulator running CygMon. To make use of it you must run a separate GDB session and connect to it.

If you run GDB in command-line mode, you can attach it to the simulated CygMon with the following command:
 

If you are running the GDBTk then, in the ‘Target Settings’ dialog, select ‘Remote/TCP’ in the ‘Target’ edit field. Type ‘localhost’ into the ‘Host’ edit field, and put the value chosen for the port number in the ‘Port’ entry.

You should use executables configured to run on the target board with RAM startup, and not executables configured for the simulator.

If the performance of the two programs on a single machine is too slow, it is possible to use two machines: one to run the simulator and one to run GDB. These machines must be connected together on a TCP/IP network. Run the simulator on one machine, but supply the name of the machine in place of ‘localhost’ in the ‘--sockser-addr’ option. When running GDB on the other machine, replace ‘localhost’ with the name of the machine running the simulator.
 

CygMon has basic program handling and debugging commands, programs can be loaded into memory and run, and the contents of memory can be viewed. There are several more advanced options that can be included at compile time, such as a disassembler (this of course increases the code size significantly).

Since CygMon contains a GDB remote stub, full debugging can be done from a host running GDB to a target running CygMon. Switching between CygMon monitor mode and GDB stub mode is designed to be transparent to the user, since CygMon can detect when GDB is communicating with the target and switch into stub mode. When GDB stops communicating with the target normally, it sends a termination packet which lets the stub know when to switch to the CygMon monitor mode.

The command parser was written specifically for CygMon, to provide necessary functionality in limited space. All commands consist of words followed by arguments separated by spaces. Abbreviations of command names may be used. Any unique subset of a command name is recognized as being that command, so ‘du’ is recognized to be the ‘dump’ command. The user is prompted to resolve any ambiguities. Generally, a command with some or all of its arguments empty will either assume a default-set of arguments or return the status of the operation controlled by the command.

For users of the Sourceware release of eCos, instructions can be found at

http://sourceware.cygnus.com/ecos/

C:\cygnus\gnupro\i386-cygwin32\mn10300-elf\ecos-98r1p3\cygmon-src

In our examples everything is assumed to be installed on drive ‘C:’. If the CygMon source was not installed initially, it may be installed later by running the GNUPro compiler tools installer from the CD (‘D:’ must be replaced with the proper drive letter for your CD-ROM drive):
 

When the installation is complete, the sources should be installed in:
 

Programs->Cygnus eCos->eCos Development Environment

This will bring up a window running "bash".

If the location of your sources is not already mounted, do so:
 

mount C:/cygnus/gnupro/i386-cygwin32/i386-cygwin32/
unsupported-98r1p2/H-i386-cygwin32/bin /bin

You should now be able to configure and build CygMon as follows:
 

When complete, you will have CygMon images built in:
 

The baud command sets the speed of the active serial port. It takes one argument, which specifies the speed to which the port will be set.

Example: baud 9600

Sets the speed of the active port to 9600 baud.

The break command displays and sets breakpoints in memory. It takes zero or one argument. With zero arguments, it displays a list of all currently set breakpoints. With one argument it sets a new breakpoint at the specified location.

Example: break 4ff5

Sets a breakpoint at address ‘4ff5’.

The disassemble command disassembles the contents of memory. Because of the way breakpoints are handled, all instructions are shown and breakpoints are not visible in the disassembled code. The disassemble command takes zero or one argument. When called with zero arguments, it starts disassembling from the current (user program) ‘pc’. When called with a location, it starts disassembling from the specified location. When called after a previous call and with no arguments, it disassembles the next area of memory after the one previously disassembled.

Example: disassemble 45667000

Displays disassembled code starting at location ‘45667000’.

The dump command shows a region of 16 bytes around the specified location, aligned to 16 bytes. Thus, ‘dump 65’ would show all bytes from ‘60’ through ‘6f’.

Example: dump 44f5

Displays 16 bytes starting with ‘44f0’ and ending with ‘44ff’.

The go command starts user program execution. It can take zero or one argument. If no argument is provided, go starts execution at the current ‘pc’. If an argument is specified, go sets the ‘pc’ to that location, and then starts execution at that location.

Example: go 40020000

Sets the ‘pc’ to ‘40020000’, and starts program execution.

The help command without arguments shows a list of all available commands with a short description of each one. With a command name as an argument it shows usage for the command and a paragraph describing the command. Usage is shown as command name followed by names of extensions or arguments.

Arguments in [brackets] are optional, plain text arguments are required. Note that all commands can be invoked by typing enough of the command name to uniquely specify the command. Some commands have aliases, which are
one-letter abbreviations for commands which do not have unique first letters. Aliases for all commands are shown in the help screen, which displays commands in the format:

command name: (alias, if any) description of command

Example: help foo

Shows the help screen for the command ‘foo’.

The load command switches the monitor into a state where it takes all input as s-records and stores them in memory. The monitor exits this mode when a termination record is hit, or certain errors (such as an invalid s-record) cause the load to fail.

The memory command is used to view and modify single locations in memory. It can take a size extension, which follows the command name or partial command name without a space, and is a period, followed by the number of bits to be viewed or modified. Options are 8, 16, 32, and 64. Without a size extension, the memory command defaults to displaying or changing 8 bits at a time.

The memory command can take one or two arguments, independent of whether a size extension is specified. With one argument, it displays the contents of the specified location. With two arguments, it replaces the contents of the specified location with the specified value.

Example: memory.8 45f6b2 57

Places the 8-bit value 57 at the location ‘45f6b2’.

The port command allows control over the serial port being used by the monitor. It takes zero or one argument. Called with zero arguments it displays the port currently in use by the monitor. Called with one argument it switches the port in use by the monitor to the one specified. It then prints out a message on the new port to confirm the switch.

Example: port 1

Switches the port in use by the monitor to port 1.

The register command allows the viewing and manipulation of register contents. It can take zero, one, or two arguments. When called with zero arguments, the register command displays the values of all registers. When called with only the register name argument, it displays the contents of the specified register. When called with both a register name and a value, it places that value into the specified register.

Example: register g1 1f

Places the value 1f in the register ‘g1’.

The reset command resets the board.

The step command causes one instruction of the user program to execute, then returns control to the monitor. It can take zero or one argument. If no argument is provided, step executes one instruction at the current ‘pc’. If a location is specified, step executes one instruction at the specified location.

Example: step

Executes one instruction at the current ‘pc’.

The terminal command sets the type of the current terminal to that specified in the type argument. The only available terminal types are vt100 and dumb. This is used by the line editor to determine how to update the terminal display.

Example: terminal dumb

Sets the type of the current terminal to a dumb terminal.

The transfer or $ function transfers control to the gdb stub. This function does not actually need to be called by the user, as connecting to the board with gdb will call it automatically. The transfer command takes no arguments. The $ command does not wait for a return, but executes immediately. A telnet setup in line mode will require a return when executed by the user, as the host computer does not pass any characters to the monitor until a return is pressed. Disconnecting from the board in gdb automatically returns control to the monitor.

The unbreak command removes breakpoints from memory. It takes one argument, the location to remove the breakpoint from.

Example: unbreak 4ff5

Removes a previously set breakpoint at memory location ‘4ff5’.

Shows the amount of memory being used by the monitor, broken down by category. Despite its name, it has nothing to do with the usage of any other command.

The version command displays the version of the monitor.

These are common "EMACS" and "X" text editing escape sequences. Here are the keys for editing.

When developing and debugging CygMon, it is convenient to run CygMon itself as a downloadable application. There are some modifications that the developer may want to make temporarily, to debug CygMon. Reconfigure CygMon so it does not patch the exception handler. Have your test program call breakpoint explicitly. This combination disables CygMon in some serious ways, but many essential features remain functional and debuggable. Breakpoints can be administered, memory accesses can be tested, or registers fetched. You can debug the serial driver. But, you cannot resume execution, single step or test if a breakpoint has been hit. You can force CygMon through its context-save and context-restore. This is the plan; get all the basics working and verified, and then restore the exception patching capability.
 

MN103000 LSI User’s Manual
(1st Edition, Matsushita Electronics Corporation, November, 1996)

32-bit Microcontroller MN103002A LSI Manual
(Version 3.0, Matsushita Electronics Corporation)

Getting Started with eCos
(Sunnyvale: Cygnus Solutions, 1998)

eCos User Guides
(Sunnyvale: Cygnus Solutions, 1998)

eCos Reference Manual
(Sunnyvale: Cygnus Solutions, 1998)

Getting Started with GNUPro Toolkit
(Sunnyvale: Cygnus Solutions, 1998)

GNUPro Compiler Tools
(Sunnyvale: Cygnus Solutions, 1998)

GNUPro Debugging Tools
(Sunnyvale: Cygnus Solutions, 1998)

GNUPro Libraries
(Sunnyvale: Cygnus Solutions, 1998)

GNUPro Utilities
(Sunnyvale: Cygnus Solutions, 1998)

GNUPro Advanced Topics
(Sunnyvale: Cygnus Solutions, 1998)

GNUPro Tools for Embedded Systems
(Sunnyvale: Cygnus Solutions, 1998)

System V Application Binary Interface
(Prentice Hall, 1990)