Functionality carried over from the preceding product:

• ​7 port USB hub with BC 1.2 charging capabilities
  
• ​​Electrical and mechanical interface to other ZK modules and equipment
  
• Test Platform Concept with single point flat flex connection
  
• GPS
  
• ​EMI features
  

​​Key upgrades from the preceding product:

• 266 MHz Coldfire MCF54452 to 1 GHz TI AM3352 Cortex A8
  
• ​​RAM increased from 64 MB 266 MHz DDR to 256 MB 400 MHz
  
• Flash increased from 32MB NOR to 16 GB (or larger) eMMC
  
• ​​Dual Gigabit Ethernet from single 10/100 TX
  
• USB device port upgraded to full OTG capability and BC 1.2
  
• Vastly Improve test and development functionality, including adding capability to test other system modules
  
• Compact Flash replaced by uSD card, USB flash Drive capability, "USB Gadget" capability, Wireless upload/download
  
• ​Linux
  

​​New Functionality:

• WiFi
  
• ​Bluetooth
  
• New test capabilities
  
• Incorporation of some internal interfacing functional blocks to eliminate chassis components and cabling

Introduction

Introduction

    I have always had a fascination with electronics. Growing up I first starting playing with electronics with an electronics project box kit designed for kids to learn about electronics. My introduction to programming came with a Casio programmable calculator. This was at a time when a basic electronic calculator was the most advanced “computer electronics” in the typical household. I quickly discovered the importance of efficient programming to squeeze as much program in the tiny space available and to improve execution times.

    My first foray into “real” programming on a “real” computer came with an Atari 400. I taught myself BASIC programming on this system…because there was no other means for a kid to learn programming at that time. I just picked up the books and started writing code. After tiring of BASIC and wanting to dig deeper into the internals of the computer I picked up a book on the 6502 instruction set and the technical manuals for the computer (which you can’t just buy at your local bookstore or download from the Web like you would be able to today), and proceeded to teach myself assembly programming. When computer programming was first introduced at my high school, I helped out with the class.

    UC Berkeley was my next destination. There I studied everything from transistors and semiconductor design, to digital design, to computer architectures, to operating systems, algorithms and theory. There were a couple projects that particularly stood out as favorites. There was the paper design of a 68000 CPU (which was a sophisticated CPU at that time) as if implemented using 74xx series logic. Another was building an EPROM programmer and emulator using an Atari 800XL which I had hacked to gain access to internal bus architecture. A class I also particularly enjoyed was the operating systems class because the lab projects were basically writing operating system functions. Another class was computer graphics where we wrote 3D rendering programs. For fun I obtained access to UC Berkeley’s “Magic” VLSIC layout tools and designed an IC for an SDRAM controller.

This product would not normally be the kind of product I most enjoy developing, but it was still quite enjoyable and rewarding in having built a custom Pentium platform. This was yet another project for which I was the sole engineer responsible for the entire development effort from product specification, design and development, bring up and validation, to demonstration of working product.

Testability of that original design was horrible. There was no consideration given to how this board would be tested in production. Testing required utilization of custom cables that were designed for chassis installation, not repeated insertion/extraction in a production test environment. Invariably cables would break and need to be replaced and in the mean time test would be at a standstill. (Even giving them “redundant” cables failed to alleviate production test ending up at a standstill - they would wait until after the backup broke to request new cables!) In addition, these connectors were physically challenging to insert/extract as there were designed for internal connections, not user connections - which only added to the tendency to breakage. And the test software was tedious, lacked coverage, and generally awful to work with.

​The first full redesign with the new processor (which incorporated USB 2.0 hosts that eliminated the problem parts) achieved the following:

• Full lead free process
  
• Eliminate obsolete and hard to get parts to eliminate hold ups on material acquisition
  
• Improved interface design to the display module
  
• Design for testability - no more custom cables required. All test connections made via a ZIF flat flex cable to a breakout test fixture. Flat flex cables are off-the-shelf and inexpensive to “stockpile” and have high circuit density to fit space constrained needs.
  
• Moved GPS module from cabled chassis mount module to mount directly on-board
  
• Improved yield to 99% and greatly reduced infant mortality rates to effectively zero due to PCA failure
  

When I first joined ZK Celletest Inc. my initial task was to assist testing and and debug of existing production units of their new MCF5474 based controller. This experience exposed many flaws that led to problems in both yield and testability.

​​Initial yield was poor on the that original design - almost as low as 50%. A large contributing factor to this was a mixed leaded/lead-free component mix. Also problematic was the use of 0.8mm BGA. Of course this shouldn’t be a problem in and of itself, but combined with the mixed process nature, this created a problem area. My initial redesign of this board was to go all lead free to eliminate the process problems that caused. I was eventually able to get yield up to >80% but as this design was not a “fresh” redesign but was an edit to the original PCB, there were still fab and assembly problem areas on account of the PCB. Not only was yield poor but so too was the infant mortality rate. This was related to the yield problems as poor solder would open circuit or the PCB would open circuit.

This project is in process. It is a next generation update for the Coldfire MCF54552 Embedded Platform for Cellular Test Equipment. This board replaces the existing Coldfire board. It is designed to the same mechanical specifications so as to reuse the other components of the system without redesign.

This was the first use of commercial third party router silicon. This architecture provided full bandwidth non-blocking routing. It entailed two fabric chips connected via a 250MHz DDR HSTL interconnect and each using a 300MHz SSTL DDR DRAM packet buffer. The system was controlled by a 500MHz AMD/Alchemy Au1500 MIPs processor.

The primary source of grief was the packet buffer DRAM interface of the fabric chips. This was a brand new IC product. Before actual design, a fair degree of effort was spent simulating the bus with HyperLynx. This showed problematic waveform behavior. This I tried to mitigate with a tuned termination architecture. What I was able to determine was that the package and I/O design of the fabric chip was problematic. The package design had poor power and ground allocation and placement. As well there were impedance mismatch problems in the package routing connecting IC to package ball. Once this was addressed, this made for a great deal of improvement. However it was still also the case that the I/O buffer impedance was not optimized correctly. I could measure that the I/O buffers of the DRAM chips were behaving superbly. This defect was ironic in that the I/O buffers in PHY chips from this company were actually quite good. So it’s not like that company did not know how to produce high performing I/O buffers on their silicon. In the end we could not quite obtain the 300MHz promised by the vendor on account of the shortcoming in their I/O buffers. If they had better optimized their I/O buffers I have no doubt that 300Mhz would have been readily achievable. This being the case, packet forwarding performance was slightly derated as well, Ixia load testing reflected this in that sustained full bandwidth could not quite be obtained. Had the 300MHz DRAM bus been achieved it would have met the packet performance expectations. But even still, it was at that time one of the better performing routers in that market space.

​This product also passed testing to EMI certification levels as well as environmental 4-corners testing - which I had to conduct.

An upgraded system version adds a third party scanner module. In portable application this requires a larger battery to handle the added power draw of the scanner module to provide sufficient run time.

This battery system is the same design as the preceding except in a different form factor. As we need a larger chassis for the scanner module anyway as well as a larger pack, we have the space to put the entire battery system on one PCB. This battery system can supply 60W to the system while from the battery or while simultaneously charging the battery at 3A.

The battery system for scanner systems

I also designed some boards to expand system functionality. The basic portability upgrade adds a battery system. This system is sized to power the system plus multiple USB connected devices for several hours of field use.

DX260 Controller Board with Portability System

DX260 Controller Board with GPS module

My job was to build an embedded platform that would potentially be embedded in a toy, take their pile of code running on a PC, and migrate it to this embedded platform. Obvious requirements were simplicity, low cost (ie. as low cost a processor as possible and minimal memory requirements) and low power. And since these toys interact, there would have to be provisions for message passing between toys as well as audio for the toys to “speak”.

A fundamental issue was the fact that their algorithms parse a large amount of data. Meaning that both the low cost CPU and low cost memory requirements were problematic. This was far more than could be handled by an 8 bit MCU and 64KB. A 32 bit micro was called for to handle the large data sets and processing power to parse it and handle all the other tasks. The choice was an ARM 720T Cypress EP7309. This was coupled with 2MB of flash. IR was chosen for communication for simplicity. A solution that had a near 180 degree field of view was created.

​The next step was to choose an OS. I looked at some candidates but I figured it would take some time to port to the platform, and to customize, and to build a software platform around it. And I was also concerned about the performance of a “general purpose” OS. I wanted it to be tuned to the specific needs of this project. So I figured I could just as easily and quickly write my own from scratch targeted exactly to my specific needs and optimized (cycle counted). Some key features needed were message passing for communicating between toys, audio playback, and blocking preemptive task scheduling.

​The last issue gets to part of the challenge of the porting process. The code was spectacularly well written in cleanliness, organization, and architecture. It was; however, written on a PC by a PC programmer - that is to say as if infinite PC power and memory is available. Task switching was done cooperatively and employed cycle wasting spin-waits. So one effort was to convert that to a blocking preemptive scheduled task approach. It was also written in C++, which was great - but no so good for an embedded application in those days. Initial compilation of the C++ resulted in a image over 500KB! After “de-C++-ifying” the code (which entailed getting under the hood of C++ to find where memory was being most consumed and re-implement in standard C in a smaller footprint), the image was reduced to about 124KB.

​The final software task was to devise a scheme for storing the database. On the PC they used a LUA script engine to build up the database in memory, so the database did not exist in any sense of an image that could be loaded. So I developed an image format and an algorithm to export the data structure in a linear image and manipulate all the links so as to point to the correct points in memory once the image was loaded into the flash of the embedded hardware.

I also did some cleanup work on that display unit also. The documentation package to build the boards was somewhat incomplete in that they were getting inconsistent results in the production runs. There were some PCB design issues as well as features that were inadequately specified such that if the PCB procurement was sent to a different PCB fab shop, problems would ensue as the different shop lacked the “tribal knowledge” to build the board correctly. So I also had the design cleaned up and documentation filled out to explicitly state the various nuances required to build the PCB correctly. That board has effectively been on autopilot since.

Some of the features needing correction were pullback of planes from various features, Correct specification of plated and nonplated hole sequencing, specification of gold-plated features, some adjustment to make for better mechanical fitting/clearances, modifications for better EMI shielding.

Not shown in these images is the work done to mitigate EMI issues. When I came on, there were a number of issues that I saw as potential EMI holes - gaps, unshielded connectors, etc. Eventually it became an issue to the point where it had to be addressed. I spent a fair amount of time reducing and eliminating EMI spectral spikes to where EMI was below measurable levels in the field. The task consisted of determining the EMI source based on frequency and taking corrective measures to mitigate the emissions such as EMI gasketing, shielded connectors.  Of particular problems were emissions from the LVDS link to the display and the CPU itself. The LVDS link is ironic since that is supposed to be a feature that it is low EMI due to the differential nature. The source seemed to be the on-chip PLL. With shielding, gaskets, connectors, filters, and beads I was able to take out several dB of emissions bringing levels down to acceptable margins.

This is our big system. It includes two scanners, an additional 7 port USB hub board (also with BC 1.2 capability for up to 1.5A per port) and employs two batteries to meet the power needs of this system. Power system output is 96W. Maximum charge current is 4A but is derated depending on the output load in order to constrain input current draw to 10A or less from a 12V source. In this system compactness of packaging was a goal. All three boards (controller, battery system, USB hub) plug directly together for minimal package size.

The battery system from the other side

Here is shown the test setup I designed to facilitate both software development as well as production test. Previously all those cables had to be connected directly to the board via pigtail connector cables. Now it is all handled via that flat flex cable. I also developed a test software suite (based on U-Boot) to create an automated test suite that addressed another sore spot for testability. Prior to my test platform, loading the test software was an arduous process and required much manual operation and was also lacking in coverage. My system can boot directly into U-Boot from which the test can be automatically run, log the results, and store board serialization and time stamping and other manufacturing data into EEPROM.

The original system did not employ any regulation on input or output which made for it problematic to account for the disparity between battery voltage needs and system voltage needs and external supply voltages. I solved this by adding a buck-boost regulator to output a fixed 15V to the system regardless of battery voltage. This also makes it possible to utilize 7.2V, 10.8V, or 14.4V battery packs. As our systems are typically deployed in vehicular applications for while doing drive test measurements, our power source is the vehicular 12V system. This would prohibit use of 14.4V packs and is marginal at best for full charging of 10.8V packs. So to handle this, I also include a boost supply to provide 20V to the charging system to allow for charging any battery pack voltage configuration including 14.4V.

Robert Miller

This one wasn’t a huge challenge from a hardware perspective but it was a fun project and was more interesting to me from a software perspective than a hardware design perspective. This particular project was a second stage proof of concept for a product this company was developing. They had some IP for a concept for toys that could interact with each other and create a “play space” narrative based upon the toys available. They had working code implemented on a PC to implement their concepts and simulate the interacting toys. They were ready to take their development to the next phase and implement it in actual dedicated embedded hardware.

One project I particularly enjoyed was the design of a rackmount network router. This product was a 24 port 10/100/1000 TX plus 4 SFP GBIC ports. I found this project particularly rewarding because of the complexity and the technical problems that had to be overcome. Also because I have a particular interest in networking.

I was the sole electrical engineering designer on this product responsible for this product design, bring up, and functional validation. I was also responsible for overseeing the simultaneous engineering development of a sister product based on this switch fabric silicon.

This company had been producing an embedded platform for a gaming system manufacturer. This was built around an 80486 embedded controller and had been in use for a number of years. The customer wanted to update the platform to support more modern functionality such as better graphics, dual displays, and generally more processors power. They also had their unique requirements. It required a high degree of GPIO to control and interface to various chassis electro-mechanical elements like lights, and buttons. It needed a high number of serial ports for interfacing to components such as bill takers and handling winnings payouts. It also needed to support DIP mounted ROMs in order to facilitate field signature verification of installed ROMs. And they wanted fanless.

​I based the design on an Intel 82855GMCH chipset (82801DA ICH4, 82802AB FWH, DA82562ET). I used the builtin graphics for the dual display graphics. I designed a Xilinx FPGA to interface to the PCI bus to add the DIP socketed memory, additional UARTs, and an SDCard interface, and the GPIO capability. The FPGA provided the capability to  accommodate a number of DIP memory package configurations under software control. Some of the sockets were battery backed to provide for battery backed SRAM capability.

​The BIOS used was provided by General Software. This was chosen because they supported the Intel 855 platform as well as being designed to be easily customized. I did the customization of the BIOS to this platform as well as added support for the access and control of the DIP socketed memory, the SD Card, and the additional UARTs. I also was able to install Windows XP and configure it to support the additional capabilities of the hardware including the dual display capability and the additional UARTs.

I demonstrated the system to the customer using the game Quake to demonstrate the video and audio capabilities of the system.

It was a challenging project in all aspects. I required developing an understanding of x86 platforms not only to design and build one, but to be able to add the required customizations and support that in the BIOS and OS. Some of the key challenges were the Xilinx design, BIOS modification and customization, and layout of the processor bus as one package had length matched package traces whereas the other did not, creating a layout challenge to obtain length matched traces.