NEC CEB-V850/SA1 Hardware Setup

The CEB-V850 board is fitted with a socketed EPROM. The internal Flash of the V850 supplied with the CEB-V850 boards defaults to vectoring into this EPROM. A GDB stub image should be programmed into an EPROM fitted to this board, and a pre-built image is provided at loaders/v850-ceb_v850/v850sa1/gdb_module.bin under the root of your eCos installation.

The EPROM is installed to the socket labelled U7 on the board. Attention should be paid to the correct orientation of the EPROM during installation.

When programming an EPROM using the binary image, be careful to get the byte order correct. It needs to be little-endian. If the EPROM burner software has a hex-editor, check that the first few bytes of the image look similar to:

00000000: 0018 8007 5e02 0000 0000 0000 0000 0000

If the byte order is wrong you will see 1800 instead of 0018 etc. Use the EPROM burner software to make a byte-swap before you burn to image to the EPROM.

If the GDB stub EPROM you burn does not work, try reversing the byte-order, even if you think you have it the right way around. At least one DOS-based EPROM burner program is known to have the byte-order upside down.

The GDB stub in the EPROM allows communication with GDB using the serial port. The communication parameters are fixed at 38400 baud, 8 data bits, no parity bit and 1 stop bit (8-N-1). No flow control is employed. Connection to the host computer should be made using a dedicated serial cable as specified in the CEB-V850/SA1 manual.

Installing the Stubs into ROM

Debugging with the NEC V850 I.C.E.

eCos applications may be debugged using the NEC V850 In Circuit Emulator (I.C.E.) A PC running Microsoft Windows is required in order to run the NEC ICE software and drivers. In addition Red Hat have developed a “libremote” server application named v850ice.exe which is used on the PC connected to the I.C.E. in order to allow connections from GDB.

The I.C.E. must be physically connected to a Windows NT system through NEC"s PCI or PC Card interface. A driver, DLLs, and application are provided by NEC to control the I.C.E.

v850ice is a Cygwin based server that runs on the NT system and provides an interface between the gdb client and the I.C.E. software. v850-elf-gdb may be run on the Windows NT system or on a remote system. v850-elf-gdb communicates with the libremote server using the gdb remote protocol over a TCP/IP socket. v850ice communicates with the I.C.E. by calling functions in the NECMSG.DLL provided by NEC.


Run the v850-elf-gdb client to debug the V850 target. It is necessary to issue certain configuration commands to the I.C.E. software. These commands may be issued directly in the MDI window or they may be issued from the gdb client through the "monitor" command.

On the Cosmo CEB-V850 board, on-chip Flash is mapped at address 0x0, the on-board EPROM at 0x100000 and the on-board RAM at 0xfc0000. Since a stand alone V850 will start executing from address 0x0 on reset, it is normal to load either an application or a bootstrap loader for Flash at this address. eCos programs may be built to boot from Flash or the on-board EPROM. If building for the on-board EPROM, it would be expected that the Flash will contain the default CEB-V850 flash contents. An ELF format version of the default contents may be found in the eCos distribution with the name v850flash.img.

In stand alone operation, normally the code in this flash image would have been programmed into the V850 on the Cosmo board, and this would cause it to vector into the on-board EPROM to run the application located there. In the case of eCos, this application may be a GDB stub ROM application, allowing the further download to RAM over serial of actual applications to debug.

As an example, we shall demonstrate how to use the I.C.E. to download the v850flash.img and GDB stub EPROM image using I.C.E. emulator memory only, and not requiring any actual programming of devices.

v850-elf-gdb -nw (gdb) file v850flash.img (gdb) target remote localhost:2345 (gdb) monitor reset (gdb) monitor cpu r=256 a=16 (gdb) monitor map r=0x100000-L 0x80000 (gdb) monitor map u=0xfc0000-L 0x40000 (gdb) monitor pinmask k (gdb) monitor step (gdb) monitor step (gdb) monitor step (gdb) monitor step (gdb) load (gdb) detach (gdb) file gdb_module.img (gdb) target remote localhost:2345 (gdb) load (gdb) continue

NOTE: The four "monitor step" commands are only required the first time the board is connected to the I.C.E., otherwise the program will fail.

This is because of a limitation of the I.C.E. hardware that means that the first time it is used, the "map" commands are not acted on and the addresses "0x100000" and "0xfc0000" are not mapped. This can be observed using the command "td e-20" in the MDI application"s console to display the trace buffer, which will show that the contents of address 0x100000 are not valid. Subsequent runs do not require the "monitor step" commands.

It is unusual to load two executable images to a target through gdb. From the example above notice that this is accomplished by attaching to the libremote server, loading the flash image, detaching, reattaching, and loading the ROM/RAM image. It is more normal to build an executable image that can be executed directly. In eCos this is achieved by selecting either the ROM or ROMRAM startup type, and optionally enable building for the internal FLASH. The I.C.E. emulator memory can emulate both the internal FLASH and the EPROM, so real hardware programming is not required.

Upon running this example you will notice that the libremote server does not exit upon detecting a detach request, but simply begins listening for the next attach request. To cause v850ice to terminate, issue the "monitor quit" or "monitor exit" command from the gdb client. v850ice will then terminate with the next detach request. (You can also enter control-c in the Cygwin/DOS window where v850ice is running.)


eCos and the V850 I.C.E. libremote server have been written to work together to allow debugging of eCos threads. This is an optional feature, disabled by default because of the overheads trying to detect a threaded program involves.

Obviously thread debugging is not possible for programs with "RAM" startup type, as they are expected to operate underneath a separate ROM monitor (such as a GDB stub ROM), that itself would provide its own thread debugging capabilities over the serial line. Thread debugging is relevant only for programs built for Flash, ROM, or ROMRAM startup.

To configure the libremote server to support thread debugging, use the command:

(gdb) monitor syscallinfo ADDRESS

at the GDB console prompt, where ADDRESS is the address of the syscall information structure included in the applications. In eCos this has been designed to be located at a consistent address for each CPU model (V850/SA1 or V850/SB1). It may be determined from an eCos executable using the following command at a cygwin bash prompt:

v850-elf-nm EXECUTABLE | grep hal_v85x_ice_syscall_info

At the current time, this address is 0xfc0400 for a Cosmo board fitted with a V850/SA1, or 0xfc0540 for a Cosmo board fitted with a V850/SB1.

So for example, the GDB command for the SB1 would be:

(gdb) monitor syscallinfo 0xfc0540

Given that the syscallinfo address is fixed over all eCos executables for a given target, it is possible to define it on the libremote command line as well using the "-t" option, for example:

bash$ v850ice -t 0xfc0400
v850ice: listening on port 2345