The CR201 board is a simple microprocessor system.
The CPU is MC68LC302, the low cost
version of the classic 68302
Integrated Multiprotocol Processor.
The other principal components are RAM, flash, Ethernet and the DSL transceiver,
the latter being the only part different between the SDSL and IDSL versions.
The system is quite modest. There are 64 kbytes of RAM (static) and 256 kbytes of flash total. The CPU core inside the 68LC302 is the original M68000, none of the later frills. The board hardware is very simple and easy to reverse-engineer. There are no ASICs, FPGAs or any other programmable logic, just the listed principal components and a few standard SSI/MSI chips.
The flash chips with the firmware are socketed PLCC32s, two 29F010s for the 16-bit data bus, making this board perfect for hacking.
The use of a specifically telecom-oriented microprocessor rather than a completely generic one is very obvious in this application.
MC68LC302 has two on-chip Serial Communication Controllers (SCCs), which are very versatile serial ports capable of both synchronous and asynchronous operation with a bunch of protocols, all DMA. In the CR201 application one of these SCCs (SCC1) is used in the synchronous HDLC mode for the DSL WAN interface, and it is thus the second most important feature of the MC68LC302 chip after the CPU core for this application. MC68LC302 has many other features beyond the basic M68000 core, and a lot of them are used to eliminate glue logic and simplify the hardware, but beyond the SCCs they aren't particularly application-specific, just the usual stuff one would want in an embedded system.
What about the other SCC, SCC2? It implements the secret RS-232 debug port.
The WAN transceiver on the SDSL CopperRocket is the Bt8970 bitpump. No framer is used, and the bitpump is connected to the 68LC302 SCC1 as a very vanilla sync serial interface, which Motorola called NMSI (non-multiplexed serial interface).
Note that the bitpump is an 8970, not 8973, and thus has no built-in multirate clock synthesiser. It wants an input clock that's 16 times the symbol rate, and this clock is produced by an ICD2053 programmable frequency synthesiser from a 4.096 MHz reference (see clocking below). ICD2053 is a tiny SOIC-8 chip that's easy to overlook at first. It is programmed serially from two GPIO pins on the MC68LC302.
The bitpump has 4 separate sets of power supply pins (digital core, digital I/O pins, analog and PLL), but on the CR201s all 4 are connected to the same main +5V supply (see power supply below), i.e., the 3.3V core option is not used. This unfortunately means that the Bt8970 can't be easily replaced with an RS8973.
The IDSL version replaces the HDSL bitpump with an ISDN U interface transceiver chip, and on the CR201i that chip is the classic MC145572. The data path interface to it is tricky however, as described on this page.
The MC145572 offers several choices for its supervisory control and monitoring interface (selected by hardware strapping), and CR201i uses Motorola SCP (serial control port), another not-so-common interface very conveniently supported by the MC68LC302.
The Ethernet chip is Crystal LAN CS8900. This chip is intended for the ISA bus and implements the ISA interface on-chip with all of its idiosyncrasies, thus its operation in a non-ISA system like the CopperRocket is somewhat tricky. Even aside from the bus interface, the chip's functional design is rather counter-intuitive as we have found in the course of our Hack-o-Rocket project, but it can be dealt with. On the positive side, the entire 10BaseT interface is implemented on-chip, only the magnetics are external. The chip also has an AUI port, but it isn't wired on the CopperRocket.
The CS8900 has a 3-wire serial EEPROM attached to it. The EEPROM is not programmed to autoconfigure the CS8900 on powerup, but is there just for the software evidently. Each CopperRocket unit does have a unique MAC address assigned; it is printed on a sticker on the board, on another sticker on the metal enclosure, and stored in the EEPROM. It is not clear why one would be needed for a MAC-transparent bridge, but it's certainly very handy for our Hack-o-Rocket.
The CS8900 is probably the main reason why CM has used the MC68LC302 in the 16-bit mode, as they've used the 8-bit mode on the Netopia SDSL wanlet.
While it can take a ready-made system clock, the MC68LC302 is primarily designed to synthesise its system clock with its internal PLL from a lower frequency external reference. On the CR201 (both SDSL and IDSL) the external reference is 4.096 MHz and the MC68LC302 PLL is configured to multiply it by 6, producing a 24.576 MHz system clock. This clock is used to produce 9600 baud for the RS-232 debug port (happens to be exact!) and to run software timers.
On the CR201s the 4.096 MHz source is a can oscillator, and the same 4.096 MHz clock is fed to the ICD2053 frequency synthesiser for the bitpump.
The clocking arrangement is more interesting on the CR201i. The MC145572 requires a special 20.480 MHz pullable crystal, and one is indeed present on the board. In the NT (CPE) application there is no option of using an external clock; the crystal must be used and it must be pullable: the MC145572 uses the pullable crystal to adjust its clock to the CO (LT) timing on the line.
There is no separate 4.096 MHz can oscillator on the CR201i. Instead it just so happens that one of the clocks optionally put out by the MC145572 is 4.096 MHz, and this output is fed to the MC68LC302. However, since the ultimate source of this clock is the pullable crystal, the result is that the CPU system clock, the debug port baud rate and the clock for all software timers all float slightly with the clock received on the IDSL line!
The CS8900 also has its own 20 MHz crystal for the 10 Mbps Ethernet timing, but nothing else is derived from that clock.
There are 4 bicolor LEDs on the CopperRocket, each of which consists of
two LEDs under the same lens and can light red, green, orange or off.
The LEDs are labeled Power
, LAN
, DSL
and Data
,
but all 4 are controlled by software and identical in hardware.
The Power
LED is not hard-wired, nor does the LAN
LED have any
connection to the CS8900.
(The CS8900 Ethernet chip has LED drive capability, but it isn't used in this
design.)
All 4 LEDs are controlled by an 8-bit register implemented externally to the 68LC302, not by GPIO pins.
The CR201 is an all 5V circuit. The external power input is 7.5 VDC from an unregulated wallwart; 5V is made from that with a classic 7805 linear regulator.
CR201s has two 7805 regulators, a big one and a small one. The big one powers the main circuit, but what is the small one for? The separate small 7805 does not provide any of the power supplies for the bitpump as one may first be inclined to guess, instead it turns out to be for the ICD2053 programmable PLL clock synthesiser. All bitpump power supplies are fed from the main +5V regulator, separated only by inductive filters. The 3.3V core option isn't used and there is no 3.3V on the board at all.
CR201i has only one big 7805 regulator which powers everything.
Both CR201s and CR201i PCBs are replete with unpopulated footprints; what they are for we can only guess. Some of the GPIO pins serving non-understood purposes can be traced to those.