The TI engineer-to-engineer (E2E) Community, which launched in 2008, is an open support community. The goal of TI’s E2E community is to provide a seamless customer experience on all TI supported products. This includes building a strong community of engineers, providing quality engagement on the site and enabling customers to value and to find the information that will help them solve their problems.  The E2E support forums and specialty blogs are a wonderful data source for our engineering community.

Users can collaborate by asking and answering technical questions, sharing knowledge, exploring new ideas and solving problems. This community is supported:

• Primarily by the TI factory teams with field and customer support
• By more than 190,000+ engineers spanning 100+ countries and TI experts

Watch this video about our TI E2E Community:

 (Please visit the site to view this video)  

A few facts about TI’s E2E community platform:

• Based on Zimbra Social 8.0
• SEO optimized for easy search
• Responsive design for ease of use on many devices
• 100+ support forums to answer a bevy of design questions
• 19+ blogs based on design specialties
• Custom groups for  our Regional partners in Japan and Russia
• Approximately 3,000+ new members join each month.
• More than 1.5 million posts alone in the community with 75K+ new threads per year
• Reward and recognition programs to drive engagement for engineers who are frequent responders with quality content and answers
• Integrated support dashboards for measurement and improvement from our internal business teams
• Redesigned in 2014 to improve our customer experience

 Our community growth over  time:

• E2E has garnered great customer interaction since its launch
• Number of active threads has grown over the years

E2E testimonials

The best part of TI’s E2E community? The success stories. Check these out:

(Please visit the site to view this video)

“It’s a great success – saving our time and customer’s time, and ultimately making it a more positive customer experience. I highly encourage using the E2E forum and wiki.”   -- Frank Dehmelt, TI applications engineer

(Please visit the site to view this video)

“Customers like having the ability to contact TI applications engineers directly.  Because we have engineers worldwide, we can assist customers in real time, no matter the time zone.”  Don Dapkus, TI audio applications manager

(Please visit the site to view this video)“The avenue to explain to customers how design decisions are done so customers get more understanding about the product and what they’re looking at – it’s great.  I love having the interaction with real-world and real situations.  We’ve made numerous improvements to the tool, based on suggestions from customers and other TIers.” – Rafael de Souza, TI software applications engineer.

And of course, our non-TI experts who are regular participants in providing answers on our forum.  Hear what Jens Michael Gross’, TI customer and one of TI’s E2E contributors of the year, has to say about E2E:

“I enjoy the discussions with other customers and TIers to get questions answered by customers. Providing a forum for questions and answers is a benefit for both sides. The company saves money, and it builds customer relationships. It’s a win-win situation. You can profit from the experience of others, and I find solutions to problems I didn’t know I had!”

(Please visit the site to view this video)     (Please visit the site to view this video)

Thank you for your support of the e2e community!

In a recently released white paper, “Powering sensors with LDOs for industrial process control,” I reviewed important design requirements for low-dropout regulators (LDOs) used in industrial process control sensors. The paper examined the importance of an LDO delivering a small solution size while ensuring sensor accuracy and providing system protection.

One of my proposed solutions for a sensor power supply involved using a switching regulator followed by an LDO to get high efficiency and low power-supply noise. I thought it would be helpful to dive into this solution in a little more detail to help you understand why this solution is advantageous and how to select the right devices for sensors.

First, let’s take a look at the issues of power-supply noise and efficiency. In the white paper, I showed how using a switching regulator instead of an LDO can provide almost twice the power to the sensor circuitry, so I will not cover that in this post.

Here are some basic assumptions related to the overall efficiency of DC/DC converter + LDO solutions:

• The overall sensor system current is 3mA at 3.3V (just under the 4mA budget).
• The typical input voltage from the 4 to 20mA loop to the sensor is 24V.
• The Iq of the LDO is 45µA. We will use the TPS71733 for the analysis.
• The efficiency of the switching regulator is 80%.
• The intermediate voltage between the DC/DC converter and LDO is 3.8V. This gives the LDO enough headroom to provide good power-supply rejection (PSR).

The white paper showed that the power dissipated by the LDO is:

So for our example, the input voltage to the LDO is 3.8V, the LDO power dissipation is 1.51mW and the power dissipated by the DC/DC converter is:

The V_LOAD in the equation above will be the 3.8V output voltage and the DC/DC converter power dissipation will be 2.85mW. The load power is simply 9.9mW.

Thus, the overall system efficiency is the power delivered to the load divided by the total power dissipation, which is 70.1%. This is much better than the 13.8% (=3.3V/24V) efficiency delivered by just using an LDO.

Now let’s take a look at power-supply noise. We know that noise on the sensor-system supply can induce noise into the signal-chain measurement and degrade overall system performance. Taking a typical class A resistance temperature detector (RTD) with a temperature range of -30°C to 300°C, the mid-range accuracy is 0.5°C, which implies an accuracy of 0.17% (=0.5°C/330°C). To avoid contributing significant error to the measurement, the accuracy of the signal chain should be at least 10x better – roughly 0.01% or better.

A very popular device used to interface with RTD elements is the ADS1220, a low-power 24-bit analog-to-digital converter that includes features for interfacing to RTDs. Looking at the datasheet; we can see from the parametric table that the minimum PSR is 80dB, which is quite impressive.

To prevent the RTD from self-heating and affecting the temperature measurement, lower excitation currents are used, causing lower full-scale voltage readings. For many RTD applications we might see a full-scale range of 100mV, so for 0.01% accuracy from above, we would like to be able to resolve 10µV at the RTD to maintain accuracy.

Choosing a step-down DC/DC converter as the input power supply for the sensor system (operating in the range of 300kHz with a output voltage ripple of  typically 10mV), we would want the LDO to attenuate this signal sufficiently to not affect the ADS1220 performance. This means that the LDO must have good PSR at the primary switching frequency of 300kHz and probably for two or three harmonics above. Figure 1 is a PSR graph of the TPS71733.

Figure 1: TPS71733 PSR with 0.5V of headroom

At the third (odd) harmonic of 2.1MHz and low output currents needed by the sensor system, the TPS71733 will have in excess of 40dB of PSR, which means that the LDO will attenuate the DC/DC ripple by a factor of 100.

Without the LDO, the ADS1220 will attenuate noise on the power supply by a minimum of 80dB, or by a factor of 10,000. This means that the 10mV of ripple will become only 1µV of ripple with an ideal design and layout. While this is only 10% of our desired resolution, some additional filtering would be helpful in removing the effects of power-supply noise. Adding in the attenuation provided by the TPS71733, we get another factor of 100 and the effect of power-supply noise on the measurement becomes negligible.

A DC/DC converter + LDO gives you the best of both worlds: good efficiency and low noise.

How have you used an LDO to optimize your power supply performance?

Thanks to the Internet of Things revolution, we’re seeing more devices connected to the cloud via Wi-Fi®  and Bluetooth®. Load switches are commonly used to save power by disabling radios (and other power-hungry subsystems) when your smartphone, for example, is in standby mode. This lowers the device’s overall power consumption, making batteries last longer.

How does a load switch work?

Think of a load switch as an electronic light switch, used to turn a load on and off. Basic load switches have only four pins: V_IN, V_OUT, ON and GND. Figure 1 shows features found in more complex load switches.) Turning the load switch on (by asserting ON high) lets current flow from V_IN to V_OUT. When you turn off the switch, no current flows from V_IN to V_OUT, and everything downstream is also turned off. The standby power consumption of the load switch effectively replaces the standby power consumption of the load(s) on V_OUT. 

Figure 1: Generic load switch block diagram

At electronica in November, we highlighted our latest solution for energy harvesting. We saw tremendous interest, but knew there was a critical piece we could add to make it just a little-bit more exciting. Have you figured it out yet?

At the embedded world this week in Germany, we will be showcasing this demo again, now complete with cloud connectivity! The last post on this topic (linked above) highlighted the hardware:

• BQ25570 Energy Harvesting Reference Design
• MSP-EXP430FR5969 - MSP430FR5969 Launchpad
• 430BOOST-CC110L - Sub-1GHz BoosterPack

This time, we leveraged the SimpleLink Wi-FI CC3200 LaunchPad as a central hub and wanted to share the code we used to connect to the cloud. To do this, we leveraged Energia, the rapid prototyping development environment for LaunchPads. We used it to send all of our sensor data to Exosite, a cloud service which was leveraged to monitor a home or building automation focused sensor network.

As you can see in the portal above, our Exosite dashboard monitored 4 key things over the internet:

• Motion - could be used to control lights as people enter or exit different rooms, to minimize electricity used for lighting
• Ambient Light - could be used to open your bedroom blinds in the morning or to control light coming into a house or building to manage decrease the use of air conditioning
• Temperature - could be used to communicate with a thermostat, essentially extending understanding of the home/building environment to better control the air conditioning or heating from its single remote location
• Moisture - could be used to notify you in the event of a flood, or could be used to control a valve for watering your favorite plant

This implementation was created using the Wi-Fi Exosite Client example C code, as well as the simple Wi-Fi applications in Energia. The software really consists of three components:

• Connecting to the network
• Communicating with Exosite
• Code for debugging

Connecting to the network is pretty straightforward (given you have the SSID and password) using the available Energia code:

  WiFi.begin(ssid, password);
  while ( WiFi.status() != WL_CONNECTED) {
    // print dots while we wait to connect
    Serial.print(".");
    delay(300);
  }

The next piece was getting all of the content together and in order to connect with Exosite. This cloud provider uses an HTTP connection for receiving data.

// this method makes a HTTP connection to the server:
void sendData(String thisData) {
  // if there's a successful connection:
  if (client.connected()) { 
//    Serial.println("connecting...");
    // send the HTTP POST request:
    client.println("POST /onep:v1/stack/alias HTTP/1.1");
    client.println("Host: m2.exosite.com");
    client.print("X-Exosite-CIK: ");
    client.println(CIKKEY);
    client.println("Content-Type: application/x-www-form-urlencoded; charset=utf-8");
    client.println("Accept: application/xhtml+xml");
    client.print("Content-Length: ");
    client.println(thisData.length());
    client.println();

    // here's the actual content of the POST request:
    client.println(thisData);
   
    // last pieces of the HTTP POST request:
    client.println();

  }
  else {
    // if you couldn't make a connection:
    Serial.println("connection failed");
    Serial.println();
    Serial.println("disconnecting.");
    client.stop();
  }
  // note the time that the connection was made or attempted:
  lastConnectionTime = millis();
}

Armed with the lowest-power microcontrollers on the planet, built to run on nothing but ambient energy, you could add intelligent information to any system. Now, by connecting data from the network to the cloud, the possibilities for a better life are only limited by your imagination. Are you using MSP430 microcontrollers in a system with Wi-Fi connectivity? Share with us in the comments and you may be featured in the next edition of Community Highlights!

Many applications require low-noise power supplies, including laser-diode drivers and optical modules. Even with low equivalent series resistance (ESR) ceramic output capacitors, it is often impractical to use a traditional single-stage inductor-capacitor (LC) filter to power such loads. Designers may be forced to use a two-stage LC filter in order to achieve output ripple levels in the sub-5mV range. If designed properly, the two-stage filter can meet very tight power-supply noise requirements. In this example, we will walk through the design of a 5V-input 3.3V/5A power supply with a <1mV ripple specification.

For simplicity, let’s start with a single-stage 750kHz switcher designed with a 1µH inductor and one 22µF 6.3V X5R ceramic output capacitor. The calculated output ripple is 39mV, mostly due to the limited capacitance of 7.2µF from DC bias. 31dB of attenuation is needed at the switching frequency to reach 1mV of output ripple.

The first step is to choose a second-stage capacitor approximately four to 10 times the first stage capacitance. Smaller capacitances will push the second resonance away from the power-supply loop bandwidth, while larger capacitances increase attenuation but potentially interfere with the control loop. A 100µF 6.3V X5R ceramic capacitor is used for the second-stage capacitor in the example. By choosing a second resonance of 150kHz, Equation 1 can be used to calculate the second inductor.

Figure 1: Schematic and transfer function

Figure 1 shows the schematic and transfer function before and after the second LC. There are two resonances: 25kHz and 150kHz. Also notice 39dB more attenuation at the 750kHz switching frequency measured after the second filter.

The second and  final step is to compensate the power supply using current-mode control for simplicity. Simulating the power-stage gain and phase shows the output pole at 6.5kHz. I recommend rolling the power supply off low enough to prevent the second resonance from crossing back over zero and maintaining greater than 10dB of gain margin. In this example, 25kHz bandwidth is sufficient. Figure 2 shows the measured loop response.

Figure 2: 5Vin, 3.3Vout at 5A loop response

Figure 3 shows the ripple after the second stage – well below 1mV. 

Figure 3: Second-stage output ripple

The two-stage filter is a popular way to reduce the output ripple of a buck converter. Careful design considerations will yield a low-noise, stable power supply. For more information, please see PMP10900.

Additional Resources :

EETimes: Power Tip 54: Use a 2-section filter for low-noise power supply

The new SimpleLink™ CC26xx/CC13xx ultra-low power platform for Bluetooth^® Smart, 6LoWPAN, ZigBee^®, Sub-1 GHz and ZigBee RF4CE™ is built and designed with low power in mind. We’ve looked at all aspects important to making sure the energy footprint of our solution is as small as possible enabling longer battery lifetimes, smaller batteries or even energy harvesting for battery-less applications.

Application

Contrary to popular belief, that radio transceiver itself is rarely the main contributor to the overall power consumption of a wireless microcontroller (MCU). As various technologies progress, there is more and more need for computing power even at relatively small sensors and the wireless protocol stacks come with more overhead as the standards evolve.

In the SimpleLink CC26xx family, there are two very energy efficient MCUs available for the application.

ARM^® Cortex^®-M3

The ARM Cortex-M3 is the main system CPU inside the CC26xx device. One way of measuring the performance of MCUs is by using benchmark tools. One of the more popular benchmarks is CoreMark from the Embedded Microprocessor Benchmark Consortium (EEMBC). CoreMark is a simple, yet sophisticated, benchmark that is designed to test the efficiency of a processor core used in embedded devices. It is not system dependent, therefore it functions the same regardless of the platform (e.g big/little endian, high-end or low-end processors etc.). This benchmark also demonstrates the energy efficiency of the MCU core.

Table 1: Various CoreMark scores for the CC26xx, measured on CC2650-7ID @ 3.0V and 48MHz

The scores in Table 1 allow for very low average power consumption during active use. Running the ARM Cortex-M3 at maximum speed (48MHz) the CPU operation consumes less than 3 mA and outperforms any wireless MCU running at less efficient cores or at lower CPU clocks. The CC26xx Coremark power efficiency (CoreMark / mA) is the best compared to any competitor with a comparable MCU, making it the most energy efficient microcontroller available today.

Sensor Controller

The unique ultra-low power sensor controller is a 16-bit CPU coupled with peripherals like analog to digital converter (ADC), analog comparators, SPI/I2C and capacitive touch. It is designed to run autonomously when the rest of the system is in standby.  The Sensor Controller allows interface with external analog or digital sensors in a very low power manner.

Figure 1: The ultra-low power sensor controller engine can run autonomously while the rest of the system is in standby

Waking up the entire system to perform minor tasks is very often not energy-efficient as it introduces a lot of overhead. In many use cases there are tasks that need to run at certain intervals that are at a higher duty-cycle than the actual RF or main activity.

One example could be a heart-rate monitor that needs to run the ADC 10 times per second to capture the heart rate accurately. Waking the entire system up to perform a wireless transmission 10 times per second will in this case be very energy inefficient. With the SimpleLink ultra-low power CC26xx platform, one can let the Sensor Controller perform all the ADC measurements and wake up the ARM Cortex-M3 every 10^th ADC sample for optional further processing and group RF transmission of this data.

Figure 2: The sensor controller can significantly reduce average power consumption

In this example the sensor controller can do 10 ADC reads per second at less than 3 uA average consumption. Performing the same task using the ARM Cortex-M3 will require 10x the power consumption.

Table 2: Energy efficiency of the sensor controller while running at the main clock.

The sensor controller can run directly off a pre-scaled 24 MHz clock, making it capable of collecting data and performing simple processing of the data.

Radio

Traditionally the peak drain caused by high transmit and receive currents of wireless solutions puts constraints on the batteries that could be used or significantly reduced the battery lifetime. With the very low peak currents of the CC26xx at around 6mA (0 dBm output), this no longer poses any limitations on the traditional CR2032 batteries and can even allow for smaller batteries to be used. From an average power consumption perspective, the radio is no longer the main contributor and is of less concern and there is no longer a need to back down on the output power to reduce the peak consumption.

Sleep and shutdown

In any battery operated application, the RF (receive/transmit) duty-cycle and its parameters decide the battery lifetime. Between transmissions, it is important to keep the standby currents as low as possible so that there is enough juice in the battery for the active use. The CC26xx uses an ultra-low leakage SRAM that can be fully retained (20 KB) and in addition have the real time clock (RTC) running, and registers and CPU state retained while in standby consuming as little as 1uA. In shutdown, the CC26xx can wake up on external IO events while drawing as little as 150nA.

The shelf lives for CR2032s are increasing and some vendors now state up to 10 years of battery life. The average system current drawn from a 220 mAh CR2032 has to be below 2.5uA to reach 10 years lifetime [2]. If the base current of a system is above this, one cannot reach the maximum potential of the battery, no matter how low active duty-cycle one implements.

How average current affects battery lifetime

Battery life time is mostly about the average power consumption. This will be very use-case dependent, but there is a benchmark now available from EEMBC called ULPBench™ that standardizes on datasheet parameters and provides a methodology to reliably and equitably measure MCU energy efficiency. ULPBench uses a common set of workloads that are portable across 8-, 16- and 32-bit microcontrollers, enables the use of MCU low-power modes while focusing on real-world applications utilizing integrated hardware functions. In the end it analyzes the effects of active and low-power conditions [3].

Figure 3: CC26xx ULPBench scores vs competition

Another common way of looking at average current is to look at a specific use-case for a given technology. For Bluetooth Smart, one way is to point out the average while keeping a connection between two devices at a given interval.

Table 3: Average scores for the CC26xx, measured on CC2650-7ID @ 3.0V

All of what has been discussed comes into play when looking at the power profile of a wireless event. Figure 4 shows a connection event for Bluetooth Smart with wake-up, pre-processing of the software stack, radio events (both receive and transmit) and a post-processing / going back to sleep period.

Figure 4: Power pofile of a Bluetooth Smart connection event

Further details on how to calculate average currents and battery-lifetime for a Bluetooth Smart application can be found in [4]

Reference:

[1] Cortex-M0+ Processor

[2] Marketing Malarkey and Some Truths About Ultra-Low Power Design, Jack Ganssle 2014

[3] EEMBC ULPBench

[4] Measuring Bluetooth® Smart Power Consumption

Last week I wrote about the number of Industrial Communication Solutions supported by MSP430 microcontrollers (MCUs), the most popular among them being the 4-20 mA current loop. We will be showcasing this solution at the embedded world tradeshow in Germany this week. So what exactly is the 4-20 mA solution?

The current solutions can be either 2-wire current loops that provides the communication channel and power to the field transmitter or the 3-wire current loops that have a separate power line not associated directly with the 4-20mA current loop. In this kind of communication, the resolution is by voltage controlled current source and the total current budget for 2-wire field transmitter is less than 3-3.5mA. This makes the ultra-low-power MCUs extremely suitable for 2-wire communication loop solutions. 

Thanks for tuning into part 2 of this series on active shielding. In my last post, I talked about the benefits of shielding and how it helps mitigate parasitic-capacitance interference from your capacitance measurements. Today, I’ll discuss shield sensor designs and how the size and placement of the shield in relation to the sensor electrode affects sensor performance.

The shape and position of the shield relative to the sensor is an important factor in capacitive-sensor design. The sensing angle without a shield, as shown in Figure 1, picks up any stray interference within the field-line vicinity. The sensing angle with a shield depends on both how large the shield is compared to the sensor and how close the shield is to the sensor. Although the shield helps mitigate the effects of parasitic-capacitance interference from the surrounding area, it does reduce the sensitivity and overall dynamic range of the system.

Figure 1: Direct/focusing the sensing area

I performed an experiment with four different shielding configurations to determine what kind of relationship shielding has with directivity, sensitivity and parasitic-capacitance interference mitigation. The isolated sensor topology employed here is mainly used for proximity and gesture-recognition applications such as system wakeup detection and infotainment display interaction. The target object is the human hand (grounded target). The four configurations were:

1. CIN1 electrode only.
2. Shield1 the same size as CIN1 and directly underneath.
3. Shield1 200% larger than CIN1 and directly underneath.
4. Shield1 ring added on the same plane as CIN1 with Shield1 underneath (same as configuration 3).

Figure 2: Sensor layouts

Figure 2 shows the top and side profiles of the sensor layout stack-up. Shielding the sensor electrode will help block any external interference and noise. The experimental results show that even though shielding does not totally eliminate all of the interference, it does significantly reduce it. The top side of the sensors is the intended target area for the human hand (in proximity and gesture-recognition applications). The top side is the most common direction for proximity detection, whereas the proximity from the side and the bottom is treated as the unwanted interference.

Figure 3: Interference data comparison from the side

Figure 3 shows the change in capacitance as the parasitic capacitance (human hand) approaches from the side of the sensors. It is apparent that as the shield size increases, the effects of the interference are reduced.

Figure 4: Sensitivity data comparison from the top

Figure 4 displays the sensitivity of the sensors from the intended target direction (from the top). Note that increasing the area of the shield decreases sensitivity and dynamic range to some extent in the target zone. This occurs because the shield decreases the amount of electric field lines that terminate to the nearest ground source. Various applications will require a certain proximity range and margin for interference; the shield will need to be sized appropriately for each case since it does not have a linear relationship to range and interference. Table 1 shows that either using a shield the same size as the sensor, or one that is 200% larger in area, has about the same impact on target-zone sensitivity. But using a larger shield can reduce the vulnerability to interference from the side.

Measurements with bottom-side interference show a significant reduction in capacitance change at a fixed distance away from the sensor. All of the interference cannot be eliminated unless the shield is much larger (by an order of magnitude) than the sensor due to fringing fields near the edges of the electrodes.

Table 1: Error-reduction comparison

Overall, shielding is a very effective method for protecting the signal integrity of the system. The placement and configuration of the shield depends on the application and amount of acceptable parasitic capacitance. Up to 77% of parasitic-capacitance interference can be eliminated at an expense of up to 74% decreased sensitivity, depending on the desired sensing range and shield configuration. You will need to characterize each system properly to determine the optimal shield parameters.

Additional resources:

• Experience capacitive-sensing technology firsthand with the FDC1004evaluation module, which you can order today.
• Read more capacitive sensing blogs, including part 1 of this series on active shielding.
• Check out the latest TI Designs reference design for capacitive-based liquid level sensing.
• Search for answers and get help with your designs in the TI E2E™ Community Capacitive Sensing forum.

What if I told you that the way you have been comparing low-power microcontrollers was wrong?

The new ULPBench benchmark from the Embedded Microprocessor Benchmark Consortium or EEMBC (the creators of the COREMARK® benchmark) focuses on application-level power. It considers system functions such as the real-time clock, power modes and integrated hardware. The ULPBench benchmark offers a true comparison of system current and energy efficiency across microcontrollers and currently ranks  MCUs from TI ahead of the competition. 

The true value of this benchmark is clear when you leverage the EEMBC EnergyMonitor. With the purchase of the microcontroller-agnostic hardware, developers also gain access to a software GUI that can be used to track energy consumption while the benchmark is running. (See the video below for EnergyMonitor running on the MSP430FR5969 MCU)

The ultra-low-power MSP430FR5969FRAM MCU has been available to order since mid-2014 and has been leading the competition with 30 percent higher score for the past six months. One of TI's wireless MCUs currently ranks #1, but the MSP430FR5969 still ranks better than most of the competition with a ULPBench score of 117 (the first to be officially certified by EEMBC). The value of these microcontrollers is amplified with FRAM, which provides advantages in data logging applications or applications that spend the majority of time in sleep modes.

Now, if you haven't read about TI's big announcement at embedded world - it's time to get caught up! The new device in our microcontroller portfolio will continue to showcase the low-power dominance of Texas Instruments!

(Please visit the site to view this video)

This is the fourth entry of a five-part series to help you learn more about our robust MSP430 tool chain. Don’t miss Parts 1, 2 and 3 on this blog from past weeks, because this week we focus on the MSP430 flasher.

MSP430 Flasher is an open-source, shell-based interface for programming any of our MSP430 microcontrollers through an MSP Debug Stack and provides the most common functions on the command line. It provides the user with easy access to MSP430 MCUs through a FET via JTAG or Spy-Bi-Wire (SBW).

The benefit of using the MSP430 Flasher is that you can download binary files (.txt/.hex) directly to the MSP430 MCU’s memory without the need of an integrated development environment (IDE) like TI’s Code Composer Studio v6 (CCS) or IAR’s Embedded Workbench. It can also be used to extract firmware directly from a device, set hardware breakpoints and lock JTAG access permanently. 

The MSP430 MCU Flasher runs from an executable file called MSP430Flasher.exe. Here is an example to show how to upload the firmware with MSP430 Flasher.

1. Get free MSP430 Flasher. Once the download is complete, run the installer and follow the on-screen prompts.
2. Generate the .txt/.hex version of the firmware that you intend to upload, for instance “Firmware.txt”. Copy the firmware into the folder where the flasher is installed. By default it’s “C:\ti\MSP430Flasher_1.3.3”.
3. Open a new command prompt window and navigate to the folder. Run the following command and hit “enter” to execute the uploading.

MSP430Flasher.exe -n Unknown -w "Firmware.txt" -v -g -z [VCC]

If the firmware is uploaded successfully, you should see a result similar to the one in the screenshot below. This process is easy to execute and should take only a few minutes to update your firmware.

The MSP430 Flasher can run from any directory location. This makes it easy to provide an update option for new firmware. The MSP430 Flasher officially supports the following operating systems:

• Windows 7 32/64 bit
• Windows 8 32/64 bit
• Windows XP 32/64 bit
• Ubuntu 12.04 32 bit

MSP430 Flasher is not a debug tool. Its main purpose is to serve as a light-weight alternative to using IDEs for simple target code programming or reading operations.

Get your free MSP430 Flasher and try it today.

In my last post, I presented a three-step process for calculating the deterministic latency of a JESD204B link. In this post, I’ll explain: 1) how to choose your release buffer delay (RBD) to ensure a deterministic latency, and 2) how to measure and verify the expected deterministic latency. 

Choosing the appropriate RBD value

As discussed in my previous post, RBD=K is the default setting. This allows the initial lane alignment sequence to align all lanes and release them at the subsequent multiframe boundary. There are situations where system delays could cause the last arriving lane to straddle the data release point. In this case, the lanes may be released with a latency that varies by one multiframe period, depending on if the last lane arrives just before or just after the multiframe boundary. The choice of RBD is critical in this situation to provide enough margin to account for variations in the system delay while at the same time minimizing latency when the data is released.

Figure 1: Possible release points A: maximum margin, maximum delay versus B: minimum margin, minimum delay

As shown in Figure 1, an RBD=A setting would provide possible release points that would maximize the margin for variations in system delay. This also means, however, that the data must be delayed longer before it is released, resulting in a longer latency. A setting of RBD=B would release the data immediately after the last lane arrival, but some care is required to ensure that the selected delay allows enough margin to avoid possible issues with system variations.

Figure 2: Adjusting RBD to find a possible optimal release point 

One possible setting would be to offset the release point by the expected amount of system variation after the latest arriving lane. This may provide the appropriate trade-off between latency and margin to absorb possible system variations. This optimal data release point can be derived from the system parameters if those are readily available. For cases where the delay parameters are not readily available, you can derive the release point empirically.

First, start by using the default RBD=K setting. Then repeat the power cycle and adjust the delay until you observe full multiframe jumps in the measured latency. This is the upper range of the last lane arrival. As you continue to decrease the RBD value through the delays caused by system variation, you will notice the latency stabilize. This is the lower range of the last lane arrival. The difference between the upper and lower range is the system delay variation. Setting the RBD delay to this offset from the upper range is one possible optimal solution that would provide a margin against system variations while providing a consistent data release point.

Calculating, measuring and verifying your deterministic latency

A system consisting of the 16-bit, 370-MSPS ADC16DX370 and an FPGA was used to compare the measured latency with the expected latency from our calculations. The ADC16DX370 was connected to the FPGA mezzanine card (FMC) port of the FPGA platform. A pulse was generated and fed into the input of the analog-to-digital converter (ADC), as well as an oscilloscope. The ADC samples the input signal and passes this data to the FPGA through the JESD204B link. Upon receiving the ADC sample, the FPGA then sends the most significant bit (MSB) to an input/output (I/O) pin to be monitored by the oscilloscope. By factoring in the delays of the cables and board traces, and the time it takes for the input pulse signal to be sampled and passed through the link to the FPGA, it is possible to measure and confirm your latency.

The block diagram in Figure 3 shows the expected delays of the cables and traces for the various parts of the setup.

Figure 3: Additional non-device-related delays used in the delay calculation. A pulse is sent to the oscilloscope and the ADC. The MSB from the captured sample is compared against the pulse to measure the delay.

The following configuration was used on the ADC16DX370 and FPGA:

1. ADC device clock = 370MSPS (2.7ns period).
2. JESD204B parameters:
   1. L = 4, M = 2, F = 1, S = 1, K = 32.
   2. The frame cycle = 10*F/linerate = 10*1/3700MSPS = 2.7ns.
   3. LMFC cycle = frame cycle * K = 2.7ns*32 = 86.4ns.
3. FPGA device clock = 92.5MHz (10.8ns).
4. Link parameters (frame cycles):
   1. .
   2. N = 2, RBD = 28 (less than K).
5. Additional delays outside of the link latency (frame cycles):
   1. ADC core delay = 12.5.
   2. DEVCLK routing skew and MSB output cable/printed circuit board (PCB) routing delay = 3.8ns/2.7ns ~ 1.4.
   3. SYSREF/DEVCLK sampling skew within ADC = 1.5.
   4. FPGA receiver processing delays to latch the samples and send out the MSB = ~7.

As derived in my previous post, Equation 1 is:

Link latency = 116.5 frame cycles

Estimated total latency = link latency + additional delays = 116.5 + 12.5 + 1.4 + 1.5 + 7 = 138.9 cycles

The delay was measured over multiple power cycles between the signal pulse and the MSB from the FPGA. This gave a consistent latency result of 379.6ns, which equates to 140.4 frame cycles. This closely matches the estimated delay of 139 cycles based on the system parameters.

For additional advice about designing with for JESD204B, see the resources below:

• Take a deeper dive into JESD204B subclasses and deterministic latency in this training presentation.
• Download our JESD204B white paper for tips on what you need to know when transitioning to JESD204B.
• Read more JESD204B blogs.
• Learn about TI’s JESD204B ADCs, DACs, clocks and tools.

When designing a wearable product, the first thing that comes into mind is probably its size. The available space for wearables is very limited, yet the battery occupies a higher percentage of the total size due to the long operating time between charges and various functions of wearable devices. The rest of the solution has to be more compact to be able to integrate more functions while also saving extra space for the possibility of a bigger battery.

There are a few options to make the solution size smaller. First of all, the size of the integrated circuit (IC) itself can be greatly reduced by choosing a different package. Compared to the quad flat no-lead (QFN) package, the wafer chip-scale package (WCSP) is on average more than 50% smaller and is almost the same as the true die size. However, because the output current is normally below 300mA for wearables, the power dissipation is also not as large as in the high current applications.  Therefore thermal is no longer a big issue in low-power wearable applications.

Consider TI’s PicoStar™ IC packages and MicroSiP™ modules to shrink your solution further. SiP stands for system in package and combines common functions to reduce board space.  PicoStar embeds the IC in the package substrate and stacks the other passive components on top of it. Reducing the space needed in the device by as much as half.  Figure 1 shows the main concept: the caps and inductors are placed on top of the IC. Because of the 150µm thickness of the PicoStar package, the overall thickness of the module is not much different from regular packaged solutions.

Figure 1: MicroSiP™ Module with IC and Passive Components

Not only can the passive components be stacked, but also the ICs on top of the PCB. In wearable applications such as smart watches and other activity-monitoring devices, with PicoStar, it may make sense to eventually put the charger and gas gauge or the charger and DC/DC converter in a MicroSiP module, as they are always needed.

The TPS82740A is an ultra-low-power DC/DC converter that utilizes the TI MicroSiP package and integrates all of the needed components with a load switch. The total solution size is only 2.3mm x 2.9mm, smaller than many QFN packaged ICs.

In addition, be sure to choose the passive components with the smallest footprint but make sure to verify the voltage and temperature de-rating meet the application requirements.

 Additional resources

• 3 Keys to Ultra-Low-Power in Wearable Designs
• Qi (WPC) compliant wireless charger for low power wearable applications
• MicroSiP power modules