Expanding the MemoryThis was the hardware portion of our project. We had originally intended to actually construct a full-blown development board for this chip, but for reasons including getting parts in time, as well as the different number of configurations possible, we only prototyped an expanded memory configuration. Here are our notes as well as some neat ideas that a future ECE345 group should find very helpful in constructing a VERY featureful board. As a side note, there are several fairly low-cost and very well designed boards available. We'll list them at the end of this page. First, let's take a look at Motorola's suggested schematic. I'll walk you through it and what it's supposed to do. This is the result of almost reading almost 2000 pages of documentation from Motorola, so you'll be better off reading this. First take a look at Page 65 of the HC12 technical documentation. Here's a JPG of it, but you'll get better resolution if you print the page from the PDF file.  #include <foot.h>Now, I don't mean to knock the engineers at Motorola, but they do some REALLY wierd things in the schematic--I'll get to that in a bit. Let's start with the chips they recommend here. At the top left of the page, you see U1, MC34064, and you can download the datasheet for it here. This chip should probably be included in a development board for a couple of reasons. From the datasheet, you can see that it is a low-voltage sensor, designed to reset a CPU if the input voltage goes below 4.5 volts. Somewhere in the docs, I read a little blurb about possible damage to the chip if it is operated at a voltage below 4.5 volts. It also insures that the chip doesn't continue running with incorrect results if the power-supply is over-loaded and its output drops. Motorola is a little unclear as to how this should be connected. Pin 2 get's the same VDD as the CPU, 3 is grounded, and 2 should be tied to Pin 32 of the CPU along with the reset connection from the header JP1. Just below that, is the oscillator circuit. The HC12 provides two pins, EXTAL and XTAL, which essentially make up a CMOS inverter. The oscillator circuit here (and the one on the ECE Shop's board) is a generic Pierce oscillator. The other option for clocking is to provide EXTAL with a CMOS compatible clock, and leave XTAL unconnected. The first thing to note about the clock is that the input to EXTAL is twice the frequency at which the CPU actually runs. This is presumably why there is a 16MHz crystal on the ECE Shop's board, BUT Motorola discourages external memory connections at full speed (8MHz) because of timing issues. I would imagine that this statement was made some time ago, because memory chips are readily available with cycle times much less than 8MHz requires (125ns). Less than $20 will buy you a battery backed-up 32Kx8 static ram modules with a 70ns cycle time, so this is probably not a concearn that needs to be addressed--although we may find out the hard way that Motorla is right. For this reason, there should be some clock-division circuitry that allows a user-selectable clock frequency. There is also an issue running the CPU below 1MHz that involves the frequency required to program the flash memory (but you can get around it with software), so 8MHz, 4MHz, 2MHz, and 1MHz are probably all that need be available. This can easily be done with 4-bit binary counter, clocked at 32MHz, connect Q0-Q3 to the 4 inputs of a 4-1 MUX, and the two select bits to two dip switches. The output of that mux feeds EXTAL, and XTAL is left unconnected. A company called ECS (and probably others) makes a chip by the name ECS-300C-320 that performs this function perfectly. I'll include it in the datasheets with the final schematic, but essentially it works just like I described. It has 3 inputs A,B, and C; and 2 outputs. One output is 32MHz, the other is a divided clock based on the 3 inputs. Ground C, A and B become the select lines for the divider circuit. Below the oscillator circuit is the BDM header. This is an entirely superior way to program this chip besides the serial boot-loader thats on thie chip. Skip to the top right of the image. There are two little circuits, one is made up of a pair of DIP switches and pull-up resistors, the other shows how the pins VDD1, VDDX0 and VDDX1 should be connected. Essentially, they are cap'd to ground because certain signal transitions require a little more current than the chip normally does. Motorola also recommends that these cap's be as close to the cpu as possible. The dip-switch circuit is used to select the operating mode, which is one of Single-Chip, Peripheral, Expanded Wide, and Expanded Narrow. If you only wanted to run the CPU in one of these modes, there's no need for these switches, but here's where the ideas start to come in. One of the commercial boards I looked at had the CPU and serial chips on one board, and an optional expanded memory board could be added. With only the single chip board, MODEA and MODEB were tied with a resistor to ground, but were also connected to headers on each side of the board into which the memory expansion unit connected. Connecting a memory expansion unit connected the Address and Data busses, as well as tied the MODE inputs to the correct levels depending on whether a 8-bit bus or a 16-bit bus memory expansion module was connected. There's really no need for mode selection on the base unit, but a couple of switches to disable the external memory on a seperate module would be useful. I also have a neat idea about doing real-time DSP sampling using a module like this, and as soon as someone will show me how to work Autocad, I'll draw up some schematics to show you exactly what I mean. More on this later. As far as the memory bus goes, there are two expanded modes that work essentially the same. Wide (16-bit) mode and Narrow (8-bit) mode. In both modes, you loose PortA, PortB, and PortE, at least initially, but they can be rebuilt and emulated externally. This is why we didn't get a more featured board developed, a board for this CPU would be a challenging project itself. There are also issues with interrupt vectors getting moved in expanded modes that we weren't aware of, and it's too late to make it work correctly. Hopefully, this is where a future 345 group can start and get something really nice. Basically, PortA and PortB become address/data busses, and PortE becomes the control signals for the external memory. These registers and their associated Data-Direction-Registers are removed from the Register map, and accesses to them become external memory accesses. In the external memory hardware, you can catch accesses to these addresses and re-construct the functionality. This is, of course, assuming you don't move the register block, which can be done, but I don't see why you would want to. The HC12 has a byte-addressable, 16-bit memory addressing scheme. The internal memory is specifically designed to allow 16-bit loads/stores in a single cycle, but you can't do this externally. You can construct a 16-bit external bus, but accesses to odd words will be fetch in two cycles. If you try to get $FE01, the cpu will fetch $FE00 first, then fetch $FE02, and then piece the result together for you. If you try to get the data at some odd address M, you get (*(M-1)&0xFF00|*(M+1)&0x00FF) for those of you who speak C well enough. From here on out, I'm going to be speaking about a 16-bit expanded memory bus, because that's what we designed. There's really no reason to use an 8-bit bus, since ANY 16-bit move takes 2 cycles, where as on a wide bus, only odd accesses take 2 cycles. When an instruction accesses memory, what happens depends largely on what address is accessed. Most (all) of the memory block can be moved around in memory, again why you would want to is beyond me. The mapping precidence is as follows, and if anything overlaps, you talk to the highest priority device.
You can see from the above chart that this is where things start to get a little complicated. Mostly from the point of going from single chip to expanded modes. The interrupt vectors are stored from $FFC0-$FFFF, specifically the reset vector, which is stored at $FFFE-$FFFF. This is where the CPU finds the address to which it should jump after a reset. This address is normally located in flash, and in the case of the ECE Shop's HC12 boards, points to a little program that polls pins 51 and 52 to determine if it should jump to Debug-12 or just run whatever is in memory. This is also why the suggested schematic has one ram chip, and an EEPROM chip (which must be programmed externally--there's no way to program external flash from the CPU it self). They also use some logic that maps the memory funny so that most of the external memory isn't even used. When the CPU boots in any expanded mode, the internal FLASH is not only in a different place, but it's disabled all together. You can re-map it and enable it, but you have to have software running already, which is a little difficult to do if the CPU gets an erroneous address for the reset vector. Something about a chicken and an egg comes to mind here. This is where Background Debug Mode comes in. On reset, the CPU polls the state of BKGD(17), MODA(28), and MODB(27) pins to determine what mode to enter. If BKGD is LOW, it enters Background Debug Mode, and activates the BDM rom. This rom contains all the firmware commands for BDM, as well as new interrupt vectors to get into BDM. Most of BDM is implemented in seperate hardware on the CPU. Yes, you heard me correctly, completely seperate hardware. You can poke at memory, registers, etc while the CPU is executing user code. You can put the CPU in BDM mode even if it was booted in normal mode. You can even set and delete break-points all through this single pin and a clever one-wire serial protocol. These BDM cables and associated hardware sell for around $400, but if you read the details of the protocol, a well designed BDM cable could easily be created (another 345 group possibly) if the department is serious about making a worthwhile board for this chip. In BDM mode, you could upload user code to either internal memory or external memory, as well as working interrupt vectors (the BDM hardware lets you write to memory beneath BDM's memory if you want to). There's really no need for external rom either. Our design uses farily inexpensive battery-backed static ram modules. I'm not very certain about software support for BDM, because all of the different cables from different manufacturers work a little differently, but it's not a complicated protocol--there are all of about 40 different commands you can send it. The BDM connector is also designed to provide VDD and VFP, but this is probably not the best idea. You really only need 3 connectors, Reset, BKGD, and ground. For the real details, see section 18 of the technical documentation. The pin-out for the BDM header is on page 52. Now back to the memory bus, which is pretty simple. When you access external memory, (by the way, you can configure the CPU to show internal addresses and signals on the external bus. why?) the address goes out PortA and PortB. ECLOCK goes high, latching the address into the 74HC374 (you can also configure the cpu to drag out the length of external memory cycles for slow memory), the 74HCT138 is used to calculate which chip the access, and the data comes back into Ports A and B (only A in the example schematic). Our design uses two 32KB memory modules that cover the entire memory space of the CPU, giving you the most usable memory we could possibly come up with. If we get it done in time, we'll also add hardware to emulate the functionality of PortA, PortB, and PortE so you won't loose any of the base-chip functionality. While we're on the subject of memory cycles, there is a region called the Register Following Space, which is defined as the rest of the 1KB after the Register Block. If you move the register block, this space moves also. This is external memory, unless you map something over it, and there are different clock stretch bits to set. The clock stretch bits are how many core CPU cycles (up to 3) by which to lengthen an external bus cycle. Normal stretch bits are bits 2 and 3 of the register at $0013, and the RFS stretch bits are at bits 4 and 5. You will probably be able to set all of these to 0 (default) because we hope our final design will be fast enough to keep up with the HC12, but this is why they are there. Our design also includes hardware to slow the CPU down to one of 4 selectable clock frequencies, also for this reason (and maybe others). Now here's the best idea we could come up with for an expanded memory configuration. The chip and all the hardware to run it in single-chip mode, including a serial port (in case you still want to use the serial boot-loader), the BDM header, etc will reside on one board. On the top of that board is a 2-pin wide and 64-pin long headers (probably better with 32 pins on each side of the board). One half of these pins are where all of the Ports (A,B,E,DLC,S,T,and AD) connect. The other half of the pins go through the board to be inserted into a protoboard you'll also have to connect MODA and MODB, Power and Ground. In normal single chip mode, a jumper is placed on all the pins, making the protoboard connect directly to the CPU, but these jumpers can be removed and a second board can be stacked on top of the first board. This second board utilizes the connections from all the ports that are required for external memory access, and correctly sets MODA and MODB according to whether it is an 8-bit bus or a 16-bit bus on the memory board. This memory board also contains the hardware to emulate PortA, PortB, and PortE. Instead of the signals going straight from the CPU to the protoboard, now they go up to the memory board either to memory, or to the emulated Port hardware, which connects to the other half of the jumpers, back down through the first board to the protoboard. Why so complicated? You can make different boards for different applications. One can have just 64K of memory on it. The other, a ROM socket or two (since the pin-outs for rom and ram don't match, they'll have to be on different boards). My favorite idea is a real-time DSP sampling board. A board could fairly easily be designed to work as follows. It would have 2 RAM chips, of whatever size is appropriate, a clock for the sample timing, antialiasing filters, and a counter that can run through the entire addressable space of one of the RAM modules. Accesses from the CPU (reads and writes of data that have already been processes) are mapped to one RAM module, while the ATD samples and fills (and the DTA reads and generates signals) from the second ram module, which logically occupies the same memory space. When the counter reaches its terminal count (all the memory is full), some simple hardware would logically swap the Memory chips and light up the interrupt pin on the HC12. Now the CPU get's new data and the ATD/DTA hardware goes to work on the other data now in the other RAM module. It's just a matter of some latches, a few muxes and a counter. For this type of board, you'd also have to pass it the voltage reference inputs for the ATD, but you can just make the header larger. The normal expanded memory board can ignore what it doesn't need. Sorry for being so long winded, but I just wanted to put everything I know about this chip out there to be as useful to anybody else as possible. When we get it drawn up, we'll put our schematic and part numbers below. If any future 345 student is actually interested in physically constructing this, feel free to email me, CJ, for any clarifications or with any questions. That email should work for several years from now. Incedently, you can purchase the BDM modules from www.kevinro.com for about $60 in a kit, or $90 assembled if you are looking for one now. That's the best price I've found so far, but it appears to be a dude that is building them in his spare time or something similar. There's another one that a lot of people use made by P.E. Micro (www.pemicro.com) but its closer to $400. Heres the schematic for a development board with a 16-bit expanded memory bus.  I apologize for the poor quality, but Orcad's software makes it a little difficult to export their files to images. This should be high enough resolution to enlarge it in Photoshop and obtain a readable document. This page created by: CJ Oster Last Modified: April 23rd 2003 |
|
