A JOURNEY BACK TO 1994
So, if you have read this part of my story about microcontrollers, the title will make sense.
Also, that first part explains how we got here, in 2023, with NOS* HC05 parts and something that actually works.
Let The Adventure Begin
First things first, let's talk silicon. Here are the two parts that I received from Mantech. Note that they are at a much later mask revision than the part I had back in 1991 or the parts I had in 1994. These NOS* parts were made somewhere around 2004 given the date code, most likely part of the last batch made, just before Motorola SPS was spun off as Freescale Semiconductor Inc, and HC05 production ceased.
Also, that first part explains how we got here, in 2023, with NOS* HC05 parts and something that actually works.
Let The Adventure Begin
First things first, let's talk silicon. Here are the two parts that I received from Mantech. Note that they are at a much later mask revision than the part I had back in 1991 or the parts I had in 1994. These NOS* parts were made somewhere around 2004 given the date code, most likely part of the last batch made, just before Motorola SPS was spun off as Freescale Semiconductor Inc, and HC05 production ceased.
Next, I carefully constructed a suitable circuit on a breadboard to support this MCU. I also ordered a DC-DC converter to generate the needed Vpp voltage of 15.75V for EPROM programming. My circuit was constructed based on the information given in the HC05 databook. Later I modified the circuit to reflect information I obtained on MIDON Design's website since I was not getting any joy out of the bootloader - more on that later.
This is the very same breadboard used to play with one of the HC05 MCU I salvaged from CONLOG S-VSS units during June 1993. Originally got the breadboard from this guy in high school.
So if you look at the HC05 databook, you will notice it includes a schematic for a programmer. The programmer can connect to a host via serial interface and also, very interestingly, has provision for an EPROM from which data is copied and written to the EPROM in the HC05. I surmise this was likely a measure taken to reduce the number of gates on the die** and to allow manufacturers to make production line programmers. A bit of a pain really because it means that considerable effort is required to program this device if you don't want to use the internal bootloader. This is of course effort I have gone through before, with the successor to the HC05 series, the now also obsolete HC908 series which at least had EEPROM and a better bootloader that allowed a debugger to work. The concepts learnt with the HC908 back in 2004 came in very handy with this beast.
Troubles
If we look at the databook of this device, and the schematic above we notice that PD5 down to PD2 are used to select different bootloader functions. The logic level on these four pins are read directly after RESET and then the appropriate function is performed. One of these functions will dump the memory contents (RAM and ROM) via serial interface. Unfortunately this simply didn't work, so I began to look at things to try.
If we look at the databook of this device, and the schematic above we notice that PD5 down to PD2 are used to select different bootloader functions. The logic level on these four pins are read directly after RESET and then the appropriate function is performed. One of these functions will dump the memory contents (RAM and ROM) via serial interface. Unfortunately this simply didn't work, so I began to look at things to try.
The above table is indeed correct, but something was missed. That was the fact that the IRQ pin needs to be connected to a 9.4V DC supply. I only figured that out later.
In my attempts to get known code into the RAM and running I had a look around online. That's when I found PROG05, by Midon Design.
On the site they also had a link to an ancient program, PROG7, which programmed the device via the serial port using the PROG05 hardware. What was useful that it has a "test" function to enable the user to confirm the HC05 is OK.
So I built the circuit on breadboard for the HC05 as per Midon's schematic, and that's when I discovered that the IRQ pin had to be pulled to 9.4V approximately to force the MCU to execute from the bootloader out of RESET. This was not mentioned in the databook and I searched both the scanned copy and the later PDF version of the databooks and it's not there. However when I saw that there was a jumper on the IRQ pin on the MIDON board, I was immediately reminded of how the MC68HC908 series worked- the IRQ pin on that device had to be pulled to 7.2V to invoke the booloader, or in HC908-speak, the "Monitor ROM program".
Eventually after some fiddling I got the test function to work on the PROG7 application which was run in a virtual machine (Windows XP). Awesome!!
First Code
So as soon as PROG7 was working, I wrote a test program and it worked perfectly. The source code is included below
In my attempts to get known code into the RAM and running I had a look around online. That's when I found PROG05, by Midon Design.
On the site they also had a link to an ancient program, PROG7, which programmed the device via the serial port using the PROG05 hardware. What was useful that it has a "test" function to enable the user to confirm the HC05 is OK.
So I built the circuit on breadboard for the HC05 as per Midon's schematic, and that's when I discovered that the IRQ pin had to be pulled to 9.4V approximately to force the MCU to execute from the bootloader out of RESET. This was not mentioned in the databook and I searched both the scanned copy and the later PDF version of the databooks and it's not there. However when I saw that there was a jumper on the IRQ pin on the MIDON board, I was immediately reminded of how the MC68HC908 series worked- the IRQ pin on that device had to be pulled to 7.2V to invoke the booloader, or in HC908-speak, the "Monitor ROM program".
Eventually after some fiddling I got the test function to work on the PROG7 application which was run in a virtual machine (Windows XP). Awesome!!
First Code
So as soon as PROG7 was working, I wrote a test program and it worked perfectly. The source code is included below
More Troubles
So the next day when I wanted to work on this project some more, I noticed PROG7 couldn't connect to the HC05. Eventually after like 20 attempts it would suddenly connect and work. I also began to notice erratic behaviour in the code I wrote. The above code worked one day and wouldn't work the next. So I decided to have a look what was being sent via the serial interface using Device Monitoring Studio.
The databook says that, once the LOAD RAM and EXECUTE function is entered out of reset, the first byte received indicates how many bytes will be sent. So the first byte is the length (in bytes) and that is followed by the bytes of the program to be run from RAM, execution starting at address 0051. From examining the data sent by PROG7, I saw the problem. Not only did it send garbage for byte number 1, it also sent more than one byte, each successive programming attempt sending a different set of garbage bytes before the actual code appeared. Eventually these garbage bytes would be correct and the program would work, by absolute chance. The reason why this was happening was obvious- PROG7 was written for the 8088 and designed to run on DOS 3.3. On a modern 64 bit CPU the part of the code that computes the length byte to be sent, obviously overflows.
So what could I do about this? Well, there was no choice but to roll my own programmer and this is where PROG05 was "reborn". I created my own HC05 programmer, compiled in a modern langauge (Go) and with the ability to be compiled for Linux and macOS.
So the next day when I wanted to work on this project some more, I noticed PROG7 couldn't connect to the HC05. Eventually after like 20 attempts it would suddenly connect and work. I also began to notice erratic behaviour in the code I wrote. The above code worked one day and wouldn't work the next. So I decided to have a look what was being sent via the serial interface using Device Monitoring Studio.
The databook says that, once the LOAD RAM and EXECUTE function is entered out of reset, the first byte received indicates how many bytes will be sent. So the first byte is the length (in bytes) and that is followed by the bytes of the program to be run from RAM, execution starting at address 0051. From examining the data sent by PROG7, I saw the problem. Not only did it send garbage for byte number 1, it also sent more than one byte, each successive programming attempt sending a different set of garbage bytes before the actual code appeared. Eventually these garbage bytes would be correct and the program would work, by absolute chance. The reason why this was happening was obvious- PROG7 was written for the 8088 and designed to run on DOS 3.3. On a modern 64 bit CPU the part of the code that computes the length byte to be sent, obviously overflows.
So what could I do about this? Well, there was no choice but to roll my own programmer and this is where PROG05 was "reborn". I created my own HC05 programmer, compiled in a modern langauge (Go) and with the ability to be compiled for Linux and macOS.
.* NOS: New-Old-Stock. Sometimes, long after production ceases, unused stock of obsolete silicon (and other) products surface at electronic retailers.
** A compatible MCU was the Hitachi HD6305V0, the Japanese of course, made that device (windowed versions only) programmable as if they were normal 2764 EPROMs.
However the Hitachi MCU was not practical for low volume products as that series was usually mask programmed in the factory by Hitachi which put it out of reach of many, except CONLOG of course, who at the time, had their shareholder's deep pockets to cover the cost.
** A compatible MCU was the Hitachi HD6305V0, the Japanese of course, made that device (windowed versions only) programmable as if they were normal 2764 EPROMs.
However the Hitachi MCU was not practical for low volume products as that series was usually mask programmed in the factory by Hitachi which put it out of reach of many, except CONLOG of course, who at the time, had their shareholder's deep pockets to cover the cost.