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

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

Editor's note: InPart 1 in this series, the authors covered the basics of the TimeProcessing Unit on board several advanced processors, some basic boardconfigurations, and what is needed to reconfigure it for use as anon-chip logicanalyzer using the uClinux operating system.

The following sections describe the steps taken to make the uClinuxOperating System work on theMCF5235 evaluation board. All the source code and the uClinuxsystem files that needed to be modified for the Logic Analyzerapplication are available for download as a Zip file at EmbeddedLogan Code..

There is also a complete S-record image of the application suitablefor the M5235BCC evaluation board. In addition to the configureduClinux kernel and all the binary applications developed for the LogicAnalyzer device, the image also contains the web-server-side HTML pagesand a prototype of the visualization component self-installing cabinetfile.

Configuring the uClinux
After you extract the uClinux distribution somewhere to your homefolder, you should see the directory structure as shown below:

+ bin helperbuild utilities and tools
+ config scriptsused to configure the uClinux system
+ Documentationvarious how-to documents
+ glibc standard Clibrary source code
+ images destinationdirectory for generating uClinux images
+ include kernelinclude files
+ lib otherlibraries source code+ linux-2.0.x Linux 2.0 source tree
+ linux-2.4.x Linux 2.4 sourcetree
+ linux-2.6.x Linux 2.6 sourcetree
+ Makefile the master makefile
+ romfs device file systemgenerated as uClinux apps are built
+ tools variousscripts and utilities used during build process
+ uClibc standard Clibrary optimized for uClinux
+ user user application sourcetree
+ busybox standard Unix commandline toolset
+ samba SMB/NetBios services
+ portmap remote procedure callportmapper (used by NFS)
+ boa the web server source
+ .. a lot ofother Linux applications ported to uClinux
+ vendors support andconfiguration files
+ Motorola Freescale processorplatforms
+ M5235EVB ColdFire5235-specific makefiles and configurations

With such a clean installation, and before any changes are made tothe source tree, it is worth testing that you are able to configure andbuild up the uClinux image. There are several ways to configure theuClinux before building ” one of the most user-friendly is to use thetext-based menu-driven application invoked by the “make menuconfig”command from the base “uClinux-dist” directory.

In the first menu system, shown below, you can select the vendor andtarget board (Motorola, M5235EVB), Linux kernel version (2.4.x), andthe uClibc as the standard C library. Options to further customize thekernel and vendor/user settings should also be selected, so the nextmenu system is automatically invoked upon exiting the first menusystem. The following list below summarizes the options we enabled in order to make the uClinuxsuccessfully work on the development board.

[uClinux-dist]$> make menuconfig

Linux Kernel 2.4.27 Configuration:
* Code maturitylevel options
    o Promptfor development and/or incomplete code/drivers
* Loadable modulesupport
    o Enableloadable module support
* Processor type and features
    o MCF5235CPU
    o 150MHzCPU Clock Frequency
    o MotorolaM523xEVB board support
    o 16MB RAMsize
    o AUTO RAMbit width
    o Kernelexecutes from RAM
* General setup
    o Networkingsupport
    o Kernelcore format ELF
    o Kernelsupport for flat binaries
* Block Devices
    o RAM disksupport
    o 4096Default RAM disk size
    o ROM diskmemory block device (blkmem)
* Networking options
    o Packetsocket
    o TCP/IPnetworking
* Network devicesupport
    o Networkdevice support enabled o Ethernet 10 or 100Mbit
* FEC Ethernetcontroller of ColdFire 52xx
* Character devices
    o ColdFireserial support
* File systems
    o /procfile system support
    o ROM filesystem support
    o Secondextended fs support
    o NetworkFile Systems
* NFS file systemsupport
* Provide NFSv3client support

uClinux Configuration
* Core Applications
    o shellprogram: other
    o expand
* FilesystemApplications
    o SAMBA
* nmbd
* NetworkApplications
    o boa
    o portmap
* BusyBox
    o BusyBox:enabled with the following applets:cat, chmod, cp, echo, expr, ifconfig (with status reporting), init(using inittab), insmod (with lsmod and rmmod), kill, ln, ls, mkdir,mknod, more, mount (with loop devices and NFS support), mv, ping, ps,rm, rmdir, route, shell (with msh as /bin/sh), sleep, test, true_false,udhcpc, umount, uname, yes

After the configuration is saved, you have to run the “make dep”command and then the final “make”:

[uClinux-dist]$> make dep
[uClinux-dist]$> make

In a few minutes, you should get the resulting uClinux binary imagein the “image” output directory.

Customizing uClinux for the LogicAnalyzer
Having a clean uClinux source tree, let's now add the “Logic Analyzer”application.

A good starting point is to read the Adding-User-Apps-HOWTO document we have created, which will guide you step by step inmodifying the “user/Makefile “and “config/config.in ” files.Our code will be placed in the “user/loga n”directory and the build will be controlled by two configurationoptions: CONFIG_USER_LOGAN_LOGAN andCONFIG_USER_LOGAN_KMODS.

“logan_drv” – the Kernel Driver
The Logic Analyzer kernel driver is heavily based on the examples givenin the O'Reilly “Horse Book” ,the Linux Device Drivers 2nd Edition. The driver code begins in thelogan_mod.c file and completely reuses the C API code developed for theeTPU “LA” function.

The driver compiles to logan_drv.o, a so-called “loadable module” of the uClinux kernel. In fact, the codeis compiled as if it were a part of the kernel, with access to allkernel and device resources. The only difference from the “static”device drivers compiled into the monolithic kernel image, is that theloadable module is available as a separate object and can be “inserted”into the running kernel using the “insmod “utility.

After the logan_drv.o moduleis inserted into the kernel, it initializes the eTPU, installs the eTPUinterrupt service routines and registers itself as a “character device 4 2″. Being acharacter device means that the driver mimics the standard filebehavior of a special file object, often called a “device file”. Anytime this special file is opened or closed, or any time it is read orwritten to by the application, the driver gets a special call to handlethe operation. The device file can be created anywhere in the user filesystem using the mknod utility. Typically, the /dev directory is the place wheredevice files are stored:

[uClinux-dist]$> mknod/dev/logan c 42 0
The “/dev/logan ” here is anarbitrary name under which the driver is known in the user file system.The 42 and 0 are so-called “major” and “minor” device numbers. Themajor number identifies the particular device driver, while the minornumber is passed to the device driver as an argument and typicallyidentifies different device instances.

There can be up to 255 different character device drivers registeredin the system. The major number 42 is reserved for experimentalpurposes or custom applications, so we use it for our application. Theminor number is currently ignored by the logan_drv , but in future it mightbe used to identify a particular eTPU unit on devices with multipleeTPUs.

The logan_drv operation isquite straightforward: any time the device file is written to, theinput data is parsed as a set of newline-delimited commands andprocessed one by one. In case there is any output text to be generatedby the driver, it is buffered until the device file is read. Thefollowing list gives a summary of “commands” handled by the driver:

* set param value – configure the Logic Analyzer parameter
* get param -obtain a parameter value
* star t – start measuring
* stop – abortmeasuring
* trig force – atrigger event to occur
* get_status – getthe state machine status (running, triggered, …)
* get_data – get the measured data

The set and get commands are used to configure the parameters of theeTPU Logic Analyzer engine. The following “param ” values can be used:

* setchannel_mask – configure channels to be used
* set buffer_size – allocate CPU buffer memory
* settrigger_mask_hl – specify High-to-Low trigger channels
* settrigger_mask_lh – specify Low-to-High trigger channels
* setpre_trigger_time – specify pre-trigger time (in clocks count)
* set total_time – specify maximum measure time (in clocks count)

The advantage of text-based communication between kernel driver andthe user space application is that simple “echo” and “cat” utilitiescan be used to exercise or to monitor the Logic Analyzer operation.

“logan_srv” – the Network Interface
The Logic Analyzer network application is a very simple TCP server usedonly to forward and replicate text messages between the network clientand the /dev/logan devicefile. The application runs in an endless loop, permanently waiting foran activity on any of the client-connected sockets.

Each time a text-based message is received from any client, it iswritten to the /dev/logan file. Then, the file is immediately read and its whole content, i.e.the command response, is replicated back to all listening clients.

The output generated by the kernel driver is fully”self-descriptive”, so even if there are multiple network connectedclients and one of them issues a command to the Logic Analyzer device,the response describes to all the clients what really happened. Intheory, this mechanism enables the Logic Analyzer device to be accessedsimultaneously from multiple clients.

For example, the command:
set channel_mask0x0f

generates the response:
valuechannel_mask=0x0f

which is sent to all network-connected clients. Each client thenknows that the channel mask was changed and what the new value is. Ingeneral, any changes to the configuration or to any data measured bythe Logic Analyzer device are immediately made available to allclients.

Making it all Work Together
What I still find wonderful on the Linux source tree, and even more soon the uClinux distribution, is the really well thought out set ofmake-files, spread over the source directories and co-operatingtogether.

Using a single “make “command issued in the base directory, the whole system builds up into abinary image which is ready to be burned onto a device Flash memory andused as it is. The image consists of the kernel runtime as well as theread-only file system (romfs) mounted automatically as a root directory”/ “.

The romfs containsall the files needed by the running system: configuration files, devicefile, utilities and user applications. For the Logic Analyzer device,some system files need to be changed in the file system, so first let'stake a look on how it all works.

During the make process, the complete file system is temporarilybuilt in the “romfs “subdirectory of the uClinux tree, from where it is later packaged intothe binary image suitable for the embedded target.

You can examine the files in the romfs directoryto see what you really get after the build process, but it makes nosense to make any modifications here. All romfs files are re-generatedany time the make builds the binary image. The question of how theromfs gets built can be answered after a closer look at the individualMakefiles, and especially the central Makefile of the selectedplatform, which is “vendors/Motorola/M5235EVB” in our case.

This Makefile builds the romfs directorystructure, prepares device files in the directory, and installs theconfiguration and other “static” files into the romfs/etc or romfs/devromfs/home directories. The executables such as the BusyBox, “boa” web server, or ourlogan_srv, logan_drv.o are installed by individual Makefiles aspart of their build processes.

By default, the M5235EVB Makefile takes the files to be installedfrom the “vendors/Generic “directory. To build up the Logic Analyzer system we made a slightmodification to the Makefile in order to take the original files from aseparate “M5235EVB/LogAn “directory. All the files can be found in the download section.

The resultant “image.bin” is finally built with the “make” commandand can now be tested on a real board.

On an embedded platform, the uClinux system is typically invoked bya so-called “bootloader” program ” a small application whichinitializes the CPU, memory and other board resources and jumps to theoperating system entry point. The factory-default bootloader programfor the MCF5235BCC board is the “dBug “, alsoavailable for other Freescale platforms.

dBug isquite a powerful application in itself, enabling the downloading ofother applications or operating system images over the Ethernet (TFTP)network, and also the programming of the system Flash memory. The usercommunicates with dBug using a serial command-line interface which isthen reused by the uClinux as a system console.

Please see the dBug documentation available on the board support CD,or visit www.freescale.comfor more details on how to use and configure the dBug environment. Lookfor the MCF_DBUG product in the Design Tools section of a particularproduct summary page.

To view the uClinux startup process after it is invoked from dBug bya “go” command, go to iClinux Startup. 

When the device is running, you may try connecting to it from aregular Internet Explorer browser. The default device address assignedby the startup script “/etc/rc “is 169.254.100.100 . Thisaddress remains valid until the “udhcpc “application discovers a DHCP server and requests an address moresuitable for the local network.

At any time on the device console, you may issue the “ifconfig ” command which gives youinformation on what address is currently assigned to the TCP/IPnetworking layer.

Conclusion
The choice of using the uClinux operating system just to implement thenetwork interface seems, even to us, as an overkill today. Using one ofthe commercially available TCP/IP drivers, or the freely availableOpen-TCP stack would perhaps better suit this kind of application.

On the other side, we began this project to demonstrate the eTPUcapabilities and to show how it helps off-load the main CPU fromextensive and time-consuming work. And what might be a betterdemonstration than the Logic Analyzer working simultaneously with theoperating system core, networking services, and the web server?

More information on this application and access to all of the sourcecode and the uClinux system files that need to be modified for theLogic Analyzer application is available for download at Embedded_logan_codeas a 1.81 MB zip file

Included in the download is a complete S-record image of theapplication suitable for the M5235BCC evaluation board. In addition tothe configured uClinux kernel and all the binary applications developedfor the Logic Analyzer device, the image also contains theweb-server-side HTML pages and a prototype of the visualizationcomponent self-installing cabinet file.

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

To read Part 1in this series, go to Thebasics of using an enhancedTPU.

Leave a Reply

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