The Embedded Beat: Freescale Blog Community - Software Meets Silicon

Is Moore’s Law relevant when it comes to the edge nodes of IoT, or is it all about packaging now?

r62516@freescale.com — Sat, 11 May 2013 02:01:39 GMT

A couple of weeks ago I was a part of the panel at the GSA Silicon Summit.

The overview of the summit was described by the GSA team on their web-site as:

“Moore’s Law has transcended computing expectations; however, its promise will eventually reach scalability limitations due to extraordinary consumer demands. Future technology encompasses breakthroughs capable of interaction with the outside world, which the More than Moore movement achieves. Through integrating functionalities that do not scale to deliver cost-optimized and value-added system solutions, this trend holds significant potential for the industry. This event will explore the business and technical factors defining the More than Moore movement, and address how it will yield revolutionary electronic devices.”

In a way (just my two cents here, and not a reflection of what GSA organizers told me), the organizers were politely questioning how relevant Moore’s law will be in the future. I was part of the panel titled “Disruptive Innovation – Enabling Technology for the Connected World of Tomorrow,” which was moderated by my long time industry friend Dan Rabinovitsj, who is the SVP & GM of Wired & Wireless Infrastructure Networking BU at Qualcomm Atheros, and the discussions turned out to be great and at times controversial. No, not about Moore’s Law, but ironically about the role of cellular operators in the IoT (refer to my recent blog about the role of Smart phones and IoT).

So back to the topic of Moore’s Law, which was an observation that actually was made by Gordon Moore of Intel, in 1965. Back then he said that the number of transistors per square inch on integrated circuits had doubled every year since the integrated circuit was invented, and that the trend would continue for the (back then) foreseeable future. Later on that pace of doubling per year slowed down to around every 18 months, and hence the current definition of Moore's Law, uses the 18 months number.

In previous blogs we looked at the “box level” building blocks of the IoT from the edge node all the way through the cloud. As outlined in my original white paper, embedded processing is present throughout the entire system, and one may say that indeed it is embedded processing that is the central point in making IoT happen. Depending on the application and what part of the system we are considering, embedded processing which acts as the “brain” of the system, works hand in hand with a variety of other technologies to accomplish its objectives.

In this blog, I want to focus on the edge products, which as can be seen, include the most amount of diversity of the “box level” products. The types of edge/sensing nodes needed for the Internet of Things vary widely, depending on the applications involved. Edge nodes (sometimes also referred to as “leaf nodes”) could include a camera system for image monitoring; water or gas flow meters for smart energy; radar vision when active safety is needed; RFID readers sensing the presence of an object or person; doors and locks with open/close circuits that indicate a building intrusion; or a simple thermometer measuring temperature. The bottom line is that there could be many different types of edge nodes, depending on the applications. Who could forget the heat-seeking mechanical bugs that kept track of the population of a building in the movie Minority Report? Those mechanical bugs represent potential edge nodes of the future. These nodes all will carry a unique ID and can be controlled separately via a remote command and control topology, and all could/would include:

An MCU
Sensors and actuators
Integrated modem chip (connectivity)
Energy source

As mentioned in previous blogs, these nodes need to be very small, low cost, low power, low complexity, and robust. Here are a couple of examples, with one being an event monitoring module, and the other Medtronics’ glucose monitoring device that uses Bluetooth to communicate with various gateways. The edge node will always be communicating with a gateway/hub, which in turn will communicate with the core network and cloud based processing.

From a pure volume perspective, the number of edge nodes will dwarf all other markets in the world. Allow me to explain. Today the ultimate consumer devices with very high volume is the cell phone market. In my household, my wife and I each have a smart phone. We have two daughters, and in 5-7 years each will have their own smart phones, so my household will have four smart phones in five to seven years. If I count every door that opens up, every window that opens up, every appliance, and every electrical wall outlet, every smoke detector, thermostats, light switch, sprinkler zone controller, etc., my house has between 68 to 100 IoT edge node potentials that could be connected to the one gateway box inside of our house. So in five to seven years we would be comparing four smart phones to minimum 68 edge node boxes. This was a household example where there are smart phones present there. In most other IoT applications (think factory process automations, road infrastructure IoT, logistics, environment, etc.) there are no cellular phones involved. Hence the volume of IoT edge nodes will dwarf our existing consumer volume devices volumes by orders of magnitude.

The pictorial above can show the diversity of the types of sensing nodes inside a connected home. From an underlying silicon and packaging technology perspective, edge nodes have very little digital CMOS silicon in them, to be subject to Moore’s law. The types of connectivity we are talking about here all have very small basebands, and bigger RF and analog circuitries. The power source (whether battery or an energy harvester) will have very little to do with Moore’s law, and the sensors are mostly about MEMS, electromechanical circuits and analog, than any Moore’s law related CMOS. The MCU will have the most to do with Moore’s law, but even there, this class of MCUs, will be dominated by the precision analog circuitry and non-volatile memory (NVM), and the core and sea of gates will be the smaller part of the die. So from a system level perspective, the product volume runner of IoT, will have very little to do with Moore’s law.

When you look at the diversity of technologies in the edge nodes, such as precision analog, MEMS, RF, Flash, battery and or rechargeable coils (wireless charging) or energy harvesters, antennas of different shape, etc., you realize that bringing all of these technologies together cost effectively, operating under industrial or auto specifications, and shrinking them while optimizing the system performance, is really a herculean packaging challenge, and not a silicon integration exercise.

This is the part of the industry that has relatively been neglected and not a lot of innovations have been happening, however there is a type of packaging technology that can address the integration challenges of the edge nodes of IoT, and while I normally stay away from “pitching/pushing” products, in this case I will be making an exception, and in my next blog I will introduce you to Freescale Redistributed Packaging technology (RCP).

Kaivan Karimi is Director of Global Strategy and Business Development, MCUs at Freescale and can be reached at kaivan.karimi@freescale.com.

Sensor fusion and the Internet of Things (IoT)

r62516@freescale.com — Sat, 11 May 2013 02:04:13 GMT

Last month I had a paradigm shifting experience in Europe, when I presented a paper about The Role of Sensor Fusion and Remote Emotive Computing (REC) in the Internet of Things (IoT). I had presented this paper in the U.S. multiple times to a few analysts and reporters, as well as at a couple of different forums and shows. The reaction that I got from the European audience was completely different than what I had experienced in the US, and made me realize how different the experience of IoT could be in Europe versus the U.S.

Now about the topic and setting up the context to the reaction I received from that audience. The paper was about the pervasiveness of sensor technology and how the sensors are experiencing a renaissance of sorts as micro-electromechanical systems (MEMS) technology is becoming less expensive and further miniaturized, in turn fueling penetration of sensors into new applications and creating new potential for the sensor market. Sensors are now found in a wide variety of applications, such as smart mobile devices, automotive systems, industrial control, healthcare, oil exploration and climate monitoring. Sensors are used almost everywhere, and now sensor technology is beginning to closely mimic the ultimate sensing machine … the human being. The technology that allows this to happen is sensor fusion, which leverages a microcontroller (a “brain”) to fuse the individual data collected from multiple sensors to get a more accurate and reliable view of the data than one would get by using the data from each discrete sensor on its own. Sensor fusion creates a situation in which the whole is much greater than the sum of its parts.

Sensor fusion enables context-awareness, which has huge potential for the Internet of Things (IoT). Advances in sensor fusion for remote emotive computing (emotion sensing and processing) could also lead to exciting new applications in the future including smart healthcare. However, these capabilities spark significant privacy concerns that IoT governance will need to address. Massive amounts of context-aware data will become available as use of sensor fusion and REC technologies increases. This data, along with the IoT’s access to the “global neural network in the sky” and cloud-based processing resources, will lead to a tremendous expansion in the delivery of context-aware services, customized for any given situation.

When combining all of these technologies, sensor fusion takes the simultaneous input from the multiple sensors, processes the input and creates an output that is greater than the sum of its parts. Sensor fusion provides a whole host of capabilities that can make our lives easier and enables a variety of services that can leverage these capabilities.

Research shows that heart rate increases due to physical activities have a different pattern and slope than increases due to adrenalin from excitation. Hence, one can use algorithms and analyze sensor data to electronically detect the types of emotion a person is displaying.

Here’s an example of a gaming platform that can detect emotions electronically by monitoring and data acquisition from physiological variables and states, such as:

Muscle relaxation (MR) – via a pressure sensor
Heart rate variability (HRV) – via a two-electrode ECG on a chip
Sweat (S) – via a capacitive sensor
Attitude (A) – via an accelerometer monitoring a person’s state of relaxation (jerky movements vs. steady hands)
Muscle contraction (MC) – via a pressure sensor

Using the sensor data collected, an MCU in the game platform could, for example, detect emotions and give the gamer feedback during game situations to make the game more exciting. How about making turns faster and more difficult to maneuver in a driving game until the gamer shows a more relaxed state (a less jerky reading from the accelerometer)? Hence, the calm driver with better command over his/her emotions will have a better score (similar to real life). This would be considered local emotive computing if the local console’s MCU provided the processing function or remote emotive computing if a cloud-based system provided the processing function. In a cloud-based system, sophisticated “big data” algorithms can be leveraged to provide a more elaborate response to the gaming scenario.

In another example, sensors could be used to detect emotion by measuring the way a user holds a cell phone to type or make a call. Furthermore, software algorithms could be used to provide additional context as to the state of mind of the individual by analyzing the way the person texts, how jerky the phone movement is or how many mistakes are made while typing (use of backspace key).

The addition of sensor fusion platforms and remote emotive computing dramatically increases the capability of the sensing nodes in the IoT. In using contextual information to formulate a deterministic action, context interfaces occur within (and in between) first a human being, then the environment and, lastly, machine and infrastructure elements. Nothing detects and provides the readout of human beings’ emotions the way sensors do. Sensors provide access to the human mindset, making an experience more “personal.” Now what’s the most secret and precious thing that a person holds and usually is difficult to obtain, unless the person volunteers it? It is the person’s emotions and their reaction to their various stimuli? What if sensor fusion would allow a service provider know exactly how you feel when you are exposed to a certain product, location, environment, etc? What is the value of that information to the people who are the providers of those goods and services? Do you really want the world to have access to your most inner feelings, and what your wife or significant other may not know, the local service provider to know?

In previous blogs we had already talked about the privacy issues on the existing internet of people, without any notion of sensor fusion. This was the exact concern the Europeans had, the sense of loss of their privacy. During my talk, you could hear a pin drop in the auditorium of close to 500 people, and after the talk there was more time spent by the audience explaining to me the privacy laws in Sweden and Germany, than any of the technical discussions I was used to from my US presentations. The best way of describing the situation was that the audience was completely freaked out of the notion of a big brother reading their emotions … what a difference compared to the US where we the people have clicked away a lot of our privacy rights via “click-through” terms and conditions in an excitement to use the latest apps on our smart phone. In the US, it’s all about the technical discussions and the price points, and somehow we have all accepted the fact that “commerce” is the big brother we have created for ourselves, so cheap access to the latest and greatest apps. I have now come to understand that security and privacy of IoT will follow different paths in the US vs. Europe. Which model do you prefer?

Kaivan can be reached at kaivan.karimi@freescale.com.

The i.MX 6 series: Getting it done (Part 3 of capabilities convergence, device divergence)

admin@community.freescale.com — Thu, 03 Jan 2013 15:08:48 GMT

The i.MX 6 Series Ecosystem

As part of Freescale’s premiere series of Smart Application Blueprint for Rapid Engineering (SABRE) market-focused development systems, Freescale has deployed three SABRE designs focused on automotive infotainment, smart devices, and the general embedded market, as well an evaluation kit (EVK) based on the i.MX 6SoloLite, which drives current and next-generation electronic paper display (EPD) panels. The SABRE board for smart devices, SABRE platform for smart devices, SABRE for automotive infotainment and the i.MX 6SoloLite EVK provide customers with the board layout, circuit design, software and other documentation necessary to quickly produce their own i.MX 6 series-based platforms.

Freescale has been working with the leading embedded system design companies, OS vendors, tools vendors, and application developers to create one of the broadest ecosystems in the industry supporting the i.MX 6 series. This is a critical aspect to the i.MX 6 series as it enables broad choices and options in designing products for the processor family. And with the recently improved online i.MX Community within the Freescale Community, the ability to find answers to your design and development questions has never been easier.

In Summary

The market for intelligent devices is increasing exponentially. Tomorrow’s smart devices, auto infotainment and in-flight entertainment systems, medical systems, personal and enterprise-class intelligent control and data systems, and new classes of devices never before seen need to present data and user interface choices to the end user primarily through rich sound, video, voice, pictures and touch, rather than keyboards and mice.

The need for manufacturers to quickly provide multiple devices to fit specific market segments or niches and provide their customers with a broader range of choices is increasing just as quickly. The i.MX 6 series was designed specifically to enable this new market by bringing together high-performance scalable multimedia processing, a software-compatible family of five processors and pin*-compatible processor solutions with integrated power management so that a manufacturer can deploy a full portfolio of products with a single hardware design.

Let's make it real - Internet of Things

admin@community.freescale.com — Tue, 13 Nov 2012 18:36:09 GMT

People have been talking about the “Internet of Things” for years with the promise of creating a connected world. I was fascinated by “The Jetsons” as a kid and I realize now that it was an early look at the “IoT” world. Ok, yes, “The Jetsons” is a bit of a stretch of the imagination, even today. But, in reality the transition to “IoT” is happening and is being accelerated by technologies that transform devices from being information gatherers, to being part of a smart system where the data collected provides consumers with real improvements to their lives.

What I've found from my experience at Freescale is that creating and implementing these smart systems takes an ecosystem – no one company can cover the gamut of needs. Not only are ecosystems valued now, they are important and necessary to provide complete solutions. More importantly, it’s not about how many partners are in your specific ecosystem – it’s about having the RIGHT partners.

As I stated, the “IoT” is everywhere, some people even use the term “Internet of everything.” At ARM TechCon which was held in Santa Clara a couple of weeks ago with >90 exhibitors and 5,000 attendees, the “IoT” as a reality was certainly obvious as I walked through the show floor. The picture below highlights an example of a RIGHT ecosystem with Freescale and Oracle. Our company booths were back-to-back and Oracle showcased demos based on i.MX processors running Java SE Embedded.

The shot shown above uses Freescale and Oracle technologies. The SABRE Lite board, based on the i.MX 6Quad processor, is used as the aggregator for the smart grid – it receives data from a power meter and then sends it to the utility company for analysis and action. The i.MX 6Quad processor that’s acting as the aggregator is part of Freescale’s newest ARM applications processor family, the i.MX 6 series, which was launched this week. This platform addresses the needs of the “IoT” – scalability, flexibility, performance and low power. The aggregator also communicates to an i.MX based tablet with a user interface (built using Java FX) to view the data. As the saying goes, with knowledge comes power. Consumers can manage their own energy usage to improve their lives if they have the right data and tools to do so.

A partnership between Freescale (makers of applications processors based on ARM technology) and Oracle (makers of Enterprise software) may not seem like a customer-centric partnership at first. However for the “IoT” to become a reality all devices from the enterprise to the edge must be connected and secure. Oracle’s vision is that Java is not only the platform running in the enterprise but also on edge embedded devices based on ARM processors such as Freescale’s i.MX processors. Couple the power and performance of the i.MX portfolio on the embedded side, with the dynamic and growing Java developer community – and the devices that we can see in the future are limited only by the imagination. Heck, who would have thought about a ‘connected’ thermostat five years ago?

Processor Expert Component Adds Touch to the Freescale Freedom Development Platform

admin@community.freescale.com — Wed, 31 Oct 2012 09:59:21 GMT

Through the use of tutorials, I have covered several features of the Freescale KL25Z Freedom development platform: its RGB LED, its accelerometer and the RTOS. My coverage has missed one useful peripheral thus far that is in plain view—the touchpad slider area (Figure 1). It is time I set matters right with this blog article.

Figure 1. Touchpad slider area (outlined in red) on the Freescale Development Platform.

The Kinetis L Series MCU has implemented a Touch Sensing Interface (TSI) module in the silicon. It helps a lot when implementing a capacitance touch sensing application, but requires a lot of reference manual reading. See Tom Thompson’s recent blog article for a bare-metal implementation of a touch-sensing application using the TSI module on this board.

However, the article covers only a few of the many features the TSI has to offer. Features left unexplored are hardware-triggered scans and low-power mode operation, for example. Accessing more of the features at this level requires further heavy-duty reading. Banging on the bits can be a lot of fun, but it is also really hard and time consuming. Learning the deep intricacies of any silicon system and training it to jump through hoops is not necessarily the best use of your time. Software development cycles are fleeting and we know you often want ready-made embedded software solutions rather than having to reinvent the wheel.

Fortunately, there is a Processor Expert component that both simplifies this task for you and provides access to all of those nifty features. So in this tutorial I shall present Processor Expert’s Touch Sensing Software (TSS) Library component. Combine this with Tom’s article, and you can see both the power of bit banging, and the ease of the Processor Expert Software solution.

I shall not repeat the details in creating a Processor Expert project with CodeWarrior for MCUs v10.3 here. You should be able to find all the needed information in the LED, Accelerometer and RTOS tutorials.

Alternatively, if you do not want to start from scratch, you can add the touch support to any of the above tutorial projects.

Adding the TSS_Library Processor Expert component

Start by creating a CodeWarrior project based on the KL25Z MCU, and activate the Processor Expert tool. From the Components Library view, I add the TSS_Library component to my project. This is done by right-clicking on the component and selecting Add to project from the context menu (Figure 2), or with the + icon in that view, or by double-clicking the TSS_Library component.

Figure 2. Adding the TSS_Library component.

Now that we have added the software, it is time to start configuring the interface. This means we need to know what port and its pins connect to the electrodes that implement the touchpad. A glimpse of the board schematic reveals that the two electrodes are connected to PTB16/Channel9 and PTB17/Channel10 (Figure 3).

Figure 3. The electrode lines (TSI_CH09 and TSI_CH10) connect to Port B, pins PTB16 and PTB17.

First, this component needs to support two electrodes. To do this, I select the TSS_Library_Component in my project. In the Component Inspector view, I click on the + sign in the Number of Electrodes properties item to increase the electrode count to two (Figure 4).

Hint 1: If the Component Inspector view is not visible: select Inspector when right-clicking the TSS_Library icon.

Hint 2: In order to display the + and - buttons to change the electrode count as shown in the screenshot, I need to click in the field to select it.

Figure 4. Adding an electrode using the Number of Electrodes property.

Having configured the component to support two electrodes, I continue merrily along in the Properties view to couple the channel connections (Figure 5) to the appropriate port. These elements are marked in yellow in the figure.

Figure 5. Specifying the electrode/channel connections.

Configuring the Controls

The elegant feature of this Processor Expert component is that it provides point-and-click support for all kind of human interface controls, and specifies how they generate values and responses to user events. So I add a slider control, and for now I go with its default settings (Figure 6):

Figure 6. Configuring the human interface control for type and output range.

As the screenshot shows, the control has been configured as an ASLIDER (Analog Slider) control. I have it configured so that it has a range of 0 through 64, and that the range values are stored in a structure named TSS1_cKey0. This structure name and value range is what we will use later when the TSS library detects a touch.

Adding LEDs

In my code I want to show the status of the slider (that is, that the slider was touched and where) using the RGB LED on the board. I will not explain how to add the add LED components to my project, as this is explained in detail in the LED tutorial.

Hint: I can copy-paste the LED component from my other tutorial projects. That way it only takes seconds to have it in my new project.

When done, the Components view should resemble Figure 7.

Figure 7. Project with LED components added.

Generating Processor Expert driver code

Now I can generate the driver code based on my settings. The simplest way is to select the project and click Generate Processor Expert Code (Figure 8):

Figure 8. Generating Processor Expert code.

Processor Expert tool places the code it produces into the files TSS1.c and TSS1.h, which are located in the Generated_Code project folder (Figure 9).

Figure 9. Generated TSS Driver Code with TSS Files.

Initializing the TSS library

Now that I have the code in the project, it is time to make use of it. For the TSS library APIs to function properly, I have to initialize it. For this I need to call Configure(). An easy way to provide that function is to drag and drop that method into my source code (Figure 10):

Figure 10. Configuring the TSS Library via drag and drop.

With the library initialized, to capture user events I need to call the TSS library periodically using TSS_Task(). So in main()I need to add this function call to the event loop, like so:

int main(void)

/*lint -restore Enable MISRA rule (6.3) checking. */

{

/* Write your local variable definition here */

/*** PE internal initialization. DON'T REMOVE THIS CODE!!! ***/

PE_low_level_init();

/*** End of PE internal initialization. ***/

Configure(); /* initialize TSS library */

for(;;) {

TSS_Task(); /* call TSS library to process touches */

}

/*** Don't write any code pass this line ***/

/*** RTOS startup code. ***/

#ifdef PEX_RTOS_START

PEX_RTOS_START(); /* Startup of the selected RTOS. */

#endif

/*** End of RTOS startup code. ***/

/*** PE end of main routine. DON'T MODIFY THIS CODE!!! ***/

for(;;){}

/*** PE end of main routine. DON'T WRITE CODE BELOW!!! ***/

} /*** End of main routine. DO NOT MODIFY THIS TEXT!!! ***/

The function TSS_Task()detects if the slider has been touched, and invokes a callback function to handle the event. This callback is named fcallBack(). For my first (and only) control in the system this callback function is TSS1_fCallback0(), as shown in Figure 11.

Figure 11. The callback function that is invoked when the slider is touched.

Double-clicking on that callback event opens the editor view to the user callback function code. This code is in the source file Events.c (Figure 12).

Figure 12. The placeholder stub for the slider callback function.

Remember the Range and Structure Name we defined when configuring the control? Now it is time to use those items here and to turn on an LED. Which color LED glows depends upon the range value. This is implemented with following code:

void TSS1_fCallBack0(TSS_CONTROL_ID u8ControlId)

{

(void)u8ControlId; /* avoid warning */

LED1_Put(TSS1_cKey0.Position<=20);

LED2_Put(TSS1_cKey0.Position>20 && TSS1_cKey0.Position<=40);

LED3_Put(TSS1_cKey0.Position>40 && TSS1_cKey0.Position<=64);

}

Here the library provides a value in TSS1_cKey0 that has been scaled through the range of 0 through 64. You do not need to know gritty details of the algorithm that converts the slider capacitance reading into a range value that represents a position on the slider.

Touching It

After all of the set up work, the rest is easy: compile, download and run the code on the board. With my value arrangement, LED1 is on if I touch the slider on the left (Figure 13), LED2 is on if I touch it in the middle (Figure 14), and LED3 is on if I touch it on the right (Figure 15).

Figure 13. Touch on the left: red LED lights up.

Figure 14. Touch the slider’s middle to light up the green LED.

Figure 15. Touch on the right: blue LED aglow.

Summary

Using the capacitive touch capability of a device is usually not easy. However, the TSS Library Processor Expert component delivered with the Eclipse-based CodeWarrrior IDE for MCU 10.3 simplifies matters significantly. As this tutorial shows, in a few minutes you can put the touch slider on the Freescale Freedom development platform to use by just pointing and clicking, and adding a little code. Of course, there are a lot of settings that you can fine-tune (sensitivity, resolution, kind of controls), but I hope this gives you an idea what can be accomplished in a short amount of time. Additionally, there is a lot of documentation about the TSS library available here.

The sources for the project discussed in this tutorial are available here.

Happy Touching!

Software and hardware breakpoints

admin@community.freescale.com — Sat, 27 Oct 2012 18:46:46 GMT

By Erich Styger — As an embedded software developer, the use of breakpoints to debug software is a fact of life. I usually debug my applications in flash memory, because nearly all of the microcontroller units (MCUs) I use have on-chip flash memory, and quite often there is more of it available than RAM. However, debugging code in flash has its problems. One of these is that flash limits the number of breakpoints that I can use during a debugging session. This is because MCUs typically support a limited number of hardware breakpoints. If I debug the code in RAM, I can use software breakpoints, with no practical limit as to the number of them that I can use. The caveat is that code in RAM executes faster than code in flash, and so timing issues can surface when I move the finished code into flash. Given the presence of these different breakpoint types, it is worth explaining how they are different. Armed with this knowledge, we can make better use the hardware breakpoints that are available.

Let me start by explaining the two types of breakpoints.

Software Breakpoints

A software breakpoint is where the debugger replaces an instruction in an embedded program with another one. The new instruction is either an illegal instruction or a dedicated breakpoint instruction that the MCU debugger hardware recognizes. Obviously, to over-write an instruction this way requires that the program reside in RAM. To illustrate how the substitution works, Figure 1 shows some code in RAM starting at address 0×100. The LDA load instruction at the address 0×100 is encoded as 0×3788.

Figure 1. Code in RAM prior to setting a software breakpoint.

I want to set a breakpoint on the multiply (MULA) instruction at address 0×102. Assume that this MCU architecture has a breakpoint instruction encoded as 0xffff. Therefore, the debugger simply writes over the opcode at address 0×102 with the 0xffff BKPT opcode, as shown in Figure 2.

Figure 2. Code in RAM with software breakpoint (red) in place.

When the MCU executes the code at address 0×102, it triggers the debug module in the MCU. What the debug module does at this point is defined in the MCU reference manual. For example, the ARM Cortex architecture supports a breakpoint (BKPT) instruction. I can use this instruction in a custom function to stop the MCU.
void __attribute__((interrupt)) ISR_Unhandled(void) { asm("BKPT 255"); /* sofware breakpoint */ }

When this function executes, it triggers an illegal instruction exception that the debugger module catches. This works, but debuggers can accomplish this job faster and better for the developer. When you set a software breakpoint with the debugger, it simply replaces the existing instruction at the address with a BKPT instruction. However, the debugger does a lot of hidden bookkeeping to match the specified location in the source code with the actual address in memory. Furthermore, it retains a “patch list” of replaced instructions (Figure 3) so that if you later remove the breakpoint, the appropriate instruction is copied back into the corresponding address. This bookkeeping takes place behind the scenes, and allows you to focus on hunting that bug.

Figure 3. Patch list of software breakpoint managed by the debugger.

If for some reason the debugger fails to restore the original instruction, then the software breakpoint remains in place and causes an unexpected processor halt when the MCU reaches it. The debugger might report “illegal breakpoint” or something similar. This situation might be caused by a board or hardware problem. Or, the debugger breakpoint list might have become corrupted. In the latter case it is best to start over and reload the application to the target embedded system.

The good thing about a software breakpoint is that it provides an almost unlimited number of breakpoints. Because changing instructions in RAM is easy for the debugger to perform, software breakpoints are used for applications in RAM.

Some debuggers even apply software breakpoints on code running in flash memory. This usually makes setting and removing breakpoints a time-consuming process, because the debugger has to erase and re-program the flash to modify the breakpoints. Other architectures implement a “patch list” mechanism, similar to what is shown in Figure 2. This makes it possible to “set” software breakpoints within the hardware. This lets me neatly segue into a description of “real” hardware breakpoints.

Hardware Breakpoints

To make debugging in flash memory easier to implement and manage, silicon vendors have added hardware breakpoint capabilities to their MCU cores. A typical hardware breakpoint consists of a dedicated hardware trigger that watches an internal bus or program counter, as shown in Figure 4. If the current address or counter value matches a certain condition—as specified by the debugger—the trigger mechanism activates the debug module. The debug module in turn stops the processor or does whatever the hardware implements for that condition.

Figure 4. A hardware breakpoint mechanism triggering on an address match.

As you might expect, dedicated hardware breakpoint triggers take up silicon on the die, so the number of hardware debug triggers available is quite limited. The ARM Cortex-M0+ at the heart of the Freescale Freedom Development Platform is no exception to this: its Coresight module can implement a maximum of four hardware breakpoints. A good debugger supports both software and hardware breakpoints. However, that raises a question: do I have any control over what type the debugger uses?

Choosing the Breakpoint Type

The CodeWarrior debugger in the Eclipse IDE allows you to specify the breakpoint type. Simply right-click in the blue annotation area on the left side of the Editor view, a drop-down menu appears, and you select what kind of breakpoint to use (Figure 5):

Figure 5. The breakpoint type menu.

Hardware Breakpoints in Eclipse

In Eclipse IDE, the Breakpoints view is where you manage the list of breakpoints. This view is shown in Figure 6.

Figure 6. The Eclipse IDE Breakpoints view.

What happens if the target MCU has only two hardware breakpoints, but I need to set four breakpoints? In Figure 7 below, I set a breakpoint on line 41, then 42, then 43 and finally on line 40:

Figure 7. Setting four breakpoints.

However, only two breakpoints have the check mark, which indicates the breakpoint was successfully set (Figure 8):

Figure 8. Four breakpoints, but only two are set.

This information appears in the Breakpoints view (Figure 9) too:

Figure 9. Status of hardware breakpoints in the Breakpoints view.

Obviously the debugger is using hardware breakpoints, according to the Type column, yet only two are set successfully. Having too many breakpoints set can have some impact on debugging.

Note: I pay close attention to the Breakpoints view to see if my breakpoints have the check mark set or not. Because debugging a problem with a breakpoint not set—and you think that it is—is not very productive. Besides displaying their status, the Breakpoints view also allows me to closely monitor how many hardware breakpoints I have in use. Even if I have not used all of the hardware breakpoints, using a lot of them can have side effects, which I discuss next.

Running out of Hardware Breakpoints

If I happen to launch a debug session that uses too many breakpoints, the debugger politely points this out (Figure 10):

Figure 10. A warning that too many breakpoints are in use.

As a counter measure, Figure 11 shows how I can disable some breakpoints in the Breakpoints view by unchecking them:

Figure 11. Disabled breakpoints (yellow) in the Breakpoints view.

When all of the available hardware breakpoints are set, many debugger features still work, such as normal stepping. However, the use of all the hardware breakpoints can produce side-effects for other stepping cases. Sometimes you are simply stepping throught your code and you abruptly get rewarded with this warning (Figure 12):

Figure 12. What does a stepping failure have to do with hardware breakpoints?

It means that the debugger was not able to set a breakpoint. What happened?

When I “step out” of a function, the debugger needs an extra hardware breakpoint to stop the processor once I step outside of the current function. Unfortunately, if I am using all of the hardware breakpoints, then the debugger cannot set that additional breakpoint outside of the function, and the warning appears.

A solution to this situation is to disable my hardware breakpoints in the Breakpoints view while stepping. However, there is a small trick which can make my life easier.

Skipping Breakpoints Trick

This tip does not solve all use cases, but it certainly helps in those cases where it applies. Usually the CodeWarrior debugger keeps the hardware breakpoints installed during stepping. That way, if you “step over” a function which has a breakpoint set, it triggers inside that function. However, if I am comfortable in using hardware breakpoints for the stepping operation, I can tell the CodeWarrior debugger to skip breakpoints (Window > Preferences > Run/Debug) as shown in Figure 13.

Figure 13. Skip breakpoints during a “Run to Line” operation.

What this option does is to disable all my set breakpoints when I do a “Run to Line” operation. This can be arranged by right-clicking a source line in the Editor view and then choosing Run to Line (Figure 14) in the drop-down menu.

Figure 14: The Run to Line choice in the context menu.

An even easier shortcut is to place the cursor in the Editor view, and type the Ctrl+R shortcut. With this I do not need to disable my hardware breakpoints in the Breakpoints view, yet still can do full debugger stepping. And as a benefit, I’m not tripping over my many otherwise set breakpoints.

Happy Breakpointing!

The Bare Metal Enthusiast: Winding the Clock

admin@community.freescale.com — Tue, 21 Aug 2012 05:08:04 GMT

By Derrick Klotz -- For those of us old enough to remember, a clock or watch had to be wound before it would start working. You also had to set the time. Before anything works properly in a microcontroller unit (MCU), we first need to configure its clock. As you can imagine, this is a little more complicated than spinning a knob on a watch: It involves specifying where the clock gets its source signal from (which is somewhat akin to winding it), and what output frequency it generates to drive the MCU and its peripherals (similar to setting its time).

Frequency Multiplication

Most MCUs employ a frequency multiplication circuit that gives you the ability to generate a high-frequency internal CPU bus speed clock from a lower-frequency input reference clock signal. This reference signal can be either internal to the MCU or an external module (typically an oscillator crystal) connected to certain pins. Deriving the CPU clock from a lower-frequency signal has the benefit in that the overall circuit generates less radio frequency interference. Since crystals that operate at slower frequencies tend to cost less than their higher-frequency counterparts, it can also reduce the parts cost of an embedded system. Quite often we can use an internal clock reference signal generated within the MCU and eliminate the external crystal altogether. Naturally, we need to consider the technical trade-offs of these options.

As shown in Figure 1, the frequency multiplication circuit that generates the high-frequency clock signal is a closed-loop system which continually compares a scaled down version of the output frequency of a variable oscillator (F_OUT ÷ n) to that of an incoming reference clock source (F_REF). In a Phase-Locked Loop (PLL) implementation of the circuit, the signal comparator is a phase detector whose output signal changes relative to the phase difference between the two clock signals. In a Frequency-Locked Loop (FLL) implementation, the output of the signal comparator varies relative to the frequency difference between the two clock signals. Generally, an FLL tends to lock to the desired output frequency faster, but a PLL can have finer frequency granularity (that is, generate a wider range in output frequencies) and less clock jitter (more on that in a moment). In both cases, the output of the signal comparator creates an error signal that, through the loop filter circuit, adjusts the output of the controlled oscillator. In the circuit shown, F_OUT = F_REF × n, where n represents the divide ratio value of the clock divisor.

Figure 1. A closed-loop frequency multiplication circuit block diagram.

It is important to note that the output of the controlled oscillator is manipulated by an error signal and that the circuit strives to make this error zero. But once the error is zero, the oscillator's output frequency begins to change (or drift), thereby causing a non-zero error signal again. This effect causes the output frequency to fluctuate slightly over time and contributes to a parameter known as "jitter".

While there are several other factors involved, in general the lower the frequency of F_REF, the larger the jitter of F_OUT. Conceptually, a low-frequency F_REF provides fewer corrections per second than a faster F_REF. Over the long term, clock jitter generally averages out to zero, but its instantaneous affect can cause havoc with high-speed serial communications peripherals, such as Ethernet, USB and CAN. In these instances, we usually need to have an F_REF of several megaHertz to minimize the clock jitter and its negative effect on the accuracy of the communication signals. This is rarely a concern when using RS232-style communications, which have much-lower frequency rates.

A Simple Implementation

I will use the Internal Clock Source (ICS) found in Freescale’s 8-bit MC9S08PT60 MCU as a reference towards developing a more practical understanding of how to configure an MCU’s clocking system. The block diagram for the external oscillator and the ICS appears in Figure 2.

Figure 2. MC9S08PT60 external oscillator and internal clock source block diagram.

The values at the bottom left are the status flags and control bits involved in the clock configuration.

We can see that the ICS relies upon an FLL for reference clock frequency multiplication. The circuit shown in Figure 1 is contained entirely within the block identified as FLL in Figure 2. Inside the filter we also find the signal comparator and feedback clock divider shown in Figure 1. The output of the filter manipulates the output frequency of a digitally controlled oscillator (DCO). The LP control bit ("Low Power Select") determines whether or not the FLL circuit is operational in the ICS Bypass Modes of operation.

This FLL has been designed to accept an input reference clock (that is, F_REF) in the range between 31.25 kHz to 39.0625 kHz. It then generates an output bus clock of 16 MHz to 20 MHz that most of the MCU logic blocks use. In other words, F_OUT = F_REF × 512. It is that simple. That is all it does. The rest of the circuitry shown in Figure 2 directs and controls the available input and output clocking signals.

Figure 3 shows the ICS's seven modes of operation and how we can move between these states, primarily by manipulating the IREFS and CLKS control bits. As shown in Figure 2, CLKS selects the clock source from an external oscillator, internal reference clock, or the output of the FLL. IREFS controls a signal multiplexer that selects the F_REF input signal for the FLL. We can see that the options for F_REF are either an internal reference clock or the output of the external oscillator after a binary divider.

Figure 3. State diagram of ICS clock switching modes.

From reset, the ICS operates in the FLL Engaged Internal (FEI) mode, which selects the FLL's output and internal reference clock as its input frequency source. It is important to note that the internal reference clock initially operates at an unknown frequency and must be trimmed.

All S08P Family MCU devices are factory programmed with a trim value stored in flash address locations 0xFF6E and 0xFF6F. This value configures the internal reference clock for operation nominally at 32.768 kHz with an ambient temperature of approximately 20°C.

For improved accuracy, the debugger interface can be instructed to measure the untrimmed frequency of the internal reference clock during the flash memory programming procedure. Based upon the desired frequency of operation (that is, between 31.25 kHz to 39.0625 kHz) a 9-bit trim value is calculated and then stored into flash memory, ordinarily at 0xFF6E and 0xFF6F. However, the trim values can be stored in other flash memory locations. This is a feature that is supported by Freescale's Processor Expert software.

It is the responsibility of the application software to write the trim values into the corresponding ICS control registers upon reset. Listing 1 shows the C code generated by Freescale's Processor Expert Software that copies the trim values from flash memory to the appropriate ICS control registers.

[sourcecode]
/* Initialize ICS_C3 register from a non volatile memory */
ICS_C3 = *(uint8_t*)0xFF6FU;/* Initialize ICS_C4 register from a non volatile memory */
/* Initialize ICS_C4 register from a non volatile memory */
ICS_C4 = (uint8_t)((*(uint8_t*)0xFF6EU) & (uint8_t)0x01U);
[/sourcecode]

Listing 1: Copying the trim values into the ICS internal reference clock registers.

Once trimmed, the frequency deviation of the DCO output frequency is specified to be no worse than ±2.0 percent across the full operating ambient temperature range of -40 to 105°C and better than ±1.0 percent between 0 to 70°C. In order to determine whether or not this accuracy is sufficient, we need to consider the clocking needs of the MCU's peripherals, as determined by the application.

One commonly-used peripheral with specific timing requirements is the Serial Communication Interface (SCI) used for RS-232/RS-485 communications. The clocking requirements for the SCI are normally determined by its ability to generate industry-standard baud rates. One beneficial characteristic of Freescale's SCI is that it resynchronizes its internal timing reference on every high-to-low incoming signal transition. If we do the math, we would find that this mechanism allows the worst case baud rate mismatch to be about ±4.5 percent when using 8-bit formatted data. This provides some flexibility in the MCU's bus clock speed selection and easily accommodates the FLL's DCO-specified frequency deviation as indicated above.

All industry standard SCI baud rates can be achieved by using the Internal Reference Clock and trimming it to 36.0 kHz. The FLL multiplies this by 512 resulting in a bus clock rate of 18.432 MHz. Using integer values in the SCI Baud Rate Register, the common baud rate values of 4800, 9600, 19200, 57600, and 115,200 can all be easily obtained. As specified, the worst case frequency deviation for the FLL's DCO is ±2.0 percent (-40 to 105°C). This is sufficiently better than the required ±4.5 percent, as described above. Hence, no external clock or crystal is required for applications where asynchronous serial communications dictates the most stringent timing requirements. In these situations, using the Internal Reference Clock is the practical and lowest cost option.

Some applications need the timing accuracy that can only be achieved with a crystal oscillator. The MCU's reference manual and data sheet provide the information needed to connect a crystal to its XTAL and EXTAL pins. The application software needs to first enable the External Oscillator and then wait for it to initialize and stabilize before switching modes from FEI to FEE (FLL Engaged External). Changing the IREFS bit achieves the mode switch.

The ICS has been designed to accommodate the higher frequencies commonly available for crystals. We can see in Figure 2 that the "RANGE" and "RDIV" control bits are used to configure prescale dividers that bring the external clock frequency within the range required by the FLL. Table 1 summarizes how these control bits affect the allowable crystal frequency range.

Range	RDIV	Divide-by	Crystal Frequency range
0	000	1	31.25 kHz to 39.0625 kHz
0	001	2	62.5 kHz to 78.125 kHz
0	010	4	125 kHz to 156.25 kHz
0	011	8	250 kHz to 312.5 kHz
0	100	16	500 kHz to 625 MHz
0	101	32	1 MHz to 1.25 MHz
0	110	64	2 MHz to 2.5 MHz
0	111	128	4 MHz to 5MHz
1	000	32	1 MHz to 1.25 MHz
1	001	64	2 MHz to 2.5 MHz
1	010	128	4 MHz to 5 MHz
1	011	256	8 MHz to 10 MHz
1	100	512	16 MHz to 20 MHz
1	101	1024	not supported
1	110	reserved	not supported
1	111	reserved	not supported

Table 1. RANGE and RDIV Values and their corresponding valid external frequencies.

The FLL can be bypassed using the ICS's four remaining operational modes. FLL Bypassed Internal (FBI) derives the output clock directly from the Internal Reference Clock, resulting in bus frequencies of 39.0625 kHz or slower. FLL Bypassed External (FBE) uses the External Oscillator as the clock source. In both of these modes, the FLL remains active and operational with its F_REF × 512 output available through just a simple change in the CLKS bits. If this is not required, each of these modes has a low-power option (FBILP and FBELP respectively) which disables the FLL.

Low power Stop mode can be entered from any ICS state by executing the STOP instruction. A reset or an interrupt cause the MCU to exit Stop mode. Reset places the ICS back into FEI mode. An interrupt triggers the execution of an Interrupt Service Routine (ISR); it does not change the mode. When the code returns from the ISR, it then continues operation from the point just after the STOP instruction.

An Example

So far I have described using the FLL with either the Internal Clock Reference or the External Oscillator to create a bus clock in the range between 16 MHz to 20 MHz. Sometimes we do not want to run this fast. MCU power consumption is directly proportional to the bus speed, so when we need to save power we run the MCU at a slower speed. Referring once again to Figure 2, we can see a bus frequency divider that is controlled by the BDIV bits. This provides the ability to divide the clock output by 2ⁿ, where n = 0 to 7. Doing a little math, we find that we can use the Internal Reference Clock with the FLL and get the bus speed down to 125 kHz (that is, 16 MHz ÷ 128). If that is still too fast, we can configure the CLKS control bits to bypass the FLL and use the Internal Reference Clock directly. Now we can get all the way down to 244 Hz (that is, 31.25 kHz ÷ 128). That is pretty slow. Probably too slow to be very practical, but it makes the point that the ICS gives us a wide variety of frequency options.

One of the real benefits to using the bus frequency divider is the ability to "gear shift" the bus clock. Stated another way, when the BDIV bits change, the bus speed responds by immediately changing its frequency—without missing a beat. This allows us to use a higher bus speed when we need more computational performance, and then switch to a slower frequency for reduced power operation.

As an example, let's consider an application which:

runs without a crystal
uses a high-bus speed for computational requirements
uses a low-bus speed for minimum power operation most of the time
needs to monitor and react to SCI communications that occur at 9600 baud

We need to figure out how fast and how slow we can run the bus to meet these criteria. Let us start with the SCI. The minimum SCI baud rate division is the bus speed divided by 16. So the slowest bus speed with which we can still run the SCI at 9600 baud is 9600 × 16 = 153.6 kHz. This is how fast that we'll run the bus during the minimum power operating phase. To get there we'll configure the BDIV bits to divide the FLL output by 128. Reversing the calculation gives us the required FLL output frequency: 153.6 kHz × 128 = 19.6608 MHz. This is within the specified 16 MHz to 20 MHz range so everything looks good so far. Next we need to calculate how to get the FLL to run at 19.6608 MHz. Recall that the FLL will multiply its input signal by 512. This gives us the frequency that we need to trim the Internal Reference Clock: 19.6608 MHz ÷ 512 = 38.4 kHz.

To summarize, we will trim the Internal Reference Clock for 38.4 kHz and set BDIV for divide-by-1. This will provide a bus speed of 19.6608 MHz during the computational phase of operation. The SCI baud rate register will be configured to divide the bus speed by 128, resulting in a baud rate of 9600 (i.e., 19.6608 MHz ÷ 16 ÷ 128 = 9600). To make the switch to minimum power we lower the bus speed to 153.6 kHz by changing BDIV to divide-by-128. We'll also modify the SCI baud rate register for divide-by-1 so that the SCI will continue to operate at 9600 baud.

Seems pretty simple.

Lots of Clocking Options

Now let's take a look at something a little more complex. Figure 4 is a block diagram of the Multipurpose Clock Generator (MCG) within Freescale's 32-bit ARM Cortex-M4 Kinetis Family of MCUs. This specific diagram applies to the most recent 100MHz versions of the K10, K20 and K60 MCUs.

Figure 4. Kinetis Multipurpose clock generator block diagram.

At first glance this figure may appear to be a little daunting, but most of the blocks should look familiar. We can see that there is an FLL very similar to what we saw in the ICS. The Internal Reference Clock Generator provides the same reference source with the same frequency trim range of 31.25 kHz to 39.0625 kHz. This signal is identified as the "Slow Clock" and is trimmed with the SCTRIM and SCFTRIM registers. There is also a separate "Fast Clock" created by the Internal Reference Clock Generator that is trimmed to a frequency of 4 MHz via the FCTRIM register. The Fast Clock does not feed into the FLL.

Kinetis MCUs are designed upon reset to automatically load the Internal Reference Clock Generator trim registers with pre-programmed factory-calibrated values. These configure the Slow Clock for 32.768 kHz and the Fast Clock for 4 MHz. The SCTRIM and SCFRTIM registers can be loaded by application software to trim the Slow Clock to a different frequency within its specified range. The Fast Clock can be trimmed between 3 MHz and 5 MHz by writing to the FCTRIM register. The C code generated by Freescale's Processor Expert Software that copies values into these registers from Flash appears in Listing 2 and should look familiar.

[sourcecode]
/* Initialize MCG_C3 register from a non volatile memory */
MCG_C3 = *((uint8_t*) 0x03FFU);

/* Initialize MCG_C4 register from a non volatile memory */
MCG_C4 = (MCG_C4 & 0xE0U) | ((*((uint8_t*) 0x03FEU)) & 0x1FU);
[/sourcecode]

Listing 2. Copying the trim values into the MCG Internal Reference Clock generator registers.

The MCG also has a PLL that relies solely upon an external oscillator source for its clock reference. The input frequency range for F_REF PLL is between 2 MHz and 4 MHz.

The MCG generates several clocking signals. It is important to understand how each of these are created in order to determine how we can put them to use.

MCGIRCLK is an internal reference clock that can be sourced from either the Slow Clock or the Fast Clock of the Internal Reference Clock Generator, depending upon the setting of the IRCS control bit. MCGIRCLK is a signal available for the MCU's Low Power Timer and Touch Sense Input peripherals, thereby providing a way to keep these circuits operational during MCU low power states.

MCGFFCLK is a fixed frequency reference that is derived from the FLL's input, F_REF FLL, and provides an alternate clocking source for the MCU's FlexTimers. MCGFFCLK is synchronized with the peripheral bus clock (BUSCLK) and is only valid when its frequency is not more than one-eighth of the MCGOUTCLK frequency, otherwise it is disabled.

MCGFLLCLK and MCFPLLCLK are the output signals of the FLL and PLL, respectively. A multiplexing selection within the MCU's System Integration Module (SIM) chooses which of these clocks serves as a timing reference option for various on-chip peripherals.

MCGOUTCLK is the principal clock signal that drives the CPU core, the internal bus, the external FlexBus, and the flash memory. Figure 5 shows the MCG's nine modes of operation which impact the generation of the MCGOUTCLK signal. Once again we can see that the primary control bits that switch among these modes are IREFS and CLKS. These bits work much the same as they did in the ICS. PLLS is an additional control that selects between the FLL and the PLL.

Figure 5. State diagram of MCG clock switching modes.

The PLLCLKEN0 control bit has the ability to enable the PLL even if it is not being selected by PLLS. This allows the system clock to be derived from the FLL while some peripherals, such as the Ethernet and USB interfaces, can be clocked from the PLL. These selection options are summarized in Table 2.

PLLS	PLLCLKEN0	FLL	PLL
0	0	selected	disabled
0	1	selected	enabled
1	0	disabled	selected
1	1	disabled	selected

Table 2. FLL and PLL selection and enable control using the PLLS and PLLCLKEN0 bits.

As we can see in Figure 5, coming out of reset we are going to be in the FEI mode. Once the internal reference has been trimmed, nominally at 32.768 kHz, the default configuration for the FLL coming out of reset results in a system clock frequency of 20.97 MHz.

The FLL in the MCG provides us with more frequency multiplication options than we have with the ICS. These are selected with the DMX32 and DRS control bits and their affect on the FLL's frequency multiplication is shown in Table 3. The DMX32 bit provides us with a higher frequency multiplication option when we use the popular 32.768 kHz as a reference.

DMX32	DRS	Multiply-by	F_REFFLL Frequency Range	FLL Output Range
0	00	640	31.25 kHz to 39.0625 kHz	20 MHz to 25 MHz
0	01	1280	31.25 kHz to 39.0625 kHz	40 MHz to 50 MHz
0	10	1920	31.25 kHz to 39.0625 kHz	60 MHz to 75 MHz
0	11	2560	31.25 kHz to 39.0625 kHz	80 MHz to 100 MHz
1	00	732	32.768 kHz	24 MHz
1	01	1464	32.768 kHz	48 MHz
1	10	2197	32.768 kHz	72MHz
1	11	2929	32.768 kHz	96MHz

Table 3.DMX32 and DRS values and their corresponding FLL frequencies.

Under normal "set-and-forget" circumstances, configuring DMX32 and DRS is pretty straight forward. However, there may be scenarios where we want to manipulate these control bits while switching between the various MCG clock modes. In these situations we need to be careful not to select an FLL frequency multiplication option that pushes the FLL output beyond the allowable specification of the MCU.

For improved frequency accuracy, the FLL can use an external crystal or oscillator. A prescaler unit divides down this reference signal so that it can be used as F_REF FLL. The RANGE0 and FRDIV bits select the appropriate configuration for this prescaler, as shown in Table 4. The information in this table needs to be combined with the device electrical specifications to understand what kind of crystal or external oscillator can be used. Valid crystal values are in the range of 32 kHz to 40 kHz or between 3 MHz to 32 MHz, while the maximum frequency for an external clock is 50 MHz (hence, 60 MHz is greyed out in the table).

RANGE0	FRDIV	Divide-by	External Frequency Range
00	000	1	31.25 kHz to 39.0625 kHz
00	001	2	62.5 kHz to 78.125 kHz
00	010	4	125 kHz to 156.25 kHz
00	011	8	250 kHz to 312.5 kHz
00	100	16	500 kHz to 625 MHz
00	101	32	1 MHz to 1.25 MHz
00	110	64	2 MHz to 2.5 MHz
00	111	128	4 MHz to 5MHz
01 or 1x	000	32	1 MHz to 1.25 MHz
01 or 1x	001	64	2 MHz to 2.5 MHz
01 or 1x	010	128	4 MHz to 5MHz
01 or 1x	011	256	8 MHz to 10 MHz
01 or 1x	100	512	16 MHz to 20 MHz
01 or 1x	101	1024	32 MHz to 40 MHz
01 or 1x	110	1280	40 MHz to 50 MHz
01 or 1x	111	1536	48 MHz to 60MHz

Table 4. RANGE0 and FRDIV values and their corresponding valid external frequencies.

As I have indicated, when using high speed serial communications, we need a solid clock source that does not have a lot of jitter. It is easier to minimize the clock jitter of a frequency multiplication circuit by using a higher frequency input reference clock, F_REF. The input reference for the PLL is higher than that of the FLL. Through its clock divider, the PLL offers more frequency multiplication options, from ×24 to ×55.

For applications using Ethernet or USB, we need to make use of the PLL. This can be accomplished by either running everything from the PLL using the MCG PLL Engaged External (PEE) mode, or by having the PLL enabled while the system clock is derived from the FLL, as per Table 2.

Another Example

Let’s look at how to engage the PEE mode operation from power on reset. Figure 5 shows us that to get to PEE, we need to move through several other states. Specifically, the shortest path through these MCG states is: FEI to FBE to PBE to PEE. As an example, I show the code required to operate the MCG in PEE while generating a 100 MHz system clock (that is, MCGOUTCLK). This technique uses an external 50 MHz oscillator as the source. This same scheme is used on Freescale's TWR-K60D100M Tower System board.

Freescale's Processor Expert Software is an excellent tool that you can use to see how to properly move between MCG states. Let’s walk through this simple procedure a step at a time. The code to change from FEI to FBE is in Listing 3.

[sourcecode firstline="100"]
/* Switch to FBE Mode */
/* OSC_CR: ERCLKEN=1,??=0,EREFSTEN=0,??=0,SC2P=0,SC4P=0,SC8P=0,SC16P=0 */
OSC_CR = (uint8_t)0x80U;
/* MCG_C7: OSCSEL=0 */
MCG_C7 &= (uint8_t)~(uint8_t)0x01U;
/* MCG_C2: LOCRE0=0,??=0,RANGE0=2,HGO0=0,EREFS0=0,LP=0,IRCS=0 */
MCG_C2 = (uint8_t)0x20U;
/* MCG_C1: CLKS=2,FRDIV=6,IREFS=0,IRCLKEN=1,IREFSTEN=0 */
MCG_C1 = (uint8_t)0xBAU;
/* MCG_C4: DMX32=0,DRST_DRS=0 */
MCG_C4 &= (uint8_t)~(uint8_t)0xE0U;
/* MCG_C5: ??=0,PLLCLKEN0=0,PLLSTEN0=0,PRDIV0=0x0F */
MCG_C5 = (uint8_t)0x0FU;
/* MCG_C6: LOLIE0=0,PLLS=0,CME0=0,VDIV0=8 */
MCG_C6 = (uint8_t)0x08U;
/* Check that the source of the FLL reference clock is the external reference clock. */
while((MCG_S & MCG_S_IREFST_MASK) != 0x00U) {}
/* Wait until external reference clock is selected as MCG output */
while((MCG_S & 0x0CU) != 0x08U) {}
[/sourcecode]

Listing 3. Changing MCG Mode of Operation from FEI to FBE.

Line 102 - The write to OSC_CR (OSC Control Register) enables the external reference clock.

Line 104 - This clears the OSCSEL control bit in MCG_C7 (MCG Control 7 Register) and selects the external oscillator as the input frequency reference for the PLL.

Line 106 - Clearing the LP bit ensures that both the FLL and PLL remain enabled as the MCG transitions through bypass states. The RANGE0 bits in MCG_C2 control the analog biasing for the crystal oscillator and select whether or not the external reference frequency is divided by 32 prior to being fed into the FLL. As we are using an external 50 MHz oscillator (that is, not a crystal), engaging the divide-by-32 prescaler for the FLL is the more important effect of setting the RANGE0 bits. When using a crystal, the RANGE0 configuration depends upon the crystal frequency like so:

RANGE0 = 00 : crystal between 32 kHz and 40 kHz
RANGE0 = 01 : crystal between 3 MHz and 8 MHz
RANGE0 = 1x : crystal between 8 MHz and 32 MHz

Line 108 - The external reference for the FLL is further divided by setting up the FRDIV bits in MCG_C1. Table 3 shows us that by setting FRDIV to 110 and with RANGE0 set to 10, we end up dividing the external 50 MHz by 1280, which produces a 39.0625 kHz signal. Also within MCG_C1, setting CLKS to 10 selects the external 50 MHz clock as the source for MCGOUTCLK, thereby bypassing the FLL.

Line 110 - MCG_C4 provides the frequency selection for the FLL via the DMX32 and DRS control bits. The code clears these to zero, which is their power-on reset default, so nothing gets changed.

Line 112 - MCG_C5 controls the prescaler for the PLL with the five PRDIV0 bits. Recall that the frequency range for the PLL's input reference, F_REF PLL, is between 2 MHz and 4 MHz. The code configures PRDIV0 to 01111, which divides the 50 MHz reference by 16, and results in an F_REF PLL of 3.125 MHz. The clock signal presented at F_REF PLL must be within the specified frequency prior to enabling the PLL.

Line 114 - MCG_C6 provides some further PLL controls such as the loop clock divider with the VDIV0 bits. Setting VDIV0 to 01000 results in a multiplication factor of 32. It is important to configure these dividers while the PLL is disabled. Once it is enabled, the PLL output frequency can be calculated as: 50 MHz ÷ (PRDIV0 + 1) × (VDIV0 + 24) = 50 MHz ÷ 16 × 32 = 100 MHz.

Some control bits in the MCG do not update immediately due to internal synchronization delays. We need to wait for these controls to take effect, or we risk the possibility of running the MCG outside of its operating specifications. So what we see next in the code is two while loops that provide this delay.

Line 116 - The first while loop waits until the hardware verifies that the external clock has been enabled as the reference for the FLL (that is, the status of the multiplexer controlled by IREFS).

Line 118 - The second while loop waits for confirmation that the external clock is directly driving the MCGOUTCLK signal (that is, the status of the multiplexer controlled by CLKS).

At this point the MCG is operating in FBE mode with the external 50 MHz oscillator directly driving the MCGOUTCLK signal. Next we need to change to PBE mode. The code that Freescale's Processor Expert Software generates is shown in Listing 4.

[sourcecode firstline="119"]
/* Switch to PBE Mode */
/* OSC_CR: ERCLKEN=1,??=0,EREFSTEN=0,??=0,SC2P=0,SC4P=0,SC8P=0,SC16P=0 */
OSC_CR = (uint8_t)0x80U;
/* MCG_C7: OSCSEL=0 */
MCG_C7 &= (uint8_t)~(uint8_t)0x01U;
/* MCG_C1: CLKS=2,FRDIV=6,IREFS=0,IRCLKEN=1,IREFSTEN=0 */
MCG_C1 = (uint8_t)0xBAU;
/* MCG_C2: LOCRE0=0,??=0,RANGE0=2,HGO0=0,EREFS0=0,LP=0,IRCS=0 */
MCG_C2 = (uint8_t)0x20U;
/* MCG_C5: ??=0,PLLCLKEN0=0,PLLSTEN0=0,PRDIV0=0x0F */
MCG_C5 = (uint8_t)0x0FU;
/* MCG_C6: LOLIE0=0,PLLS=1,CME0=0,VDIV0=8 */
MCG_C6 = (uint8_t)0x48U;
/* Wait until external reference clock is selected as MCG output */
while((MCG_S & 0x0CU) != 0x08U) {}
/* Wait until locked */
while((MCG_S & MCG_S_LOCK0_MASK) == 0x00U) {}
[/sourcecode]

Listing 4: Changing MCG mode of operation from FBE to PBE.

As much as I like Freescale's Processor Expert Software, I also like to point out places where it could be improved. I am a bare metal guy who is used to counting every bit, byte and clock cycle on 8-bit MCU code. I know that memory has become more affordable and 32-bit machines can tolerate a certain amount of bit-level inefficiency. But it still irks me when I see code that I consider to be simply unnecessary.

When we compare Listing 3 and Listing 4, we find that several registers are being written twice with the same information. The writes to OSC_CR, MCG_C7, MCG_C1, MCG_C2, and MCG_C5 in Listing 4 are redundant.

Line 131 - Changing the PLLS control bit in MCG_C6 is the only modification needed when moving from FBE to PBE.

The first while loop in Listing 4 is also unnecessary. It is identical to the second loop shown in Listing 3. So there should be no need to perform the same check again since the CLKS bits have not been modified. More on this in a bit.

Line 135 - The second while loop in Listing 4 is waiting for the PLL to lock. When PLLS was set it enabled the PLL and disabled the FLL, as previously described in Table 2. Before the PLL can be used we should wait for it to lock in order to be certain that it is operating within the specifications.

With the MCG operating in PBE mode we are ready to move into PEE mode. Listing 5 shows how this is accomplished with Freescale's Processor Expert Software.

[sourcecode firstline="136"]
/* Switch to PEE Mode */
/* OSC_CR: ERCLKEN=1,??=0,EREFSTEN=0,??=0,SC2P=0,SC4P=0,SC8P=0,SC16P=0 */
OSC_CR = (uint8_t)0x80U;
/* MCG_C7: OSCSEL=0 */
MCG_C7 &= (uint8_t)~(uint8_t)0x01U;
/* MCG_C1: CLKS=0,FRDIV=6,IREFS=0,IRCLKEN=1,IREFSTEN=0 */
MCG_C1 = (uint8_t)0x3AU;
/* MCG_C2: LOCRE0=0,??=0,RANGE0=2,HGO0=0,EREFS0=0,LP=0,IRCS=0 */
MCG_C2 = (uint8_t)0x20U;
/* MCG_C5: ??=0,PLLCLKEN0=0,PLLSTEN0=1,PRDIV0=0x0F */
MCG_C5 = (uint8_t)0x2FU;
/* MCG_C6: LOLIE0=0,PLLS=1,CME0=0,VDIV0=8 */
MCG_C6 = (uint8_t)0x48U;
/* Wait until output of the PLL is selected */
while((MCG_S & 0x0CU) != 0x0CU) {}
[/sourcecode]

Listing 5: Changing MCG mode of operation from PBE to PEE.

Once again, the knowledge base within the Processor Expert Software has generated redundant code, specifically with the same writes to OSC_CR, MCG_C7, MCG_C2, MCG_C5, and MCG_C6.

Line 142 - The only change actually required is the modification of the CLKS bits in MCG_C1 so that the output of the PLL now drives MCGCLKOUT.

Line 150 - The last while loop verifies that the CLKS bits did change before proceeding.

The redundant code in Listings 4 and 5 is not wrong. Processor Expert software is working to a narrow scope and simply makes no assumptions about previous MCG register settings, and therefore creates more code than is necessary. This is not a big deal: Wasting a few bytes of flash memory and a few cycles of processor time probably doesn’t matter. However, it does bug me and my 8-bit minimalistic sensibility.

I would go in and fix it, but the code generated should not be modified manually, as the Processor Expert tools will regenerate it upon every recompile. You can modify settings to disconnect the code so that it will no longer be generated – in effect use Processor Expert software to get you started, and then take over. But that’s another article.

I like using Freescale's Processor Expert Software because it saves a lot of time when we need to get an MCU up and running in a hurry. I remember using complete data books for 8-bit MCUs that were around 100 pages long. Today, the reference manuals for some of the simplest 32-bit devices exceed 1000 pages and those that document their more complex relatives are twice that size or more. That's a lot of information to learn within the ever-shortening project design timeframes.

For me, block diagrams are the best way to quickly understand how a module works. As MCU clocking options have grown in complexity, tools like Freescale's Processor Expert Software have become more important. Looking at the code it generates and comparing it to the corresponding information in the MCU's reference manual helps you understand the bare metal workings of the device. This is often much easier than the other way around - that is, the traditional way of writing code based solely upon the information provided in the device reference manual, bit-banging the registers, and hoping that the proper frequency comes out.

When it comes to software development, efficiency can be measured in terms of the size of the code and/or the time it takes to create it. I have to admit that lately I have been running out of time more often than bytes.

Eclipse working sets revealed

admin@community.freescale.com — Wed, 15 Aug 2012 01:27:40 GMT

By Erich Styger -- The CodeWarrior IDE is based on the Eclipse framework, and is project based. The CodeWarrior Projects view shows you your projects, and their contents. However, over time more projects pile up in my workspace, and more resources accompany these projects. You reach a point where, despite the IDE's many views, the number of elements displayed becomes overwhelming. When I have a lot of projects, I do not want to switch between workspaces too often. Yes, I can open and close projects, but this gets cumbersome too. Thankfully, the Eclipse IDE provides a solution: Working Sets.

A Working Set is a group of projects I want to work on at the same time. They are, at least in my mind, related to each other, so I put them together in a collection. Note that working sets are not the same as CodeWarrior subprojects: My article, CodeWarrior Tool Tip #5: The return of the subproject, explains what subprojects are. The projects in a working set are related in a looser way.

Since I often use many projects at the same time, working sets allows me to focus on the right set of elements at the right time. Better still, I can operate on the projects that belong to the working set. I can define a set of things I want to look at, and then work with them. Working sets allow me to be more productive in my environment.

Building a Working Set

One valuable feature of working sets is that I can quickly and accurately build a set of projects. Otherwise I must manually select a set of projects and then compile them all at once, or do them one at a time sequentially. A working set acts as a container that holds the projects I need to operate on. When I request a build on the working set, the IDE builds all of the projects held within it.

Making a working set is simple. I use Project > Build Working Set > Select Working Set to create or change working sets (Figure 1):

Figure 1. Menu choice to choose a working set.

If I do not have a working set defined, then the following dialog appears, which allows me to click New and create a new one (Figure 2):

Figure 2. Creating a Working Set.

Now I need to tell the IDE how to handle the projects contained in the working set. That is, I specify the working set's type. So, to create a working set of related C/C++ projects, I choose C/C++ and click Next (Figure 3):

Figure 3. Specifying the type of projects in a working set.

Next I enter a name for my working set, select the project(s) held in it, and click Finish (Figure 4). The projects listed are those available in the Explorer view.

Figure 4. Defining the projects that belong to the working set.

To build my set of projects, I first select the working set I want to use—for this example, Test set—and click OK (Figure 5):

Figure 5 Choosing the work set for the IDE to operate on

When I click OK the IDE dutifully compiles and links all of the projects associated with Test set.

The example in this article is simple. Wait until you are dealing with lots of projects that have lots of files. Freescale’s MQX RTOS, for example, has a working set that encompasses its kernel, shell, board support package, and various software stacks, such as a file system and assorted USB classes. The RTOS source consists of seven projects, each which can have hundreds of files. To modify MQX for your embedded system, you edit some values in a user_config.h file and then have the Eclipse IDE build the MQX working set. Working sets make such changes not only manageable, but easy.

Search in a Working Set

It is possible to limit the IDE's search mechanism to that of a working set. For this I can choose a working set as scope in the search dialogs (Figure 6):

Figure 6. Setting scope of search to a working set.

Managing Working Sets

To manage working sets, I first press CTRL+3 to display the IDE's Quick Access dialog (Figure 7), then type working set:

Figure 7. Choosing Manage Working Sets from Quick Access.

From this dialog, a keystroke or two takes me to the Manage Working Set Configurations dialog (Figure 8):

Figure 8. Selecting launch configurations for projects in the working set.

Here I can see how each project in the working set is built. I can create new and different configurations: ways of building this working set, and make any one of them the active configuration.

Project View Filtering with Working Sets

I can filter the projects displayed in the CodeWarrior Project view through the use of working sets. For this I click on the View Menu item (the small triangle in the corner of the view) and either select/define a working set, or choose an existing one from the most recently used sets, as Figure 9 shows.

Figure 9. Selecting the working sets to display.

This feature lets me easily focus on a subset of projects that I am working with, as shown in Figure 10.

Figure 10. Project view displaying only the chosen working set.

TIP: I often use working sets to reduce the number of workspaces that I use. Instead of having projects scattered over different workspaces, I can keep them in one workspace and use working sets to present only those projects that I am interested in. Besides keeping the information at manageable level, there is an added benefit of using working sets: having fewer projects open at the same time in Eclipse enables the IDE to operate faster. With working sets, I can switch quickly between the collections of projects that I am working on.

However, the value of working sets does not stop at filtering projects. You can even filter objects inside the project as well. I simply deselect things I do not want to see, which lets me focus on what is important. For example, Figure 11 shows where the CodeWarrior Project view only displays a project’s Source, Header and generated output (MCF51JM128_Internal_Flash) folders.

Figure 11. Filtering project files.

Export and Import of Working Sets

So far what we have been discussing is essentially standard Eclipse functionality as it applies in the CodeWarrior IDE – such as our extensions of the Project explorer to adapt to the CodeWarrior project file. The export and import of working sets is not standard, but some people have implemented this capability, including Freescale.

You can get this feature when you install either MQX RTOS with its MQX plugins, or with the AnyEdit plugins .

After installing the MQX plugin, to export a working set, I choose File > Export > Other > Export Working Set (Figure 12):

Figure 12. The MQX plugin being used to export a working set.

This gives the following dialog (Figure 13) where I can specify the file name and the root of projects:

Figure 13. Export working set dialog.

This saves the working set information into an XML file. You import the working set by selecting File > Import > Other > Import Working Set, and then opening the XML file. The MQX plugins also allow the drag and drop of the exported working set file into CodeWarrior Project view, where the Eclipse IDE then restores the working set information.

The AnyEdit plugins provide a wizard to handle the import and export of working sets. Finally, the format of the AnyEdit stored working set information differs from that made by the MQX plugin implementation, so you cannot mix the two.

Tip: I use the extension *.wsd for designating the file that stores working set information. That way I can simply drag and drop the file into Eclipse IDE to import it.

Other Kinds of Working Sets

As Figure 14 shows, the use of working set information does not stop at projects and files.

Figure 14. Selecting a working set type.

I can create working sets of breakpoints or analysis/trace points. I can create working sets of any resource files or tasks. The possibilities are nearly endless and can also depend on the plugins installed.

Window Working Sets

OK, so you have the idea that a working set can control many elements in the Eclipse IDE: collections of projects, visibility of files in the project, what gets built, breakpoints, resources, and so on. Many different views and dialogs have a workspace setting. The problem is that each view is independent and can have a different working set. Keeping them consistent can be a challenge. For example, in Figure 15, on the left I use a working set ‘ColdFire’ for the CodeWarrior Projects view, but my Search dialog on the right has a ‘Kinetis’ working set configured.

Figure 15. Two different working sets in use.

Sometimes I want this arrangement, but not always. What I need is a ‘global’ working set. And here is where the Window Working Sets comes to the rescue.

When you made your first working set, you might have noticed the option for Window Working Sets (Figure 16). What are they, and what can they be used for?

Figure 16. Choosing to use the Window Working Set.

You can say that an individual view will use the Window Working Set. But what is the Window Working Set?

I can add menu and icon items to set and switch the Window Working Set right at the top level of the UI. First, I choose Window > Customize Perspective (Figure 17). Next, I select the Command Groups tab, and enable the option Window Working Set. It is a good idea to enable the option Working Set Manipulation as well. When you select each one, the other columns tell you what menu items appear in which menu, and what icon will appear in the tool bar.

Figure 17. Choosing Window Working Set commands.

To control visibility, you can go to the Tool Bar Visibility and Menu Visibility tabs. Since you just turned on the command group, the icon and menu items should be on by default. The result is an icon on the toolbar that lets me quickly set the Window Working Set, or to Edit the working set (Figure 18):

Figure 18. Configuring working set from the toolbar.

I can do the same from the Window menu as well (Figure 19):

Figure 19. Menu access to working sets.

In an individual view (Figure 20), I can say I want to use the Window Working Sets instead of selecting a particular working set:

Figure 20. Selecting the global Window Working Set.

Now my working set settings can be shared and common for all views. If I switch the Window Working Set, the IDE changes the display for all views where I have set the view to use the Window Working Set (Figure 21):

Figure 21. Window Working Set applied to multiple views.

This ensures that my working set configuration is the same across views, and I can switch between different settings with just a mouse click.

Summary

Working sets are an extremely powerful feature that allows you to focus on a subset of elements inside the Eclipse environment. As with many great Eclipse features, you do not really appreciate their power until you become aware them and are shown how to use them. Who knows how many other hidden treasures are buried in the Eclipse framework?

I hope this article can save you a few mouse clicks, plus make organizing and managing your embedded system code much easier.

Happy Work-Setting!

Boundary-scan testing quickly done

admin@community.freescale.com — Tue, 07 Aug 2012 05:31:45 GMT

By Tom Thompson -- In a previous blog article, I described how you can perform automated hardware tests on an embedded systems board that's based on a QorIQ processor. You can do this easily in a matter of minutes with just a Freescale TAP run controller and a test application. The test application, Runner-Lite, was written by Corelis Inc., and makes use of the boundary-scan capability built into the JTAG interface of the Freescale TAP probe and the microprocessor unit (MPU) to conduct these tests and present the results graphically.

This sounds all well and good, but how difficult is it to actually perform these tests? Or, put another way, can we have a reality check here? I decided to find out. Working at Freescale, you can get your hands on some neat stuff. So it was that I was able to come into possession of a P1024RDB board. Next I went through my assorted cables and emulator pods to locate a Freescale USB TAP. The label on its housing declared that the probe is a revision A design, which makes it about five years old. Besides the board and the emulator pod, the only other gear required is a workstation that can execute the Runner-Lite application. The complete set up for performing a boundary-scan appears in Figure 1.

Figure 1. The cast of characters for conducting boundary-scan tests.

It took a few minutes to remove the protective housing surrounding the P1024RDB board, and a minute to locate the J22 connector that the JTAG/COP cable from the TAP run controller plugs into. Wait, I spent another three minutes double-checking that I had the cable oriented in the connector correctly. I didn't want any pyrotechnics from plugging the cable in the wrong way.

Now for the software. I had the CodeWarrior Development Studio v10 for Power Architecture tools already installed, which meant that the CodeWarrior Command Server (CCS), the software driver that communicates with the TAP, was in place. Next, I went to the Corelis web site and downloaded the Runner-Lite application. I then registered and was able to download the P1024RDB test plan file. Note that the Runner-Lite application requires the information stored in the test plan file in order to run the tests. If you want Runner-Lite files to test a different board, all you do is load a different test plan file.

Installing the Runner-Lite application took a few more minutes, and I had it read in the P1024RDB test plan file. I applied power to the board. No sparks flew or smoke gushed...good. Then I made a few menu selections, and had the Runner-Lite application test the board. The entire test suite—excluding external loop back tests—ran in just over a minute. Ignoring software installation times, I had boundary-scan tests going in about ten minutes.

If your board has hardware problems, the Runner-Lite application flags them and points them out to you. If the board passes muster, you can quit the Runner-Lite application and launch the CodeWarrior tools to begin downloading and testing code using the same set up. In summary, you can use the same gear to conduct boundary scan tests on prototype hardware, then perform board bring up on the prototype. Then you can conduct more boundary scans, and finally develop the applications that execute on the board. Also note that I was using a (relatively) old emulator pod and Windows XP, so you don't need the latest and greatest equipment to do hardware tests and develop software for your embedded system prototype. To see how easy it is to get started, the equipment set up is summarized in this video, and it also presents a test run with the Runner-Lite application.

This is truly a sweet arrangement. As it turns out, testing boundaries doesn’t always involve pushing technical boundaries.

Accelerometer placement - where and why

admin@community.freescale.com — Thu, 02 Aug 2012 03:28:48 GMT

By Michael Stanley – A question that should be asked during physical design of any product incorporating sensors is: "Where should be sensors be located within the product?" Like almost anything else in life, "It depends ... " is the answer. This post discusses accelerometer placement. We'll touch on magnetic sensors next time around.

If your application is such that the sensor is statically fixed in space, or at least not rotating, it doesn't really matter where you mount the accelerometer on your board. But if the device can rotate, things get a lot more interesting.

The rate of change transport theorem, which can be found in any rigid body dynamics textbook, relates the rate of change of a vector r as observed in two different reference frames. For our purposes, the first is the fixed (earth) frame and the second (body frame) rotates and translates relative to the first. In equation form:

(dr/dt)_f =(dr/dt)_r + ω X r_r (Eqn. 1)

where the subscripts indicate the frame of reference.

The transport theorem is a fundamental relationship, based upon basic principles of geometry. It applies to ANY vector observable from two independent reference frames. You should note that both left and right sides of the equation are vectors.

We are going to repeatedly apply the transport theorem to derive a relationship defining the acceleration of an object in the fixed earth frame based upon sensor measurements made in the body frame.

In graphical form, consider movable point "P", observable from two different frames of reference. "O_f" is the origin of the fixed earth reference frame. "O_r" is the origin of the rotating reference frame.

Frames of Reference

By basic geometry

r' = R + r (Eqn. 2)

Note that

V = (dr/dt)_f

V is the rate of change of vector r as viewed in the fixed reference frame. It can also be viewed as the velocity of P as viewed in the fixed earth frame

V_r = (dr/dt)_r

V_r is the he rate of change of vector r as viewed in the rotating reference frame. It can also be viewed as the velocity of P as viewed within the rotating reference frame.

ω = the angular velocity of the rotating frame relative to the fixed earth frame

by differentiating Eqn. 2, we get

(dr'/dt)_f = (dR/dt)_f + (dr/dt)_f (Eqn. 3)

which we can also write as

V_r' = V + (dr/dt)_f (Eqn. 4)

The quantity V can be interpreted as the translational velocity of the rotating frame relative to the fixed frame of reference. V_r' is the velocity of point P as observed in the fixed earth frame. Typically, this is the quantity we are trying to measure.

We can apply the transport theorem to the right most term in Eqn. 4 to get

V_r' = V + (dr/dt)_r + ω X r (Eqn. 5)

V_r' = V + V_r + ω X r (Eqn. 6)

Now differentiate and take advantage of the math identity:

d/dt (A X B) = (dA/dt X B) + (A X dB/dt) (Eqn. 7)

to get

A_r’ = (dV_r'/dt)_f = (dV/dt)_f + (dV_r/dt)_f + (dω/dt)_f X r + ω X (dr/dt)_f (Eqn. 8)

Let

A = (dV/dt)_f

where A is the acceleration of the second frame of reference relative to the fixed earth frame.

At the same time, apply the transport theorem again to substitute

(dV_r/dt)_f =(dV_r/dt)_r+ ω X V_r (Eqn. 9)

to get

A_r’ = A+ (dV_r/dt)_r+ ω X V_r+ (dω/dt)_f X r + ω X (dr/dt)_f (Eqn. 10)

Let

α = (dω/dt)_f

where α is the rate of angular acceleration, and

A_r = (dV_r/dt)_r

where A_r is the rate of acceleration of P relative to O_r. Then

A_r’ = A+ A_r+ ω X V_r+ α X r + ω X (dr/dt)_f (Eqn. 11)

and one last substitution using the transport theorem for the right most term in Eqn. 11 to get

A_r’ = A+ A_r+ ω X V_r+ α X r + ω X ((dr/dt)_r + ω X r) (Eqn. 12)

A_r’ = A+ A_r+ ω X V_r+ α X r + ω X (V_r + ω X r) (Eqn. 13)

A_r’ = A+ A_r+ ω X V_r+ α X r + ω X V_r + ω X (ω X r)) (Eqn. 14)

A_r' =	A + A_r +	<-- Inertial Acceleration
	2ω X V_r +	<-- Coriolis Acceleration
	α X r +	<-- Euler Acceleration
	ω X (ω X r))	<-- Centripetal Acceleration	(Eqn. 15)

Eqn. 15 is a classic result, and can give you a lot of insight into tradeoffs associated with accelerometer placement. To see how, let's modify our previous figure by locating O_r at the center of mass of a portable consumer device. Point P represents the location of our accelerometer within the same device. Point O_f is essentially the center of the earth.

Frames of Reference related to Portable Consumer Device

Since points P and O_r are fixed relative to one another (they are part of the same rigid body), A_r and V_r are zero by definition, and drop out of the equation. If the rotational rate of the device is zero, then ω=0, and both Coriolis and Centripetal acceleration terms drop out of the equation. Finally, if α (the rotational acceleration) is zero, there will be no Euler acceleration. If all these terms hold true, then the value measured by our accelerometer is

A_r’ = A = the translational rate between the two frames of reference

which is exactly what we would like. But what if ω≠0? If we collapse point P back into the center of mass (O_r), then both Euler and Centripetal accelerations still drop out.

What happens if you ignore these effects? Let's work an example assuming that angular acceleration is zero, but angular rotation is not:

A_r' =	A + A_r +	<-- Inertial Acceleration
	ω X (ω X r))	<-- Centripetal Acceleration	(Eqn. 16)

To bound the problem, I'm going to take advantage of the identity:

A X B = |A| |B| sin Θ n

where Θ is the angle between vectors A and B, and n is a unit vector perpendicular to the plane containing both A and B.

Looking at just the extremes, we can see that the Centripetal acceleration ranges between +/- |ω|²r in magnitude, depending upon the axis of rotation and accelerometer offset from center of mass.

Assume

ω = 2π radians/sec
r = 5 cm

Putting numbers to Eqn. 16, we get

Centripetal Acceleration = +/- 0.05 (2π)² =+/- 1.97 m/s².

That's better than 1/5 gravities! At a very modest rate of rotation!

Basically, sensor fusion mathematics get much easier when the accelerometer is at the center of mass (which is also the center of the rotating frame of reference). If you can make the assumption that, in your use case, the device is in a quasi-static state with no rotation, it doesn't matter. If not, you need to place the sensor at the center of mass OR account for the effects mathematically. That involves keeping continuous track of the axis and rate of rotation and then making the adjustments required to separate out the Centripetal acceleration.

References:

Dynamics of Particles and Rigid Bodies: A Systematic Approach, Anil V. Rao, Cambridge University Press, 2006
Motion in a Non-Inertial Frame, Alain J. Brizard, Saint Michael's College, http://www.dartmouth.edu/~phys44/lectures/Chap_6.pdf

The Freedom Board

admin@community.freescale.com — Sat, 28 Jul 2012 03:06:37 GMT

By Erich Styger

There are some advantages to working for a high tech company like Freescale. One of them is early access to cool toys. Yesterday was my ‘lucky day’: my Freescale Kinetis L series Freedom board arrived. This board is really nice and features the KL25Z from the recently announced Kinetis L series microcontrollers. The microcontroller on this board is an ARM Cortex M0+ processor, which we demonstrated at the Freescale Technology Forum. You can see a really neat video here that shows off the energy efficiency and how the Kinetis L series outperforms the competition in the video. It’s not an accident. If you’d like to know why, there’s a system engineering deep dive here.

Before we get started, there are two other really important things you will want to know when this article is done, so I’ll answer the questions right up front: where do I get one, and how much does it cost?

The board will be available at Element 14/Farnell. It is expected to be publicly available by the end of September 2012, and you can pre-order now. The United States Element 14 site will have the board available for a suggested resale price of $12.95 (USD). In Europe it will be about 10 Euro. You read those prices correctly.

All right. Without further delay, let’s start talking about this board, and about getting some software to run on it.

What is the first thing I want to flash on this processor? Yep: some FreeRTOS tasks. I want an operating system. We will have a reduced version of MQX as well, called MQX Lite. Look for information on that in the coming days. I have worked extensively with FreeRTOS, and I want that on this new board as well. To get there, a few important things have to be sorted out:

Get the board up and running
Get Eclipse-based build tools for the ARM Cortex-M0+ processor
Extend the Processor Expert FreeRTOS component to work with GCC and the Cortex-M0+ processor
Test, Debug and Celebrate

The Freedom Board

The board, shown in Figure 1, has a nice and small form factor of 81 mm x 54 mm, which makes it ideal for a lot of applications.

Figure 1. The Freedom Board.

You can see it has headers along either side. Those allow me to plug in other boards. The board is intended to be compatible with Arduino shields. What shields are in fact compatible is not clear yet, but the connector is able to provide 5V, while using 3.3V signals.

Figure 2 is the block diagram for the board. There is a touch sensor along one side. Note also the presence of the Freescale K20 microcontroller wired directly to one of the USB ports. It is the center of the debug interface.

Figure 2. Freedom Board Block Diagram.

There are two mini USB connectors on the board: one is the target USB connector (the KL25Z implements USB), the other is the on-board debug connector. Yes, like the Tower board, the Freedom board has on-board debug solution on it. Connecting the board using the debug connector automatically installs the drivers.

The debug connection features a bootloader similar to the Processor Expert USB Bootloader component. Using this, it is possible to program new firmware/software by simply dragging a file. This is really nice, and I am looking forward to exploring this more in the future. In principle, you can use this to—very easily—reprogram the internal workings of the Kinetis K20 to make the debug interface look like almost anything you want.

GCC and an Eclipse IDE

So, I have this inexpensive and highly capable hardware. This is a new chip architecture. What tool chain can I use for Cortex-M0+ processor? The good news is that there is a GCC tool chain maintained by ARM available both for Cortex-M0+ and Cortex-M4 processors. Additionally, there are ARM GCC Eclipse panels available too. With this, it is not too hard to have a working Eclipse environment. Freescale has implemented this inside the CodeWarrior IDE, and you’ll see it in CodeWarrior for MCU 10.3. The final version of CodeWarrior may differ slightly from the screenshot you see in Figure 3, but for sure you will see the ARM GCC compiler for the Cortex-M0+ processor.

Figure 3. ARM GCC Panels.

FreeRTOS Processor Expert Component

My next task was to extend my Processor Expert component to work with GCC. This mainly means it must work with the GCC assembly syntax. To do this I must extend port.cof the FreeRTOS distribution.

I already had a FreeRTOS port for CodeWarrior and Kinetis K-Family. I modified that code to work with both a Cortex-M4 and a Cortex-M0+ processor. Below is an extract of the code that deals with both MCU types.

[sourcecode language="cpp"]
__attribute__ ((naked)) void vPortSVCHandler(void) {
#if FREERTOS_CPU_CORTEX_M==4 /* Cortex M4 */
__asm volatile (
" ldr r3, pxCurrentTCBConst2 \n" /* Restore the context. */
" ldr r1, [r3]               \n" /* Use pxCurrentTCBConst to get the pxCurrentTCB address. */
" ldr r0, [r1]               \n" /* The first item in pxCurrentTCB is the task top of stack. */
/* pop the core registers */
" ldmia r0!, {r4-r11}        \n"
" msr psp, r0                \n"
" mov r0, #0                 \n"
" msr basepri, r0            \n"
" orr r14, r14, #13          \n"
" bx r14                     \n"
"                            \n"
" .align 2                   \n"
"pxCurrentTCBConst2: .word pxCurrentTCB \n"
);
#else /* Cortex M0+ */
__asm volatile (
" ldr r3, pxCurrentTCBConst2 \n" /* Restore the context. */
" ldr r1, [r3]               \n" /* Use pxCurrentTCBConst to get the pxCurrentTCB address. */
" ldr r0, [r1]               \n" /* The first item in pxCurrentTCB is the task top of stack. */
" add r0, r0, #16            \n" /* Move to the high registers. */
" ldmia r0!, {r4-r7}         \n" /* Pop the high registers. */
" mov r8, r4                 \n"
" mov r9, r5                 \n"
" mov r10, r6                \n"
" mov r11, r7                \n"
"                            \n"
" msr psp, r0                \n" /* Remember the new top of stack for the task. */
"                            \n"
" sub r0, r0, #32            \n" /* Go back for the low registers that are not automatically restored. */
" ldmia r0!, {r4-r7}         \n" /* Pop low registers. */
" mov r1, r14                \n" /* OR R14 with 0x0d. */
" movs r0, #0x0d             \n"
" orr r1, r0                 \n"
" bx r1                      \n"
"                            \n"
".align 2                    \n"
"pxCurrentTCBConst2: .word pxCurrentTCB \n"
);
#endif
}
[/sourcecode]

My First Freedom Application

After a few iterations, my FreeRTOS Processor Expert component worked with all the previous cores and compilers, plus with GCC for Cortex-M4 and Cortex-M0+ processors.

The Freedom board has an RGB LED, so my first application was to run three tasks, each toggling one color of the LED. For this I added three Processor Expert LED components to my project, as shown in Figure 4.

Figure 4. Freedom Board Processor Expert Components.

Here is the complete source code of the demo application where APP_Run() is called from main():

[sourcecode language="cpp"]/*
/* Application.c
* Author: Erich Styger
*/
#include "Application.h"
#include "LED1.h"
#include "LED2.h"
#include "LED3.h"
#include "FRTOS1.h"
#include "WAIT1.h"

static portTASK_FUNCTION(Task1, pvParameters) {
(void)pvParameters; /* parameter not used */
for(;;) {
LED1_Neg();
FRTOS1_vTaskDelay(1000/portTICK_RATE_MS);
}
}

static portTASK_FUNCTION(Task2, pvParameters) {
(void)pvParameters; /* parameter not used */
for(;;) {
LED2_Neg();
FRTOS1_vTaskDelay(1050/portTICK_RATE_MS);
}
}

static portTASK_FUNCTION(Task3, pvParameters) {
(void)pvParameters; /* parameter not used */
for(;;) {
LED3_Neg();
FRTOS1_vTaskDelay(2080/portTICK_RATE_MS);
}
}

void APP_Run(void) {
uint16_t i;
for(i=0;i<4;i++) {
LED1_Neg();
LED2_Neg();
LED3_Neg();
WAIT1_Waitms(250);
}

if (FRTOS1_xTaskCreate(
Task1, /* pointer to the task */
(signed portCHAR *)"Task1", /* task name for kernel awareness debugging */
configMINIMAL_STACK_SIZE, /* task stack size */
(void*)NULL, /* optional task startup argument */
tskIDLE_PRIORITY, /* initial priority */
(xTaskHandle*)NULL /* optional task handle to create */
) != pdPASS)
{
/*lint -e527 */
for(;;){}; /* error! probably out of memory */
/*lint +e527 */
}
if (FRTOS1_xTaskCreate(
Task2, /* pointer to the task */
(signed portCHAR *)"Task2", /* task name for kernel awareness debugging */
configMINIMAL_STACK_SIZE, /* task stack size */
(void*)NULL, /* optional task startup argument */
tskIDLE_PRIORITY, /* initial priority */
(xTaskHandle*)NULL /* optional task handle to create */
) != pdPASS)
{
/*lint -e527 */
for(;;){}; /* error! probably out of memory */
/*lint +e527 */
}
if (FRTOS1_xTaskCreate(
Task3, /* pointer to the task */
(signed portCHAR *)"Task3", /* task name for kernel awareness debugging */
configMINIMAL_STACK_SIZE, /* task stack size */
(void*)NULL, /* optional task startup argument */
tskIDLE_PRIORITY, /* initial priority */
(xTaskHandle*)NULL /* optional task handle to create */
) != pdPASS)
{
/*lint -e527 */
for(;;){}; /* error! probably out of memory */
/*lint +e527 */
}
FRTOS1_vTaskStartScheduler();
}
[/sourcecode]

This creates a nice colorful changing ambient light, and that light is bright! Not bad for a day’s work (Figure 5).

Figure 5. Freedom RGB LED controlled by three FreeRTOS tasks.

The updated Processor Expert component for FreeRTOS with added GCC and Cortex-M0+ support is available here. You can’t get the Freedom board yet, because you can’t get the Kinetis L series processors yet. The Processor Expert component is available now.

So, the Freedom board is a package that:

Provides access to the Cortex-M0+ core with industry-leading energy efficiency
Costs not much more than the change you carry in your pocket
Has a programmable debug connection
Is supported by GCC-based build tools
Has Processor Expert component support for two RTOS’s (FreeRTOS and MQX Lite)
Has Arduino shield compatibility
Has an RGB LED that will ruin your night vision

Stay tuned for more on the Kinetis L series, the Freedom board, CodeWarrior 10.3, assorted other tools for the Kinetis L series, Processor Expert Software, and MQX Lite. There is a lot coming!

Happy Freedom!

CodeWarrior Tool Tip #9: Stop on startup

admin@community.freescale.com — Mon, 16 Jul 2012 21:33:44 GMT

By Erich Styger -- Occasionally I run into a particularly unpleasant problem: from the CodeWarrior IDE, I have downloaded my application onto my target board for debugging, and the debugger immediately loses the connection (Figure 1).

Figure 1. What happened here?

What is the problem? To answer that, it is helpful to understand what occurs when the CodeWarrior IDE (or any other debugger tool) starts a debugger session.

What Happens on Debug

Clicking on the Debug button in the CodeWarrior IDE sets into motion a sequence of events that configures the probe connection to the target board, downloads the program into the firmware (either on-chip or on the board) and readies the debug session. More specifically:

The CodeWarrior IDE flashes the application onto the target board. (For this to occur successfully, either the debugger or the probe – for example, the P&E Multilink probe – downloads a small applet into the target RAM that performs the actual flash programming. The flash programming applet starts. The debugger then feeds data – the program code – to the applet until all of it is transferred into flash.)
The debugger initializes the processor's PC (Program Counter) and SP (Stack Pointer).
If configured to do so, the debugger sets a temporary breakpoint. More on this in a moment.
The debugger issues a “run” command. That is, the debugger tells the processor to begin execution, starting from the address that was stored in the PC.

What exactly happens in step two (setting the initial PC address) depends a bit on the microcontroller architecture. Furthermore, it seems every debugger handles the initialization a bit differently, too. Despite the differences, the usual outcome is that the PC and the SP are set up. These values are usually stored somewhere in the vector table (for example, for S08 and ColdFire microcontrollers). These values are also fetched by the processor when it is reset. Often what the debugger does is simply assert a reset to reload these values.

The Temporary Breakpoint

The interesting part is step three, where the debugger sets a temporary breakpoint. A temporary breakpoint only happens once, and is then removed. Usually this breakpoint is set at main(). This way when you start a debug session, the debugger lets all of the startup code execute and the program halts at main(). This arrangement spares you from stepping through numerous lines of startup code that configure the processor registers and initialize the peripherals. This makes sense because what you really want to do is dive right into the application code.

This plan works fine, unless the train of execution jumps the track somewhere between the reset address and main(), and you get the Problem Occurred dialog in Figure 1. Typical things that could go wrong are:

The startup code takes too long to execute. This results in a watchdog timer expiring. The watchdog dutifully resets the target before your code in main() gets a chance to 'feed the dog' (reset the timer). A typical culprit here is where the startup code has to initialize, or zero, large amounts of memory.
The application entry point or initial stack pointer is incorrect, causing a bus access error.
The run control/debug connection gets severed when the target crashes.
Any other weird problem you could imagine and probably quite a few that you can't.

Stop on Startup

To solve this problem, you need to look at the startup code. That is, you want to tell the debugger to stop earlier than in main(), so that you can examine the operation of the startup code. Fortunately, there is a setting for this in the debug/run launch configuration window (Figure 2):

Figure 2. The “Stop on startup at” setting in the Debugger options.

If the Stop on startup at setting is checked, the debugger sets a temporary breakpoint as determined by the next two options. Otherwise, the target runs. The choices are:

Program entry point: If selected, the debugger places a breakpoint at the beginning of the program code (which includes the startup code).
User specified: If selected, here you can specify the name of any function. The debugger then places a breakpoint at the start of the specified function. As the figure shows, the default function name is main().

Program Entry Point

One question remains: where is this program entry point? You would like to have some idea where the debugger will take control, if only to reassure you that the problem is not in the probe.

The HCS08 linker reports it in the linker map file, like so:

**********************************************************************
STARTUP SECTION
----------------------------------------------------------------------
Entry point: 0xC004 (_EntryPoint)
_startupData is allocated at 0xC09C and uses 6 Bytes

The S08 linker has the ENTRY command, which assigns the address of the program entry point to the linker. The entry point is encoded in the application ELF file format. However it can be displayed with an ELF/Dwarf reader such as readelf. For a CoreWarrior for MCUs tool installation, run {MCU10.2 Installation}\Cross_Tools\CodeSourcery_Linux\bin\m68k-linux-gnu-readelf.exe.

The output of the readelf should appear as:

readelf -l hello.abs
Elf file is EXEC (Executable file)
Entry point 0xc004
....

Therefore, the debugger should halt the program at address 0xc004 when you click Debug.

Summary

If the debug session goes weird right after download, or if the application does not reach main(), then stop the debugger at the program entry point, rather than at main(). It’s easy to do.

Happy Stopping!

Let's get real: Vybrid asymmetric multicore processors start sampling

admin@community.freescale.com — Thu, 05 Jul 2012 21:24:32 GMT

By Tom Thompson -- Not long ago, Jim Trudeau wrote a blog article about our forthcoming Vybrid controller units.

To briefly recap, a Vybrid controller is a system-on-a-chip (SoC) that is capable of handling both network connections and a user interface, yet also respond in real-time to events generated by sensors or other means. At the time, there wasn't any silicon available. However, simulator tools allowed select customers to begin developing software. It was expected that Vybrid controller parts would begin limited sampling around mid-year.

Mid-year has come, and so it's worth revisiting the Vybrid controller scene for a more in-depth look at the software and silicon. Let's start with the silicon.

The Die with a Split Personality

Vybrid controllers come in assorted product families, ranging from microcontroller units (MCUs) that target cost-sensitive, low-power designs up to multicore microprocessor units (MPUs) that address high-performance, highly-responsive rich media products. An overview of the various Vybrid controller parts and the markets they target is available here.

A comprehensive discussion of the complete Vybrid controller product line is not possible in this article, so I'll focus on the high-end Vybrid controller VF7xx part. First, it can handle two independent TFT LCD displays, along with touch screen support. Second, it also manages high-speed Ethernet connections with IEEE 1588 time stamping, and has the ability to process audio and video input streams in real-time. The Vybrid controller VF7xx can deal with both compute-intensive interfaces and real-time processing because it has a split personality: two independent heterogeneous cores, an ARM Cortex-A5 and an ARM Cortex-M4, are integrated onto the die. See Figure 1.

Figure 1 The VF7xx has two disparate cores that manage a huge array of peripherals.

The ARM Cortex-A5 core supports IEEE 754-compliant double-precision floating-point arithmetic, has a NEON graphics acceleration engine with SIMD instruction support, security mechanisms, plus L1 and L2 caches. It does the heavy lifting for compute-intensive operations such as processing audio and video media streams.

The ARM Cortex-M4 has DSP instructions that implement 32-bit MAC operations, and support for IEEE 754-compliant single-precision floating-point arithmetic. It has 16 KB instruction and data caches to boost throughput. These capabilities enable this core to execute low-latency yet computationally demanding operations, making it ideal for real-time work.

In terms of I/O interfaces, the Vybrid controller7xx is, to use the vernacular of my youth, loaded for bear. It has:

10/100 Ethernet controller
Dual USB 2.0 controllers with integrated PHY
Two CAN modules
Four DSPI interfaces
Four I2C interfaces
Video interface unit with camera support for 8- and 10-bit ITU656 video
Four synchronous audio interfaces
Asynchronous audio sample converter with several rate conversions
Sony Philips Digital interface for digital audio I/O
Dual TFT LCD display interface with XGA (1024 by 768 pixels) resolution
Four-wire resistive touch screen controller
Xtrinsic touch screen interface that supports both resistive and capacitive screens
Two 12-bit ADCs
Two 12-bit DACs
Assorted timers
Memory controller for DDR3 and LPDDR2 memories, with EEC support

To handle the speeds and feeds of all these peripherals, 64 DMA channels enable low-overhead transfers between the peripherals and memory. In addition, a crossbar switch enables concurrent multi-master bus accesses between peripherals, memory, and the cores. Address space controllers provide memory protection for all of the crossbar switch masters, which reduce the chance of data corruption.

Given the vast array of on-chip peripherals, all sorts of intriguing product designs based on a minimum of parts are possible.

The Software Scene

The silicon solution, as promising as it sounds, isn't very useful if it lacks the necessary software. Since Freescale's goal is to make the design of both the hardware and software in a product easier, we have software in place to support the Vybrid family.

In terms of operating systems, there is our own MQX RTOS, which I have written about here . We also offer a board support package (BSP) that features a comprehensive native Linux implementation for the part. There are libraries for math, encryption, and motor control. Complimentary boot loaders that function over a variety of interfaces such as USB, Ethernet, RF, and serial connections are provided. To handle video and audio operations, a media framework is available, and a complimentary Freescale embedded GUI (eGUI) software driver provides support for graphics LCD panels. This software can be downloaded from the Freescale web site.

Vybrid controller solutions use the Freescale Tower System platform for software development.

Figure 2 shows a common software scenario using the VF7xx part. Here, the ARM Cortex-A5 core executes the Linux kernel to manage network connections and the human machine interface (HMI). The ARM Cortex-M4 core executes the MQX RTOS and deals with the real-time interrupts and some data processing. A low-latency interprocessor communications API developed in-house by Freescale supervises the communications and the integrity of any data shared between the two cores. Note that the example shown in the figure is not a required software configuration. The Vybrid controller could execute two copies of MQX (MQX RTOS for the Cortex-A5 is in development), or a Linux kernel along with a lightweight task scheduler, or just bare-board code. It all depends upon the demands of your product design.

Figure 2 A Vybrid controller executing two different operating systems simultaneously.

For a more tangible demo application, check out this video of an automotive instrument cluster using the Vybrid automotive solution.

Since samples will be limited, your design team can develop software using a comprehensive simulator provided by VWorks. Its VLAB product is a software simulator module that emulates the Vyrid VF7xx controller and effectively implements a virtual platform of the part. The two disparate ARM cores are simulated in great detail, along with many of the on-chip peripherals. You can examine the contents of registers and memory, and observe the state of bus transactions and the data transferred.

For peripheral devices, you can call up information on the various attributes in use (such as the background color being used by the LCD controller, or the transfer rate of a UART), and display the contents of the various device registers. Even better, the output of most simulated peripherals can be examined to ensure the proper operation of the application software. For example, you can establish a Telnet session to one of the many emulated serial ports to observe the serial I/O generated by prototype application code. Even better, VLAB not only simulates the operation of the Vybrid video controllers, it also presents two virtual LCD screens that display the operation of any UI code. This level of simulation is not only very cool but helps developers verify the graphic output without the need of a prototype system.

VLAB also facilitates code debugging through the ARM Development Studio 5 (ARM DS-5) tools (Figure 3). You use the ARM DS-5 tools to write and build software, and then have its debugger connect to VLAB. The virtual platform allows you to set breakpoints that can trigger when an access to a specific register or signal change occurs. You can debug code on both ARM cores simultaneously. For example, you can have both cores execute code in lock-step to detect synchronization problems. VLAB can collect and record extensive trace information to track down intermittent bugs or to measure code performance. Sessions can be recorded and played back.

Figure 3 Using the ARM DS-5 tools to debug code on the simulated Cortex-M4 core.

You can write and use scripts to change the values of registers of the virtual platform or step through the code that it executes. Scripts can also be written to drive VLAB's operation so that you can perform regression testing on application code. In summary, VWorks's VLAB allows you to thoroughly debug and test your Vybrid controller application code, without any silicon.

Like any new platform, let alone a multicore platform, there is always a lag between announcement and general market availability of silicon. Even when silicon is widely available, your software team may be well ahead of your hardware development team. A virtual model and the tools provided by Freescale and our partner, VWorks, will help you be productive, with or without hardware. That’s part of what we call enablement around here.

CodeWarrior Tool Tip #8: Extending the build system

admin@community.freescale.com — Wed, 27 Jun 2012 02:39:35 GMT

By Tom Thompson -- At Freescale, we spend a considerable amount of effort trying to make the work that goes into a design easier for our customers. The flexibility that our software tools provide often enables you to devise ways to make the embedded software development process for your project easier, or faster, or more reliable. Or even all three.

As an example of this, let's look at a feature in the CodeWarrior tools that allows you to "extend" its build system. Specifically, you can have certain operations execute before or after the CodeWarrior build process. You might do this to, say, have a set of source files pre-processed before the CodeWarrior Eclipse build system gets involved. Or, you might perform post-processing on the ELF file generated by the build system. For example, in the latter case an ELF file might be converted into a format that is suitable for a production firmware burner. Or, a post-processing operation might append a CRC value to the embedded operating system image file that a bootloader would use to validate the integrity of the download.

This pre- and post-processing feature is not new: It's actually an enhanced version of a capability already present in the Classic CodeWarrior IDE. See Figure 1. (As an aside, you can see that valuable features such as this one do get carried forward to the CodeWarrior Eclipse IDE. However, sometimes features prove difficult to migrate to Eclipse, which was the case with CodeWarrior subprojects. However, subproject support has returned in the CodeWarrior V10.2 tools.) In the Classic IDE, the pre- and post-processing feature was found in the Target Settings panel. Note that this ability was limited to performing actions before or after the link step of the build process.

Figure 1 Pre- and post-link processing support in the CodeWarrior Classic IDE

In the CodeWarrior v10 IDE, this build feature happens to be buried deep in a project's build configuration settings. To get to it, choose Project > Properties > C/C++ Build > Settings and then click on the Build Steps tab (Figure 2). The first thing you should notice is that the pre-processing operations are carried out prior to the entire build; they are not limited to the link step.

Figure 2 Pre- and post-processing commands for the build is specified in these options

The other difference is that the pre- and post-build command options allow you to enter an actual command line, whereas the Classic IDE choice did some sleight-of-hand to execute a program or kick-start a batch file. With the command line in the Build Steps option, you can specify a program to run and provide it with any argument values it requires. Or, you can have a batch file run, which leads to all sorts of interesting automation possibilities. Often you're going to have to provide path names and other information to make a usable command line, but this gives you the flexibility to do what you need, rather than be hemmed in by limited choices. In addition, the Eclipse IDE provides convenient symbols and environment variables that make the command line set up much easier. More on that in a moment.

Suppose you're working on a project that performs regression testing. This requires that you regularly pull an embedded application's latest and greatest source and header files from a networked server into your project before commencing a build. Using a text editor, you add the following commands into a batch file, named copy.bat:

rem delete old source and header files in project
del ..\Sources\*.c
del ..\Project_Headers\*.h
rem fetch latest source and header files
copy Z:\Superproject\Sources\*.c ..\Sources\*.c
copy Z:\Superproject\Headers\*.h ..\Project_Headers\*.h

Then you drag copy.bat into the project folder of the CodeWarrior Projects view in Eclipse. Go to the Processing Steps tab as described previously and enter the following command into the Command option of the Pre-build steps group:

$(ProjDirPath)/copy.bat

Then click Apply. Now when you do a build, the commands in copy.bat execute, dutifully deleting and copying files into the specified project directories before kicking off the build.

Note the use of the Eclipse variable $(ProjDirPath), which represents the directory path to your project folder. Table 1 shows a number of Eclipse variables that specify the location of tool directories, the name of your generated binary file (termed an artifact in Eclipse parlance), and other useful information.

Table 1 A few of the symbols maintained by Eclipse for build operations

Symbol	Purpose
${MCUToolsBaseDir}	Specifies the absolute path where are MCU tool folders are located
${ProjDirPath}	Provides the absolute path to the current project folder
${BuildArtifactName}	Name of the image file to be output by the build system
${HC08Tools}	Returns the absolute path to the HCS08 command-line tools
${ProjName}	Name of the project, as was specified in the CodeWarrior New Project wizard

You can use these variables to make powerful and flexible one-line commands. A set of the symbols and variables that Eclipse supports can found under Project > Properties > C/C++ General > Paths and Symbols. Click on Edit and then Variables to display a complete set of build variables (Figure 3).

Figure 3 The pre-defined variables and symbols that Eclipse uses

Since pre-build operations can create dependencies (those files need to finish copying before you turn the compiler on them, for example), the Eclipse IDE automatically switches off its parallel build capability. If necessary you can re-enable the parallel build capability, but be certain that there are no side-effects involved when doing this.

Now let's consider a post-build operation. The embedded software that passed the regression tests needs to be burned into firmware on prototype devices. The firmware burner, however only understands Intel HEX image files. Fortunately for you, the CodeWarrior burner utility that generates Motorola S-records for firmware burners can also generate image files in the Intel HEX format. Assuming that you're working with the HCS08 tools, you edit the burner utility control file, burner.bbl, to specify Intel HEX output. This control file uses the batch burner language (BBL) to specify output file characteristics such as the format, and if the image is to be split across firmware chips, for example. The burner.bbl file is located in the project directory's \Project_Settings\Liker_Files folder. To start, make a copy of this file and rename it intel_burner.bbl. Edit this file to specify the Intel HEX format and output a file with an extension of .hex, to distinguish it from the S-Record file, which has an extension of .s19. The file should resemble this listing:

OPENFILE "%ABS_FILE%.hex"
format=intel
busWidth=1
origin=0
len=0x1000000
destination=0
SENDBYTE 1 "%ABS_FILE%"
CLOSE

Elements in red have been changed from the original file. The symbol %ABS_FILE% represents the symbolic name of the binary artifact file generated by the tools. You will supply an argument to the burner utility program that specifies this name.

Going back to the Build Steps tab of the Build Settings view, in the Command option for the Post-build steps group, enter:

"${HC08Tools}/burner.exe" -f=${ProjDirPath}/Project_Settings/Linker_Files/intel_burner.bbl \
 -envABS_FILE=${BuildArtifactFileName}

Where:

${HC08Tools} specifies the directory of the CodeWarrior HCS08 tools

${ProjDirPth} states the path to the CodeWarrior project

${BuildArtifactFileName} is the name of the final binary image file

This command first launches the burner utility program, burner.exe. Note that this argument is bracketed by quotes in case the path name contains a space. Next, the -f argument instructs burner where to find its .bbl command file. Finally, the -env argument specifies the name of the image file to process. The symbol ${BuildArtifactFileName} feds this image file name directly into the %ABS_FILE% symbol in the burner command file. When the project builds successfully, a file with the extension of .hex should appear in the project folder. The astute CodeWarrior developer might suggest that you could have simply edited the existing burner.bbl file to generate the Intel HEX file, but then that wouldn't have made much of an example, right?

In order to write successful command lines, it behooves you to read the tool documentation carefully to see as to what environmental variables and symbols they support and can be put to work for you in the command line. In the case of the burner example, I had to read the HC(S)08/RS08 Build Tools Utility Manual for information on the burner program and batch burner language. Second, if you have problems, just study the output in the Console view as the build progresses. It will display the command line with all of the symbol substitutions made, and from that you can catch a lot of errors. Again, this adds some additional complexity for you, but in turn it gives you great flexibility in what you can do prior to or after the build process. Also, don’t forget that on top of extending the build system operation, you can also use Tcl scripts to drive the CodeWarrior IDE and further automate your development process.

Happy building!

Freescale announces Windows 8 sensor fusion

admin@community.freescale.com — Thu, 14 Jun 2012 23:58:20 GMT

By Michael Stanley – In my last post (“Degrees of freedom vs. axes”) we discussed some basic terminology for sensor fusion. This time around, we get to put that lesson into practice as we examine Freescale’s recent technology announcement of a full featured reference platform for Windows^® 8 sensor fusion.

If you are a regular reader, you’ll know by now that I am fascinated by sensors and sensor fusion software. These are the technologies that let us interface with our electronic toys with a simple tap, swipe or gesture. So I was energized last week when Freescale announced development of a 12-axis, sensor fusion reference platform for Microsoft^® Windows^®8. I was at the kickoff meeting last year between Microsoft and Freescale, and I’ve been watching the system evolve in our offices since. We’re not quite ready to ship boards to the general market, but we’re excited and want to share our plans and status with you.

Figure 1: Freescale Microsoft® Windows® 8 Sensor Fusion Data Flow

From an information flow point of view, the board looks something like Figure 1. Our 12 axes of sensor input information are:

X/Y/Z Accelerometer
X/Y/Z Gyroscope
X/Y/Z Magnetometer
Barometer (air pressure)
Temperature
Ambient Light

Each of these is available in one form or another as outputs of the system, but more importantly, the system also computes board orientation. This can come in one of several forms:

quaternion
rotation matrix
Inclinometer Euler angles

You also get compass heading out of the mix. From a hardware perspective, the board looks like the block diagram in Figure 2.

Figure 2: Functional Level Block Diagram

Sensor fusion software is pre-installed in the MCF51JU128 flash memory. To utilize the board, you will need a Windows® 8 enabled computer or slate to act as host:

If your device is already equipped with sensors, you'll need to disable them via the device configuration screens in Windows 8. If your device isn't already sensor equipped, you can skip this step.
Plug the development board into your device's USB port.
You are done!

Pure plug & play. That’s because Microsoft has defined an “HID over USB” protocol for communications with a sensor fusion subsystem. The Freescale board talks the same language as Windows 8. And since Freescale will be publishing the full schematic and bill of materials, adding motion sensor capability to your Windows PC or slate couldn’t be easier.

Once the boards start shipping, you'll be able to download user manual, schematics and CAD files from the Freescale web site. The user manual will include instructions for customizing the software for use on your PCB, since placement orientations for sensors will vary from board to board. Don't worry. The process should be relatively painless.

Freescale will also supply a basic sensor application that you can use to test out your sensor subsystem. The application gives you a visual compass display, along with either a 3D view of a virtual gyroscope (Figure 3) or a window into a virtual room (Figure 4). You can see accelerometer, gyroscope (which Microsoft refers to as a “gyrometer”) magnetometer, ambient light sensor, temperature and air pressure readings.

Figure 3: Gyroscope (wired) view

Figure 4: Virtual Room (attached) view

Microsoft has a rigorous certification process which is encapsulated in their “Windows Hardware Certification Kit”, or “WHCK”. The WHCK specifies passing sensor test criteria and ensures hardware/software compatibility. Microsoftupdates the WHCK on a regular basis, and Freescale continuously tests its solution using the WHCK. Final certification of the kit will occur after Microsoft releases their final WHCK. This will occur before the Windows 8 OS release. I can tell you that the software is passing most of the WHCK today, with only a few open issues which we expect to resolve shortly.

A brief video demonstration of the system can be viewed in the window below.

We expect Freescale's Windows 8 reference design to be available in late 3rd quarter, so you'll have to wait a bit. But we wanted you to know it's coming, and it's real.

Finally, on another topic, if you happen to be attending the Freescale Technology Forum in San Antonio next week, and you see a fellow who looks a bit like the picture alongside this post, please come up and say hello. I would love to talk with you about your sensor needs.

References: