Dielectric Absorption

Lately I've learned of Dielectric Absorption in capacitors. The effect is caused by the dielectric, which basically can not follow voltage changes quickly enough because of internal friction of its dipoles.

One interesting behavior is that if you completely discharge a capacitor, its voltage will increase again over time as if it was charged.

In the Wikipedia article, a measurement procedure following the IEC/EN 60384-1 standard is described:

1. charge the capacitor to its nominal voltage for 1h
2. discharge it across 5Ω for 10 seconds
3. wait for 15 minutes
4. measure its voltage

Depending on the dielectric material, it will re-charge up to 15%. :-O

I've conducted that experiment with a random 16V 1000µF aluminium electrolytic capacitor and got 0.6706V, which is 4.19%.

The image shows the re-charging curve over nearly 2 weeks (note the logarithmic time scale). The voltage reached 1.083V (6.30%).

Just think of a capacitor in a microwave with 4kV. 6.3% would be 252V.
That is dangerous!

Including ADC+DSP+DAC in SPICE Simulation

Ever wanted to include an ADC + DSP/MCU + DAC chain in your SPICE analog circuit simulation? Here is an approach where you can directly use the program code of your DSP or microcontroller (MCU) firmware. You only have to program a small adapter routine to simulate ADC and DAC behavior. Then all this can be integrated in the SPICE simulation.

How does it work?

Ngspice is the next generation of the SPICE analog circuit simulator. It includes XSPICE which supports custom so called "Code Models", i.e. models for circuit element which are provided by the user as C routines. I've developed such a Code Model which simulates periodic ADC sampling and DAC output updates. For every period the adapter routine is executed which itself can execute the original DSP/MCU firmware code. So, the DSP/MCU firmware is an actual component in the SPICE simulation.

Example: FIR Filter

Consider a finite impulse response (FIR) Filter implemented in a DSP or MCU, e.g. as an audio processor.

As an example, an 11-th order FIR low-pass filter was implemented as a simple C function. The input signal was provided by another custom code model. This was configured to generate a sweep from 100Hz to 22kHz with logarithmic increments within 220ms. The sampling rate of the FIR filter was set to 44.1kHz. The following image shows the input and output signal (orange in1 and blue out1, respectively) as well as the output signal filtered by a 10kHz RC low-pass reconstruction filter (red vout). The amplitude of out1 clearly shows the filter characteristics with stopband ripples as predicted by Matlab's fvtool.

Application: Source Measurement Unit

A Source Measurement Unit (SMU, also called SourceMeter) is an instrument which does precise voltage and current measurements as well as constant voltage or constant current supply. It can operate in all four quadrants (source and load for positive and negative voltages and currents). The main application of the above mentioned Code Model is the development of an SMU with a fully digital control loop. The only analog part is a Class AB push-pull output stage, everything else, especially the control algorithm, is implemented by software.

Note that this enhances the above FIR filter example to a closed loop setup.

To be precise, there will be more analog components: translate DAC output voltages to the FET gate voltages, translate actual output voltage to ADC input voltage, shunt resistors for current measurement, ... BTW, the shunt in the positive supply is necessary to set a small but controlled quiescent current through both FETs.

The above mentioned Code Model will be used to test and optimize the control algorithm together with the analog circuitry in a SPICE simulation. The source code can then be used without modifications when compiling the DSP firmware. An ARM Cortex-M4F with floating-point support will be used as DSP. These are readily available with 120MHz, which allows roughly 1200 instructions for the control algorithm at a sampling rate of 100kHz.

LED Tubes

Retrofit LED lamps for light bulbs in E27 and E14 screw sockets and for halogen bulbs are easily available, even at food discount stores. Lately, also LED tubes as replacement for fluorescent tubes are available, sometimes at suprisingly low prices.

How do they work? First, how do fluorescent tubes work? The tube has four contacts, two on both ends, between each there is a filament. In the figure below the full circuit is shown: There is a series connection of the inductor as ballast, the right filament, the starter, and the left filament.

When switched on, the full 230V AC are across the starter. "[...] There will be a glow discharge across the electrodes in the starter lamp. This heats the gas in the starter and causes one of the bi-metallic contacts to bend towards the other. When the contacts touch, the two filaments of the fluorescent lamp and the ballast will effectively be switched in series to the supply voltage. The current through the filaments causes them to heat up and emit electrons into the tube gas by thermionic emission.

In the starter, the touching contacts short out the voltage sustaining the glow discharge, extinguishing it so the gas cools down and no longer heats the bi-metallic switch, which opens within a second or two. The current through the filaments and the inductive ballast is abruptly interrupted, leaving the full line voltage applied between the filaments at the ends of the tube and generating an inductive kick which provides the high voltage needed to start the lamp."

The current flows through the inductor and through the ionized gas inside the tube. The filaments are now used as mere electrodes. Due to the voltage drop across the inductor, the starter (which is in parallel to the lamp) sees a lower voltage (approx. 110-150V) which is below its ignition voltage.

"The lamp will fail to strike if the filaments are not hot enough, in which case the cycle repeats; several cycles are usually needed, which causes flickering [...]" (quoted from http://en.wikipedia.org/wiki/Fluorescent_lamp).

For the LED tube you have to replace the starter with the supplied replacement starter, which is a simple short. One end of the LED tube itself is also a short. Therefore the full 230V AC are seen on the other end of the LED tube. This is where the internal power supply is located. This is smart, because you can install the LED tube in either way, it will always work.

Note that with this simple replacement starter, the inductor is still in series, which causes ohmic losses. Most LED tubes also allow the direct application of 230V AC to the power supply pins. Be sure to measure the resistance on both ends to tell the short from the power supply apart. The short should be near 0 Ω (I measured 0,3 Ω including contact resistances), the power supply of my tube varies strongly around 900 kΩ, and the resistance between both ends is too high to measure. If you modify a whole luminaire, be careful not to insert the LED tube with swapped sides, because this will short circuit the 230V line voltage.

Measurement Framework for GPIB, USB-TMC, LAN, ...

The GPIB bus is used to connect and control measurement instruments like multimeters, spectrum analyzers, scopes, ... Most professional measurement instruments offer a GPIB connector, and sometimes additionally Ethernet (LXI), USB (USB-TMC) and RS232 connectors, which offer the same remote control functionality.

Setups with one or more measurement instruments and remote controlled sources are used in production test, device characterization, ... Therefore a controller, usually a PC, sends commands to all instruments and queries measurement results. The test and measurement procedure is implemented as a custom program, which links to libraries to send the commands and receive the results.

The measurement framework pas-gpib provides such libraries to communicate via GPIB, LAN, USB and RS-232 with measurement instruments. It is an open source project hosted at GitHub fully implemented with FreePascal. It was successfully tested with Agilent 34410A multimeter, LeCroy WaveJet 354A and 324 scopes and Keithley 2602A SourceMeter. Demo programs how to use the framework with these instruments are included.

All interested users are invited to test pas-gpib and to contribute more functions, more devices and even more communication protocols. Your feedback is very welcome! Let me know, how you could solve your test and measurement requirements using pas-gpib!

SVF Interpreter for VHDL Testbench

Digital chips often contain a JTAG port, which is used to implemente boundary scan and to access internal functionality of the chip, like programming and debugging.

One widespread "standard" to specify JTAG operations is SVF (Serial Vector Format). Many tools can generate SVF files which are then used to operate the JTAG signals of a chip, e.g. with Lib(X)SVF.

As everything in chip design, the JTAG functionality also has to be verified during development. At this time, all modules as well as the whole chip are simulated. vhdl-svf provides an SVF interpreter, written in pure VHDL, which reads a SVF file and exercises the JTAG signals. It is inteded to be integrated in a testbench to verify the chip design.

MSP430 LaunchPad with Debian

The TI MSP430 are ultra-low-power 16-bit RISC microcontrollers. Since a while, TI sells eval kits called "LaunchPad" for $ 4.30 for their "value line" (i.e. cheap) MSP430 products. These have a debugging and programming interface (USB).

To use the LaunchPad with Debian GNU/Linux (sid, as of 2012-10-04), some packages have to be installed

aptitude install gcc-msp430 gdb-msp430 \
  msp430-libc msp430mcu mspdebug binutils-msp430

Debugging

mspdebug supports the LaunchPad for programming and debugging using its rf2500 driver (which is also used for the eZ430-RF2500 and Chronos watch). It is started with

mspdebug rf2500

This program offers a powerful command line interface for memory dump, programming and debugging. It also has a GDB remote stub, so you can debug your programs with GDB. Connecting via the debugger stops the currently running program (presumably the preloaded demo program). To continue execution, type

run

and press ^C to stop again. This will show the current register values and a short disassembly.

(mspdebug) run
Running. Press Ctrl+C to interrupt...
^C
    ( PC: 0fc86)  ( R4: 00282)  ( R8: 0ab57)  (R12: 00000)  
    ( SP: 0027a)  ( R5: 05a08)  ( R9: 0fb5b)  (R13: 0fd90)  
    ( SR: 000dd)  ( R6: 0adff)  (R10: 0aee2)  (R14: 00000)  
    ( R3: 00000)  ( R7: 0fa3f)  (R11: 0bf73)  (R15: 0ffff)  
0xfc86:
    0fc86: 30 41                     RET     
    0fc88: f2 40 0a 00 00 02         MOV.B   #0x000a, &0x0200
    0fc8e: 03 3c                     JMP     0xfc96
    0fc90: 92 42 70 01 72 01         MOV     &0x0170, &0x0172

You can switch on beautifully colorized output:

opt color true

My LaunchPad came with a MSP430G2231. It seems that newer LaunchPads come with a different device. Features of the MSP430G2231:

• 1.8-3.6V
• 16MHz
• 2kB Flash, 128B RAM
• 10-Bit ADC, 8 IOs, WDT, Timer, USI (SPI, I2C)

Memory map:

• F800h-FFFFh: Flash, 4 segments of 512 bytes
• 1000h-10FFh: Information Memory, 4 segments of 64 bytes, stores calibration values!
• 0200h-027Fh: RAM
• 0000h-01FFh: SFR, Peripherals
• FFC0h-FFFFh: Interrupt Vectors, Reset = FFFEh

The LaunchPad has a red LED (connected to P1.0) and a green LED (P1.6) and a button (P1.3).

After reset, the 16-bit value at FFFEh is read. This is used as initial value of the PC register to start execution. Let's examine the boot process!

(mspdebug) md 0xFFFE 2
    0fffe: c2 fc                                           |..              |
(mspdebug) dis 0xFCC2
0xfcc2:
    0fcc2: 31 40 7e 02               MOV     #0x027e, SP
    0fcc6: b2 40 6e fd 36 02         MOV     #0xfd6e, &0x0236
    0fccc: b2 40 6e fd 38 02         MOV     #0xfd6e, &0x0238
    0fcd2: b0 12 66 fd               CALL    #0xfd66
    0fcd6: 0c 93                     TST     R12
    0fcd8: 02 24                     JZ      0xfcde
    0fcda: b0 12 8e fb               CALL    #0xfb8e
    0fcde: 0c 43                     CLR     R12
    0fce0: b0 12 00 f8               CALL    #0xf800
    ...

Before our own program is programmed, we should save the Flash memory content. The following command will save 2048 bytes, starting at F800h, to the Intel HEX file MSP-EXP430G2-2231.ihx.

hexout 0xF800 2048 MSP-EXP430G2-2231.ihx

During playing, I had an accident, inadvertently typing "mw 0xFFFE 2" instead of "md 0xFFFE 2" which overwrites the value C2h at FFFEh with 02h. It was not possible to correct this with "mw 0xFFFE 0xC2" because the Flash is initialized to all logic 1s and can be set bit-wise to 0. Writing the memory to an Intel HEX file, correcting the value at FFFEh to C2h (and correcting the checksum), and reprogramming the device with "prog MSP-EXP430G2-2231.ihx" restored the old contents. BTW: The "prog" command complained for the invalid checksum and also said which value it expected. So no hand calculation of the value was necessary. :-)

Compiling

As first example program, let's use the blinking LED proposed by TI at http://processors.wiki.ti.com/index.php/Blink_your_first_LED (you have to scroll down a bit). Copy-paste the example program to a file called blink.c and change the included .h-file to the device you own. Then compile using

msp430-gcc -mmcu=msp430g2231 -o blink.elf blink.c

The result can be examined (and disassembled) using

msp430-objdump -d blink.elf

Back in the mspdebug commmand line, program the new firmware to the MCU and start it:

prog blink.elf
run

Nice blinking should be visible.

MSP430 FRAM Devices

The MSP-EXP430FR5739 Experimenter Board with an MSP430 FRAM MCU can also be programmed. It comes with an MSP430FR5739 soldered to the board. Its features are

• 2-3.6V
• 24MHz
• 16kB FRAM, 1kB SRAM
• 10-BIT ADC, 32 IOs, Comparator, Timer, USCI (UART, IrDA, SPI, I2C)

The memory map is as follows:

• C200h-FFFFh: FRAM
• 1C00h-1FFFh: RAM
• 1A00h-1A7Fh: Device Descriptor Info (FRAM)
• 1800h-19FFh: Information memory (partly mirrored, FRAM)
• 1000h-17FFh: Bootstrap loader (ROM)
• 0000h-0FFFh: SFRs, Peripherals
• FF80h-FFFFh: Interrupt Vectors, Reset = FFFEh

The MSP-EXP430FR5739 Experimenter Board is a bit more expensive than the LaunchPad (but has a similar form factor). It comes with 8 blue LEDs (everything needs blue LEDs!), an accelerometer, an NTC, two buttons, ... These are connected as follows:

• LED0..3: PJ.0 .. PJ.3
• LED4..8: P3.4 .. P3.7
• S1: P4.0
• S2: P4.1
• Accel X: P3.0/A12
• Accel Y: P3.1/A13

Simple alternate blink program

#include  <msp430fr5739.h>

unsigned int i = 0;

void main(void) {
  // Stop watchdog timer.
  WDTCTL = WDTPW + WDTHOLD;

  // enable PJ.0 and PJ.1 as outputs
  PJDIR |= 0x01 | 0x02;
  // switch on first LED and switch off second LED
  PJOUT = (PJOUT & ~(0x01 | 0x02)) | 0x01;

  // main loop
  for (;;) {
    // toggle LEDs
    PJOUT ^= 0x01 | 0x02;
    // delay
    for(i=0; i< 20000; i++);
  }
}

Save this to a file blink-fram.c and compile with

msp430-gcc -mmcu=msp430fr5739 -o blink-fram.elf blink-fram.c

Important: To download, the mspdebug command "prog" cannot be used, because it issues a Flash erase command. The FRAM devices don't need an erase, because it can be written like normal RAM. Therefore program the device with the "load" command. But first, the FRAM contents should be backuped:

hexout 0xC200 0x3E00 MSP-EXP430FR5739-Demo.ihx
load blink-fram.elf
run

And again, nice blue blinking should be visible

This was only a very coarse run through the tools, but the usage is really astonishing simple, yet powerful. More to come (GDB, Makefile, Eclipse, ...)

libusb 1.0 for Pascal

This is a follow-up post to LibUSB for Pascal on 2012-07-15. I've now added header translations for the newer version libusb 1.0 (as well as its fork libusbx) including an object-oriented wrapper and a few examples to be used with Pascal.

Please find the source code in the libusb-1.0 branch at https://github.com/hansiglaser/pas-libusb.

NXP LPC11U14 and the LPCXpresso Board

The NXP LPC11xx series microcontrollers include an ARM Cortex-M0 CPU with SRAM, Flash and numerous peripherals. The low-cost LPCXpresso development board offers a debug adapter (JTAG, more precisely SWD) via USB. This is used with the Eclipse-based LPCXpresso IDE. Fortunately NXP offers it for Linux users too, even including the drivers for the debug connection.

After rapt contemplation I concluded, that most, if not all, of my ideas for nice projects require the connection to a PC. I prefer USB, so the LPC11Uxx microcontrollers including a USB 1.1 (12 MBit) device core come in handy.

NXP really tries to establish a community around their microcontrollers with forums and near-open-source software. The ARM Cortex-M0 MCUs are positioned as 8-bit and 16-bit MCU replacement. Therefore they have quite small packages (QFN33, LQFP48). The LPC1102 is sold in a WLCSP-16 package of which I've posted microscope images some time ago.

The low-cost LPCXpresso boards come without pin headers. I've added sockets, because its easier to connect wires to them.

One feature of these boards is that they can be used as debug adapter for custom boards. The connections from the debug adapter part to the device part of the board are layed out to holes for a 8x2 pin head with 100mil pitch. When delivered, the connection is made with small solder dots which can be removed using desoldering braid. I've added the pin head and put 8 jumpers on it to re-connect the on-board microcontroller.

One massive drawback of these microcontrollers is their extremley slow Flash memory. This gets even worse because it is (nearly) kept secret. The datasheet as well as the web page praise the fast operating frequency of 50 MHz. You have to dig deeply into the user manual to find a third-level section called "Flash memory access" describing a register called "Flash configuration register". Only the specific description of the two bits "Flash memory access time" reveals that wait-states (this word is avoided too) are required at higher frequencies. The maximum flash frequency is 20 MHz, so at the praised 50 MHz CPU frequency only every third cycle is an active one, effectively dividing the performance by three! Only the timers and other peripherals can utilize the higher clock frequency.

While ranting, nearly all ARM microcontrollers have slow flash and nearly all companies try to obscure that fact. Some microcontrollers try to speed up things using some kind of cache, others put loads of (fast) SRAM for code storage. It is still disappointing to be mucked around.

Control and communicate with a Cypress EZ-USB

When developing a device with the Cypress EZ-USB AN2131 microcontroller, eztool might come in handy. It is a command line tool to control and to communicate with these microcontrollers via USB. It can also communicate to any USB device in a custom user mode.

eztool offers a convenient command line interface. It uses Tcl as scripting language and command interpreter. Actually, every command you enter is implemented as a Tcl command (but written in Pascal and compiled in the executable). The Tcl programming language offers unlimited options to use, customize and automate eztool.

eztool prints a prompt at the screen which signals the current mode. To wait for the user input, GNU Readline is used. This offers comforable command line editing, history and auto-completion.

For each Tcl command and variable a dedicated manual page is provided.

Please find the source code at https://github.com/hansiglaser/eztool. It uses the Pascal OOP wrappers for GNU Readline, Tcl and LibUSB. Its device firmware is based on the EZ-USB firmware template.

EZ-USB Firmware Skeleton

Back in 2002 I developed my first evaluation board with the Cypress EZ-USB AN2131 microcontroller. Since then I developed several projects using this microcontroller. Each time a dedicated firmware was necessary.

In 2011 a student used one of my firmware projects to develop a firmware for the Keil ULink JTAG adapter, which also has an EZ-USB microcontroller. Unfortunately my firmware had a few files with unclear license conditions, so he re-implemented most files. His work was published as OpenULINK as part of the OpenOCD JTAG driver.

I used his improved firmware as starting point for the development of a firmware skeleton for the Cypress EZ-USB microcontroller. Please find the source code at https://github.com/hansiglaser/ezusb-firmware.

LibUSB for Pascal

libusb is a C library that gives applications easy access to USB devices. Many of my previous projects involving USB devices (e.g. the EZ-USB breakout board) use the libusb to communicate with it from the PC.

Since libusb is implemented in (plain) C, its headers had to be translated to be used with Pascal. I've also added an object-oriented wrapper. Please find the source code at https://github.com/hansiglaser/pas-libusb.

Raspberry Pi

Last Thursday, 2012-06-21, the Raspberry Pi has arrived. :-)

The first thing is that I ordered three at Farnell to sell to friends and to share shipping cost. Unfortunately, they reduced the order to a single piece. The guy on the phone explained, that everybody is limited to one device only. So be prepared to spend extra shipping cost.

To play with it, I followed the instruction in the Quick Start Guide. Therefore I downloaded the Debian Squeeze image and copied to an SD card. Then I connected the Raspberry Pi to my monitor, plugged in the ethernet cable, mouse and keyboard and used the power supply of my Samsung Galaxy 3 (note: not S3!) and there we go. It booted like a charm and shows its IP address at the screen.

To access the Raspberry Pi via SSH, you first have to generate a host key. Therefore run the commands

sudo dpkg-reconfigure openssh-server

which will also start the SSH server.

Next, I started the X Windows system by

startx

and got the LXDE desktop environment. The browser is "Midori" and the "LXTerminal" can be used for command line interface. I used "aptitude" to install the packages "vim-gtk" for a powerful editor, "fp-compiler" for a powerful programming language and "scrot" to make screenshots as suggested here. Note that the "scrot" package was not available originally, but after changing /etc/apt/sources.list to use the ftp.at.debian.org mirror and pressing the [U] key in "aptitude", it was there.

Most important thing? Write a Hello World! program, once in FreePascal, once with GCC. :-)

So, what next?

k7103-USB

Several years ago I wrote a GUI frontend for the Velleman k7103 PC Storage Oscilloscope.

        

The DSO is connected to the PC with a parallel printer cable. Most modern PCs don't have this interface any more. USB to Parallel converter cables don't work as interface because special control signals are used by k7103.

Therefore I developed a USB interface for k7103. k7103-USB is a dedicated interface with direct connection to the internal signals of the k7103. It offers all features of k7103 as available with the parallel printer cable. Additionally, an increased bandwidth for the data transfer of the sampling RAM to the PC is achieved. The K7103 frontend is extended with an appropriate driver for the new USB interface. It achieves approx. 70 acquisitions per second at my Core-i7 at 2.8GHz.

An additional PCB (100x76mm) is inserted into the k7103 case and connects to several digital chips of the k7103 PCB. k7103-USB mainly contains a Cypress AN2131Q EZ-USB 8051 microcontroller (MCU) and a Xilinx XC9572-PC84 CPLD.

Find more information on the GUI frontend and the k7103-USB hardware at http://k7103.sourceforge.net/.

Xilinx ISE on Linux

The FPGA vendor Xilinx very early started to offer their development tools (ISE, WebPack) for Linux. Unfortunately there are still some problems, for which workarounds are documented here.

Wind/U X-toolkit Error: wuDisplay: Can't open display

This error message comes from the Windows-to-Unix toolkit they use for their GUI. It doesn't like the DISPLAY=:0.0 value. The workaround is to set it to ":0"

export DISPLAY=:0

The problem was seen with ISE 10.1 and 12.3.

Kudos for pointing out the solution go to circuitben.

XILINX JTAG tools on Linux without proprietary kernel modules

For more detailed information please visit http://www.rmdir.de/~michael/xilinx/.

On Debian you need fxload

aptitude install fxload

and then setup the necessary files (as root!)

/opt/Xilinx/ISE/10.1/ISE/bin/lin/setup_pcusb

This installs some files to /usr/share (yes, directly, but Impact really requires them there :-( ). Ensure that the .hex files in /usr/share are world-readable.

Before you start the ISE, set the environment variable

export XIL_IMPACT_USE_LIBUSB=1

The above instructions are required for ISE 10.1, 12.3 and 12.4.

The JTAG tool has the following USB IDs

unconfigured	03fd:000f
configured	03fd:0008

(see also: /etc/udev/rules.d/xusbdfwu.rules).

FPGA Editor

The FPGA Editor of ISE 12.4 needs Motif 3 (libXm.so.3). Luckily libXm.so.4 can also be used, so simply set a symbol link.

cd /usr/bin
ln -s libXm.so.4 libXm.so.3

The tool also requires libstdc++-5.

aptitude install libstdc++-5

Simulation with ISIM

ISim converts the VHDL and Verilog files to C files and uses gcc to compile them.They ship GCC and all libraries, but these didn't work for me and others. The following trick helped by replacing the shipped version of libstdc++ by the one of the Linux system.

cd /opt/Xilinx/ISE/12.4/ISE_DS/ISE/lib/lin64
rm libstdc++.so libstdc++.so.6
ln -s /usr/lib/libstdc++.so.6 .
ln -s libstdc++.so.6 libstdc++.so

JTAG

The JTAG port of chips (signals TMS, TCK, TDI, TDO) was introduced for production tests of PCBs to  check that all connections to other chips are soldered and no shorts occur (so called boundary scan). The pins of the chip can be virtually disconnected from the core logic and their output signals remote controlled and input signals queried. This is used to set signal values and query from other chips.

To virtually disconnect the core logic from the pins special boundary scan cells are inserted. These are connected in series as so call boundary scan register (BSR). The JTAG controller (TAP: test access port) connects this BSR (among others) between TDI and TDO.

Boundary Scan Register and other data registers (DR) between TDI and TDO

Which scan chain is connected between TDI and TDO (i.e. used as data register, DR) is set by going through the JTAG state machine and shifting the according instruction into the instruction register (IR).

JTAG State Machine

Later JTAG was extended for production test of the semiconductor interiors to check that all internal gates, transistors and connections are proper (DFT: design for test). All D-FF of the logic design are connected in series to so called scan chains. A test pattern is shifted in so that all flip-flop's outputs are set to a certain pattern. The combinational logic between these outputs and the inputs of other flip-flops will create a resulting pattern only depending on the hardwired logic functions and the pattern. This is then sampled and shifted out. Utilizing a (hopefully small) set of test patterns allows to test for (nearly) all possible production faults and sort out a chip as defective. Memories inside a chip also have to be tested after production which is accomplished by a built-in self test module which automatically fills and verifires the memory with a predefined set of patterns.

These two use cases of JTAG are used during production. Therefore only few people know about it.

Most widely known is JTAG as a debugging interface to microprocessors and microcontrollers. Special logic is activated and can be used to access CPU registers, memory, peripherals, set breakpoints and do other debugging related activities. Unfortunately each vendor invented his own "higher level" protocol, so they are not compatible. Even worse, most vendors keep the protocol description secret, so you have to buy a JTAG adapter from a small set of companies which were allowed to read the specifications.

JTAG Connector at the bottom left

But did you ever wonder how this JTAG logic is getting into the semiconductor? Anybody hacking the TAP (test access port) with its state machine and signal connections in VHDL? Creating boundary scan cells for all chip IOs? For sure some will do so. But the good news is: All this can be generated automatically. Some ASIC tool vendors integrate the functionality into the synthesis tool (e.g. Synopsys Design Compiler) or offer stand alone tools to generate VHDL RTL code for the whole JTAG and boundary scan logic (e.g. Mentor BSDArchitect).

For a test chip to demonstrate the concepts developed for my PhD thesis I've successfully used Mentor BSDArchitect. It uses a VHDL entity of the core logic top level design, a pin definition file and a script file as input. It automatically generates VHDL files with RTL code of the tailored JTAG TAP, boundary scan cells and all connections as well as test benches. The RTL code wraps the core logic top level design and is used for synthesis as usual. The chip (produced in a 130nm CMOS 6 layer Cu plus 1 layer Al process) works perfectly. BSDArchitect allows to define custom scan chains which I've used as interface to download the configuration bit stream to the reconfigurable logic.

Another tool is Synopsys BSD Compiler which is integrated in the Design Compiler synthesis tool. With a few (more or less intuitive) commands you can setup the boundary scan chain, add custom scan chains, define the JTAG IDCODE, ... The tool will then automatically generate the logic for the JTAG TAP and all boundary scan cells. AFAIK it does not create RTL code but just a simulation testbench. I'll use this tool for the Invent a Chip ASIC. More discoveries to follow.

Keil ULink

Some time ago I've investigated the Keil ULink JTAG adapter. Note that this is version 1, not the ULink2, ULinkPro or ULink-ME. The following image shows the schematic (the link opens a PDF file), previously posted at Mikrocontroller.net.

The device is built around the well-known Cypress AN2131 EZ-USB microcontroller and has additional 32 kByte external memory. Level shifters are used for the JTAG signals, which are available at 3 connectors for Infineon OCDS, ST and ARM.

Since the device is quite generic, any other things can be done with it. A few students used it to program their custom firmware and PC software (running on Linux) to use the device to download ATmega and ARM software as well as an OpenOCD driver. Links and details will follow.

Unfortunately the work is only tested with the ULink version 1. Does anybody have a ULink2 and is interested to borrow it to us for investigations and firmware adoption?

Logic Analyzer and Protocol Analyzer

The Logic Analyzer and Protocol Analyzer is a project done during Easter holidays. It uses an FPGA for acquisition, then transfers the samples to the PC, where a protocol analyzer identifies the ones and zeros and reconstructs e.g. I2C bus traffic or a program download and debug session via JTAG.

Several years ago I got a Cesys X2S_USB FPGA board with a Xilinx Spartan-2 XC2S200-PQ208 FPGA and an AN2131 EZ-USB microcontroller (MCU). The MCU has rich connectivity to the FPGA and is used for programming and control, both via the PC.

The first image shows the X2S_USB and an add-on board with multiple pin-head connectors. Each size is available twice to connect this board as sniffer to a ribbon cable. One cable comes e.g. from a JTAG programmer and the second goes to the target device. No intermediate connector at ribbon cables are required this way.

Logic Analyzer

The Logic Analyzer part is mainly implemented in the FPGA. Commercial logic analyzers sample the input signals periodically. Either an internal clock is used (like a digital scope) or a dedicated input signal is used as clock. This projects realizes a different approach: The logic signals are only stored, if any of them has changed. This looses time information, but instead spares the small amount of acquisition memory.

For each input signal one of the 4kBit Block RAMs is used. The FPGA contains 14 such Block RAMs, therefore up to 14 signals can be monitored with up to 4096 values.

Before the operation can start, the MCU is used to download the config bitstream (167 kBytes) from the PC via the USB bus into the FPGA. For the operation, the FPGA is connected to the EZ-USB via the 8 bit external memory interface. The MCU can access a control register and a sample counter as well as a FIFO to read out the acquisition memory.

Everything is controlled with a small PC program, which communicates with the MCU via USB.

Protocol Analyzer

The protocol analyzer functionality uses the samples acquired by the logic analyzer and applies analysis algorithms. Successive algorithms hierarchically extract the meaning from the data. The first step is to convert the samples to protocol-specific symbols, e.g. I2C-Start, -Stop or -Data. The next levels extract the meaning of these symbols with a notion of underlying grammar, e.g. I2C Byte or a whole I2C Transfer.

Currently only I2C analysis is done. The output is printed as text, so no fancy GUI or waveforms. Next steps will be a more user-friendly interface with Readline and perhaps a scripting language. This will be supplemented with a GUI and finally with waveforms.

Eagle, VHDL, Firmware and PC software sources are available under the terms of the GPL on request.

EZ-USB AN2131 External Memory Timing

The EZ-USB Technical Reference Manual of the AN2131 and friends shows that all external memory read and write strobe signals are active (low) for two CLK24 cycles (see Fig. 13-1 to 13-4). Important: That this is only true if the wait states are disabled as described in Sec. B.2.2.

After reset the default is one wait state which extends the strobe signals to four CLK24 cycles.

 
Bits 0 to 2 of the SFR CKCON have to be set to 0 explicitly for zero wait states with a strobe width of two.

LPC1102 WL-CSP Images

NXP (former Philips Semiconductor) sent a sample of a LPC1102 ARM Cortex-M0 microcontroller in a tiny 16-pin WL-CSP (wafer-level chip-scale-package). This means that the package has the size of the chip die, or the pure die is used directly. The die is only 2.2x2.3mm with a ball pitch of 0.5mm. At the top of the die solder bumps similiar to a BGA package are used to connect the chip to a PCB.

The first image shows the whole chip (tightly fitting in the microscope's view at a magnification of 2x). The 16 balls are easily visible. At the border of the chip all pads are placed. Only a few of them are connected to the balls via the signal redistribution layer. On some unconnected pads there are scratches from the wafer prober needles during final product test.

At a magnification of 5x the connections of the redistribution layer to the chip pads reveal a nice pit.

At the top right corner a chip label shows that it really is a LPC111XL with just some peripherals not connected to the outer world. It is not sure whether NXP uses fully functional dies and just doesn't tell anybody, or if the product test revealed that these unused peripherals don't work. The latter case is clever, because they can sell chips which would otherwise be rejects.

An even close look at a magnification of 20x shows one wire of the redistribution layer and the underlying semiconductor layers. The following images have three different focus settings. Watch the sharp spots.

       

There are a lot more colorful places on the chip. These complicated and irregular parts usually are analog peripherals. These are hand crafted by design engineers.

At 50x magnification it is really tedious to find a focus plane. The following images are details of the previous two.

The digital parts are implemented with standard cell libraries of logic gates (AND, OR, D-FF, ...). Automatic tools optimize the placement and routing to connect them. The following image shows a detail of logic structures. In the mostly green area many horizontal connections between the cells are visible. Below these (yellowish) vertical connections are visible. These wires completely cover the actual logic cells below them. At some places filler structures are inserted to avoid areas of too inhomogeneous metal distribution. The two vertical lines at the left might be power distribution at the chip.

Many more images with varying magnifications and focus depths are available in the album.

EZ-USB Breakout Board

The Cypress (former Anchor Chip) AN2131 EZ-USB microcontroller contains an improved 8051 plus a USB serial interface engine. The internal 8kByte RAM (Code, Data) can be written from a PC via the USB bus to download the firmware to the chip. Therefore no flash or other non-volatile memory is required. Firmware update is as easy as restarting the PC application.

My first project using the EZ-USB microcontroller was the "EZ1" test board in 2001 with two MAX521 8 channel DACs, a MAX127 8 channel 12 bit ADC (both with I²C interface), a RS232 connector and one for the Infineon FingerTip sensor as well as two LEDs. If you don't have JTAG for debugging, two LEDs is the absolute minimum to trace the program execution.

             

In the meantime I did several other projects using this microcontroller.

The EZ1 board lacks connections for general purpose digital signals (e.g. to control an OLED). Therefore a new board was required. Contrary to the EZ1 it holds the 80 pin version of the microcontroller. All signal pins are connected to pin sockets. Port A is also connected to eight LEDs (with a driver chip).

The new board already proved useful to control an OLED module (ELV ODM100). The image shows the display on the left and the EZ-USB breakout board on the right. The image on the display is only shown partly due to the short exposure time of the camera. The ribbon cable is used to "convert" the pins of the display module to sockets which can be connected with stripped wires to the breakout board (colored wires). ELV offers source code to access the OLED. Only a few changes were necessary to get it working for the 8051. More work helped to speed up the port access and therefore image setup.

Files: Schematic PDF, Eagle Schematic, Eagle Board