Log for development on the H8

The installation of the GNU tools as detailed at the h8/300 hosted at sourceforge worked right away.

Every file that will go on the board is compiled into the SRecord binary formatted file 'Main' Here's an attempt to describe each:

Makefile:

It includes several options that make downloading the final binary onto the board a functional code, this includes:
The address at which the source should start mapping its symbols (-Ttext, given a valid linker scrip file -see h8300.ld) as well as the Map file to generate and the sequencing of objects in the final binary (l.S and Main.c). The makefile is also used here to generate the SRecord binary file.
Basically, the sequence would be:
  • Compile the assembly part of the code : l.S --> l.o
  • Compile the main code : Main.c --> Main.o
  • Generate binary linking those objects : ld -Ttext 0xF780 -Th8300.ld l.o Main.o -o Main
  • Convert this compiler defined binary formatted output to an SRecord using objcopy.
That's the idea.

h8300.ld:

The linker script file.
Specifies the organization of binary object downloaded onto the board.
  • .text represents where the actual text code will be located.
  • .data represents whrere the initialized variables will go (in memory).
  • .bss represents where the uninitialized variables are destined to.

The dot after each of these symbols could be a memory location, the dot here represents the location given in the Makefile by the -Ttext (for the first) option.
Here 0xF780

h8300.Map:

After compilation a layout of the binary code symbols can be output using the -Map Makefile option.
This results from the setting of the load address in the Makefile as well as the layout format given in h8300.ld.

l.S:

This is a cut-down version of the C runtime file (crt0.o).
Sets the stack pointer to the bottom of RAM and Jumps to the C startup symbol.

iodefine.h:

Provided by the Hitachi development tools, this file is a definition of all structures representing the onboard registers and their memory locations .

H8BootSCI.c:

This is the implementation of the boot mode protocol describe in chapter 7 of the manual, the sequence of steps to take in order to download code onto the board.
In addition to downloading the code, the last step of this code keeps listening for information coming in from the board.
Also the size of the SRecord file is calculated in here.
In order to have this Loader work properly, the terminal settings need to be switched to non-canonical mode using "stty -F /dev/ttyS0 -icanon" as well as the parameter set to &=ICANON in the H8BootSci.c file.

Bits.c:

Understanding bit settings, PCR and PDR of port 5.
PCR5 is initialized so that bit 7 and 1 are output.
bit 7 controls the LED SCL, it is initialized to OFF.
bit 1 controls the pin on which I intend to put the LED.
It is initialized to 0.

While loop:
keep reading value of bit 1. If the value is not 0, which happens when 5 Volts go through pin 22 (bit 1 of P5) then turn LED ON and set bit 1 value to 0 again.
If the value is 0 then turn LED OFF.

I am happy about this code because it confirms that setting PCR5 and PDR5 is not as strange as I thought, it is made clear here that it is possible to set a pin as OUTPUT, set a value to it and then set all pins to INPUT and keep reading this pin with the last value set.

On_Off.c:

An implementation of the example given in tutorial A.
On_Off switches the SCL LED ON and the OFF after a second.
The contribution of this code was to actually see a working result of setting bits in IO pins and also applying a delay.

SCI3.c:

This code is an attempt to understand what is the reason for the serial communication to stop sending values read from registers to the laptop (receiving host).
As long as the board is in boot mode (running with the boot program area) the values are sent without any problem, the receiving host then displays the value of any register...but once the reset switched is pressed, the transmission is stopped, although code is still running on the board since any code playing with the LED or other (see BitSet.c) is functional.
So I hardcoded the values of the SCI3 communication registers to be identical to the ones read during a functionning and tried to use the LED as an indicator of a change in any of those registers after board is reset.

This has still not been successful.

The terminal settings to properly send and receive information to the board have behaved strangely. It is unclear as to what needs to be done specifically but switching canonical mode for the terminal on and off appears to make the communication work somehow... setterm /dev/cua1 -canon

In Cygwin, strange problem setting terminal settings using stty.
Read in a post to export CYGWIN=reset_com, it seems to be working.

Setting the Serial communication baud rate for asynchronous transmission after transfer of the bootloader goes as follows:
    SCI3.SCR3.BIT.RE=1;
    SCI3.SCR3.BIT.TE=1;
    //TRANSMIT
    SCI3.TDR=b;    
    //LOOP UNTIL TRANSMIT ENDS
    while(SCI3.SSR.BIT.TEND!=1);
    //LOOP UNTIL RECEIVE HAPPENS
    while(SCI3.SSR.BIT.RDRF==0);
    SCI3.SCR3.BIT.RE=1;

Inline Assembly Notes

Inline assembly is essential to manipulate data transfer from RAM to ROM. Here are a few examples on how I use it on the H8 Tiny.
The operands numbers are incremented and relate to the number as they appear in the template form. As a general rule the form of an inline-assembly instruction is as follows:
asm volatile ("instr op1,op2" :
              output :
              inputs :
              clobber list);

The inputs are determined by the operand numbers %0,%1...
The following snippet writes data at RAM address ram_address
  asm volatile("mov.w %0,@%1" ::
	       "r" (data),"r" (ram_address));
The following retrieves data from ram_address into register that stores data
  asm volatile("mov.w @%0,%1"::"r" (ram_address),"r" (data));
BSET a bit of a specific byte
asm("bset %1,%0" : :"m" (dst) , "g" (bitno));
ADD two bytes into an output register
  asm volatile("add.w %0,%1":"=r"(b):"r"(a),"r"(b));
Declaring a function to be in a specific section can be done by
extern void func() __attribute__(section("bar"));

Writing to Flash

The following code allows to write to the Flash memory. Data is written to flash in blocks of 128 bytes that are downloaded through the serial port. Once all the data is downloaded the code branches to the beginning of the code in Flash memory @0x000.

Interrupts Handling

The vector table holds the address of the Interrupt Service Routine (ISR). This can be written in C as
void *INT_Vectors[] __attribute__((section(".vectors"))) = {
        ....
	// 7 NMI 
	(void *) INT_NMI,
	// 8 TRAP
	(void *) INT_TRAP1,
	// 9 TRAP
	(void *) INT_TRAP2,
	...};
the attribute section .vectors tells the linker to place that array in the vectors section that lies in the specified memory region (from 0x0000 to 0x0033). The linker must contain a section that declares the .vectors area such as :
SECTIONS
{
	.vectors 0x0000 :
	{
	  *(.vectors)
	} >rom
	...
The name of the Interrupt service routines must be declared and implemented somewhere, the header file is like :
...
extern void INT_NMI(void) __attribute__((interrupt_handler));
// vector 8 TRAP
extern void INT_TRAP1(void) __attribute__((interrupt_handler));
// vector 9 TRAP
extern void INT_TRAP2(void) __attribute__((interrupt_handler));
...
The attribute interrupt_handler tells the linker that this is the ISR for some interrupt vector.

Finally, the implementation of the Interrupt handler :
...
void INT_NMI(void) {/* sleep(); */}
// vector 8 TRAP
void INT_TRAP1(void) {/* sleep(); */}
// vector 9 TRAP
void INT_TRAP2(void) {/* sleep(); */}
...
The main code has to enable all Interrupts first, such as the Interrupt enable flag in CCR and all other Interrupt specific enable flags.

Links

The main homepage from Avnet Marshall
http://www.halsp.hitachi.com
http://h8300-hms.sourceforge.net/
http://www.objsw.com/CrossGCC/FAQ.html
Some info found in newsgroups
A tutorial for H8S
Renesas link to H8 3664
Why a Ladybug as a logo ?
Pointers in C




Documentation

H8/300H C/C++ Compiler's User Manual
EDK3664 User Manual
GNU Pro Toolkit Manual
Flash Dev Toolkit User's Guide
H8/3664 Hardware Manual
EDK3664 Tutorial Manual
GCC Manual
GNU CC Inline Assembly How To
Declaring Function Attributes in GNU CC

Kernels

BOOT mode micro kernel BINARY
BOOT mode micro kernel SRECORD

BOOT mode main kernel BINARY
BOOT mode main kernel SRECORD

Write Module BINARY
Write Module SRECORD

Erase Module BINARY
Erase Module SRECORD

USER mode main kernel BINARY
USER mode main kernel SRECORD

USER mode micro kernel SRECORD
User mode test program SRECORD

The GNU-C Flash Programming code