Q: My H8 doesn't seem to go into low-power mode. Why?
The data sheet omits to tell you that the H8 doesn't go into minimal power mode until the voltage drops below 3V. If you graph the current/voltage, there's a bell-shaped curve. Therefore if you use a super-capacitor, a 3.6V Ni-Cad battery, or a 3V Lithium cell, there is a heavy drain until the charge is almost exhausted.
The solution is to use a 2V4 NiMH battery. NiMH (Nickel-Metal-Hydride) are preferable as they have no Cadmium (a toxic heavy metal).
Incidentally, this is quite a common problem with many micros. I guess most of them are designed with a process with 5V and 3V operation in mind. Therefore they don't want to go into power-down mode before the voltage falls below the minimum operating voltage of perhaps 3V less 10%. So 3V lithium is above 2V7, while 2V4 NiMH is below it.
Q: What other problems has the H8?
The H8 is available with Flash memory that you can boot load with just a PC which is great but the Flash devices are not currently available in PLCC packages. So they are not very convenient for the small volume user or hobbyist. Mind you, the H3048F is a 100-pin device and the biggest PLCC socket I've seen much is 84 pins. See my Surface Mount Tips page.
The larger H8 chips seem to have been pushed for silicon space and have crammed in extra Flash ROM at the expense of the I2C interface circuit. It can still bit-twiddle an I2C master interface but there is no on-chip hardware to implement an I2C slave interface.
Final gripe is that serial programming interface is fixed at 9600 baud, so boot-loading 128K of code takes 5 or 6 minutes! If you are been used to the PC, and developing code by many small (and safe) increments, and you (or more likely your employers) don't want to shell out 6000 for a hardware emulator, then you'll find this delay incredibly frustrating. Ten mods a day is an hour, for five days a week adds up to most of an extra day!
Q: How can I speed up the development cycle?
If using the serial mode, you have to use the H8's User Mode programming. There you have to write your own programming kernel to download into the on-chip RAM. Beware though: if you get the programming routine wrong then you can easily damage the Flash ROM permanently. Not very welcome if your one and only prototype has to get shipped off for time-consuming surface mount re-work.
Parallel programming is a lot faster: the chip behaves like an Hitachi Flash Memory chip. The down side is that you need a device progammer (which you probably have in a design department). And some way of connecting the two together. The first snag is physical connection. If your H8 design uses off-chip memory, then your a step nearer because most of the pins the H8 uses to access external memory are the pins a programmer uses to parallel-program the H8. Most, but not all, so you will require some cunning extra links. And of course, it is wise to have your design using socketed memory chips so that the programmer signals can reach the H8 via such a socket and a short length of ribbon cable.
Finally it is possible to write user-mode programming kernels which download the data through the PC's parallel port. The H8 has to mimic a printer. The interfacing circuit will depend heavily on your circuit design, but Hitachi do have an application note with example demonstration code. Note that this technique cannot speed things up for the initial software download, which has to be done in serial boot mode. So it can't speed up production programming, which is only done once per unit.