Using your MCU's time processing unit as an on-chip logic analyzer: Part 1 - Embedded.com

Using your MCU’s time processing unit as an on-chip logic analyzer: Part 1

The advanced timer modules available on a number of advanced processors” such as the TPU and enhanced TPU (eTPU) on the ColdFire and PowerPCCPUs ” are powerful event-driven controllers that are useful in a widerange of engine and machine control applications.

While their main purpose is to off-load the main CPU when processingtime-triggered or external pin-triggered events, and when controllingthe output pins in a timely manner, these event-driven timer modulescan also be used to configure an on-chip edge-driven “logic analyzer“device.

Although programming an event-driven eTPU requires a slightlydifferent approach compared to standard microprocessor units, it is notas complicated as it may seem at first sight.

In this article, we will discuss the little bit of low-levelprogramming needed to use the TPU in this way, using the MCF5235ColdFire processor, and its eTPU and Fast Ethernet Controller.Mostlyfor demonstration purposes, we will use the uClinuxoperating systemand its TCP/IP networking to implement communication between the deviceand the host PC. The business card-sized evaluation board M5235BCCwasselected as the development platform (seeFigure 1, below ).

While the Logic Analyzer built on the eTPU and ColdFire MCF5235 cannot compete with today's high-end analyzer devices, it has proven to beuseful in the development of many different applications as a zero-costreplacement of such expensive equipment. We also see some potential forthis eTPU-based Logic Analyzer when developing and tuning othereTPU-based applications, simply because it shows all the signals asseen through eTPU eyes.

Figure1: In addition to a 16 channel eTPU connector, the M5235BCC developmentboard contains an MCF5235 ColdFire processor, 16MB RAM / 2MB Flash, an10/100 Ethernet transceiver, a BDM connector, and an RS232 consoleconnector.

Edge-driven Logic Analyzer
So, what is this edge-driven logic analyzer that we are going to build?In short, it is a device that should behave like a standard logicanalyzer by means of measuring multiple digital input signals, savingthem and displaying the resultant waveforms on the screen.

Unlike the classic logic analyzer which samples the input signalstates periodically at very high rates and saves the data to memory,the event-driven device is idle-waiting for an edge on any of its inputsignals. Each such edge causes the value of a global free-running timerto be saved in memory, together with information on the channel, wherethe edge occurred, and the polarity of the edge. Using such data, theinput signals can be fully reconstructed and the resultant waveformscan be drawn, similar to a standard logic analyzer device.

Of course, drawing the signal waveforms is not the only featureusers look for in a logic analyzer. Today, modern devices offer awealth of signal analysis options, as well as advanced methods to”trigger” the signal sampling to “catch” the moment of interest. On theother hand, I personally worked on many applications where a simpledrawing of the signal waveforms, with a simple “wait-for-edge” trigger,helped a lot in successfully completing the development.

The logic analyzer we are about to design does not aspire to replacehigh-end devices. In the first place, this application shoulddemonstrate the capabilities of the eTPU unit and perhaps also to freeit from the shackles of engine control. We hope that after reading thisarticle, you realize that using a processor with an eTPU module may bea reasonable single-chip solution in applications where the processorrequires some external logic or a PLA device to handle input and outputsignals.

eTPU Logic Analyzer Function
The eTPU function Logic Analyzer (LA), assigned to 16 eTPU inputs,utilizes the eTPU hardware for capturing input transitions and storingtheir times to RAM.

The eTPU module (Figure 2, below )has a micro-engine, which serves channel events. Each of the eTPUchannels includes double input capture hardware. When a transition isdetected on a channel, a 24-bit transition time is captured to thechannel capture register. At the same time, the channel asks the engineto service this capture event.

If the engine is idle, it starts the service immediately. If theengine is busy servicing another channel, the service is delayed. If asecond transition is detected on the same channel prior to servicingthe first, the second transition time is captured to the second captureregister available on the channel. This enables the capture of verynarrow pulses.

The main goals of the channel event service are storing a transitionrecord to RAM and releasing the capture hardware for followingtransitions. The transition record is a 32-bit word consisting of thefollowing fields:

* transition time (24 bits)
* channel number (4 bits)
* transition polarity (1 bit)

One or more records can be stored to memory within one service. Ifone transition is captured in the channel hardware, one record isstored. If both channel capture registers hold transition times, tworecords are stored. Moreover, the polarity of the input signal canindicate that a third transition came, the time of which is notcaptured. In this case, one additional record is stored, using thecurrent time instead of the lost transition time.

The transition records are stored in a circular buffer in the eTPUData RAM. Within the 1.5kB of eTPU Data RAM available on the MCF5235,1kB is allocated as the buffer. This enables the storage of up to 256transitions without CPU service. The eTPU buffer has two thresholdlevels ” one at the middle and one at the end of the buffer. From thebeginning, the buffer is filled from the bottom, checking for the firstthreshold level.

When this level is reached, an interrupt is generated to the CPU.The CPU needs to copy the first half of the eTPU buffer to a large CPUbuffer. In between, the eTPU uses the second half of the buffer tostore the following transition records. When the second eTPU bufferthreshold is reached, another interrupt is generated to the CPU inorder to take over the second half of the eTPU buffer. The first halfof the eTPU buffer has already been copied, so the eTPU continues tostore from the bottom of the buffer again.

The frequency of the eTPU clock counter is 37.5MHz. Thus, thetransitions are captured with a 27ns precision.

Figure2: TPU module operation.

Recently, the basic functionality of the LA eTPU function has beenextended to support the following features:

* 32-bit time range
The 37.5MHz clock overflows the 24-bit range every 447ms. In order toincrease the range of total measurement time, the LA function checksfor clock counter overflows, and every time an overflow occurs, aspecial record is stored in the buffer. This record means an update ofthe 32-bit transition times' most significant byte. Thanks to this, thetotal maximum measurement time is now almost two minutes.

* Maximum measurement time
The LA function enables limiting the maximum measurement time, andnotifies the CPU when it elapses.

* Trigger
The LA function supports a simple trigger algorithm. For each channel,either a low-high, high-low, both, or no transition can be marked asthe triggering transition. The first triggering transition detectedgenerates an interrupt to the CPU, and its time is stored as thetrigger time.

eTPU to CPU Interface
It has become a convention that the eTPU function developers createinterface routines to their eTPU functions. These API routines providean easy interface for the CPU application, enabling the initializationand control of the eTPU functions. The API aids the CPU applicationdeveloper, avoiding the necessity of knowing any details of the eTPUfunction implementation.

The same approach is applied to the LA function as well. Theinterface routines are called Logan API . TheAPI includes four easy to use run-time functions:

void LoganInit(void)
void LoganStartMeasure(void)
void LoganForceTrigger(void);
void LoganStopMeasure(logan_state_t why)

and two interrupt handlers:

void LoganBufferFilled(void)
void LoganTriggerOrStopDetected(void)

The API also creates the following global data structure (below to the left) :

TPUCodeListing

The logan_measure_tdata structure consists of three parts. The measurement setupsubstructure is filled according to user selection of active channels,trigger condition, pre-trigger time, and total measurement time. Whenthese values are set, the function can be called in order to initializethe eTPU module for measurement. The measurement itself is started bythe function LoganInit()LoganStartMeasurement().

The measurement state value monitors the Logan operation. At themoment the measurement is started, the state turns from LOGAN_DISABLEDto LOGAN_WAITING_FOR_TRIGGER. When the trigger condition is detected,the state reflects it by the value LOGAN_TRIGGER_DETECTED, directlyfollowed by LOGAN_START_LOCATED.

If no trigger is detected for a long time, the measurement can betriggered manually by the function Measurement is stopped in one ofthree ways. Either when the total measurement time elapses, the CPUbuffer is filled, or manually by the function LoganForceTrigger().LoganStopMeasurement().

All of these possibilities are reflected by an appropriate statevalue change. The third part of the logan_measure_t datastructure, the data substructure, is filled by the Logan APIafter the measurement has finished. It includes information necessaryto visualize the measured signals ” the time when the trigger wasdetected, the time boundaries of the whole measurement, andcorresponding positions in the CPU buffer of the recorded edges.

The interrupt handlers process the eTPU interrupts generated duringthe measurement. The LoganBufferFilled() is called on an eTPU channel interrupt, raised when either the lowerhalf or the upper half of the eTPU buffer has been filled. Thisfunction copies the eTPU buffer data to the CPU buffer, and checks fora buffer overflow.

The LoganTriggerOrStopDetected() is called on an eTPU global interrupt, raised when the triggercondition is met or when the total measurement time elapses. In thecase of trigger detection, the trigger time is stored, the measurementstart time is calculated, and the corresponding position of the firstmeasurement transition in the CPU buffer is located, so that thepre-trigger time period is protected. In the case of a total timelapse, measurement is stopped, the stop time and the correspondingposition of the last transition in the CPU buffer are stored in thedata substructure.

CPU to Host Interface
Having done the eTPU work, the CPU-programmer now has the LogicAnalyzer operation fully under control using a simple C-language API.To really create the signal waveforms on the screen, however, two majorproblems are still to be resolved.

The first one is the implementation of an Ethernet network-basedcommunication between the CPU and the host PC. The second challenge isto write a PC-based application to process and display the waveformdata and to provide the user with some kind of graphical interface tothe Logic Analyzer configuration.

Network Interface
As none of us who participated on developing this application was anexpert on communications and networking, we decided to find somestandard, ready-to-use solution which would fit our needs. It turnedout that there are a lot of solutions which enable standard TCP/IPcommunication for the ColdFire platform, so we started to think aboutwhich one would be the best.

Finally, we decided to use the full uClinux operating system and itsnetwork capabilities to do the job. We thought this would be a greatopportunity to demonstrate the combination of low-level time-criticaltasks with high-level control software on a single chip ” exactly whatwe had wanted to achieve from the beginning. With a vague idea of whatit means to implement the uClinux, and with minimal previousexperience, we were also looking forward to learning something new.

Pleasetake the remainder of this article as a report on how weprogressed in the development, rather than an official guide to makinguClinux work on the ColdFire. An experienced embedded-Linux guru wouldsurely find some imperfections, but this is simply the route we took.

To start the uClinux or any embedded-Linux development, it is alwaysbetter to have a standalone Linux-based workstation. In our case, thiswas a common PC computer running RedHat Linux 9.

As a starting point, it is worth reading the uClinux overview on the uClinux.orgweb site and especially the pages dedicated to the uClinux port for ColdFireplatforms .Before starting, download the GCC compiler and other m68k(ColdFire)build tools from the site as well. In our application, we have usedthe Linuxkernel 2.4, which can bebuilt using the GCC version 2.95.3. In case you want to be up-to-dateand use the newer 2.6 kernels, the GCC version 3 will be required. Backin March 2005, when we were working on this application, there wereknown issues in using the GCC 3 so we decided to use the older and morestable version of both the kernel (2.4.27) and the GCC (2.95.3).

eTPU in Linux
In Linux, just as in any other operating system, things do getcomplicated when you want to access the processor resources atlow-level. In theory, the system separates and protects the memoryspaces of different running applications, as well as the memory spaceof the operating system kernel.

The mechanism used to achieve such protection is called “virtualmemory” and it also utilizes a bit of the silicon (Memory ManagementUnit ” MMU). On high-end processors such as x86, PowerPC, or ColdFire54xx, the system and the MMU ensure that the user processes live intheir own linear memory space, without direct access to the memory ofother processes or the kernel. All addresses are simply logical(“virtual”) and do not refer directly to the physical memory ” in factthe address values completely lose their meaning if taken outside ofthe process context.

The Operating System kernel and the MMU manage thevirtual-to-physical address translation tables for each process andthey translate addresses on-the-fly as the process is running. The userprocess has no way of turning the translation mechanism off, so even ifthere are memory-mapped peripheral registers on a well-known fixed(physical) address, the process can not access them. In other words,the operating system kernel is the only one who may access the deviceperipherals.

So how can a standard (user-space) application make use of aperipheral device? It always needs to go through its kernel-space ally” the so called “device driver”. Using the software interrupt called a”system call”, the process activates the system call handler in thekernel and passes parameters describing what it needs to do.

From the application programmer perspective however, thiscomplicated mechanism is pretty much hidden in the standard C library.Function calls such as fopen, fork, socket, etc. always end up with asystem call to the operating system kernel and are passed further on tothe appropriate device driver.

There are several kinds of device drivers in Linux. The simplest oneis the so called “character” device, which mimics the behavior of aplain file in the file system. With a character driver, standard fileI/O operations are used to access the driver and to exchange databetween kernel-space and user-space applications.

In our application, we will write the character device driver to actas an interface between the low-level Logic Analyzer running on theeTPU and the user application which implements the TCP/IP networkconnection.

The ColdFire processors of the 5200 family, which also includes theMCF5235 used in our application, do not have the Memory ManagementUnit, and there is also no concept of “virtual” memory. The Linuxoperating system could not normally run on such a platform withoutsignificant modification.

TheuClinux patch ,as itwas originally called, enables the Linux to run from the one and onlymemory area, and to use it for both kernel and user applications.Despite this drastic MMU-surgery, it still retains a lot of its greatfeatures and enables advanced operating system-based applications torun on cheap and simple devices.

From our Logic Analyzer perspective, and because there is no memoryprotection in uClinux, it would be easily possible to access the eTPUunit directly from the user space TCP/IP application. However, thiswould not be “the right way” and would definitely close the door toreusing the code on the PowerPC-based platforms. Obeying the Linuxrules, we have developed both the Logic Analyzer kernel driver and theTCP/IP user-space application separately.

Logic Analyzer, the Big Picture
The Logic Analyzer application (see schematicin Figure 3, below ) consists of the following parts:

* The eTPU unit, running the low-level Logic Analyzer function onall its channels
* The kernel driver (logan_drv), managing the eTPU operation andimplementing the high-level C interface to the Logic Analyzer operation
* The TCP/IP server application (logan_srv) running in user-space andaccessing the kernel driver through the virtual file interface.
* The TCP/IP client application, which is the Microsoft Windows-basedActiveX visualization component in our case (not covered by thisarticle).

Figure3: Schematic view of the eTPU Logic Analyzer application

There is also a web server running on the uClinux system whichpresents the HTML infrastructure pages to the client. The main “LogicAnalyzer” HTML page also contains an auto-installing cabinet file ofthe ActiveX visualization component, so there is no need to install itseparately on the client computer. When the page is opened, the ActiveXself-installs, establishes its own TCP connection to the logan_srvserver, and starts “streaming” measured data.

Having the web server in the system, there is also the possibilityof using the Common Gateway Interface (CGI) application and use astandard HTTP protocol to communicate with the Logic Analyzer. Whentesting this approach, it turned out that the HTTP overhead degradesthe performance significantly.

The version of the “boa ” web serverwe had used did not support the “keep-alive” links that time, so thevisualization agent needed to re-establish a TCP connection each timeit wanted to retrieve the device status or data. Although not tried, webelieve that with the latest version of the “boa” web server, or theheavyweight “Apache “server, it would be possible to use the CGI as asolution comparable with the standalone “logan_srv “application.

All the communication between the kernel driver, TCP/IP server, andTCP/IP client runs in a common plain text protocol:

* The “logan_drv” kernel driver accepts text-based commands on its input (writing to thevirtual /dev/logan file), and returns the status or data also as plaintext (reading the file until end-of-file).

* The TCP/IP server isa very simple text-based forwarding machine. Any text message itreceives from the TCP/IP client is sent on (written) to the /dev/logan file .Then in-turn, the TCP/IP server also reads the /dev/logan file andsends its complete content back to the client.

Although not really optimal with regards to the communicationspeeds, using text-based communication eases the debugging and testingof the driver and the system as a whole. The “echo ” and “cat ” commands can be used from theuClinux console to write to and read the /dev/logan file,and to exercise and diagnose the underlying eTPU Logic Analyzerfunction.

Next in this two part article:Building the uClinux application.

Michal Hanak is systems engineerand Milan Brejl, Ph.D., is System Application Engineer is Freescale Semiconductor's Roznov Czeck Systems Center.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.