Pragmatics of nano power radios

This is a brief note about high level concerns with nano power radios, solar powered without batteries.

Don’t rely on this, study it yourself, especially until I add proper links.  Some of it is just crude notes, even speculation.

Other References

A note at Mouser about ultra low power mcu design.

Context: nano power

The power supply:

  • provides low average current, around 1uA
  • has no large reserve
  • is is expected to provide zero current often (say every night)

For example:

  • solar power with a capacitor
  • no battery
  • indoor light
  • solar panel smaller than a credit card


  • radio is duty-cycled
  • a voltage monitor/power supervisor and load switch chip provides clean reset/boot
  • boot sequence must be short and monitor mcu Vcc
  • use a power budget for design
  • use synchronization algorithms
  • testing is hard
  • over voltage
  • energy harvesting

Duty-cycled radio

The radio is sleeping most of the time.  When sleeping, a low-power timer runs to wake the system.  The sleeping radio cannot wake the system when it receives.

Example: the system may sleep for a few seconds, and be awake (with radio on) for about a millisecond.  That is, the duty cycle is around 1000.

Voltage monitor/Load switch

A microprocessor (in a radio SoC) needs a fast-rising voltage to boot cleanly.  Otherwise it may enter a state where it consumes power without booting. (Fibrillating?)  It may be in that state for a long time.  The solution is to use an external voltage monitor aka power supervisor aka reset chip.  E.g. TPS3839 (ultra-low power of 150nA.)

You can’t just connect the voltage monitor to the reset line of the mcu.  Otherwise, the mcu will still consume power while its reset line is held in RESET state. (Between the time voltage is high enough for the voltage monitor to have active outputs say 0.6V and the time the voltage is high enough to run the mcu say 1.8V.)  An mcu may draw a fraction of a milliamp while held in reset.

So the voltage monitor drives a high-side load switch that switches power (Vcc or Vdd) to the mcu.  I use the TPS22860.  (You can switch ground i.e. low-side with a NMOS mosfet but it’s not so easy to design your own high-side switch.  You can’t switch the low-side of an mcu because many pins may leak to ground?)

Voltage monitor hysteresis and boot sequence

The voltage monitor asserts its Out (sometimes call Not Reset) at a certain threshold voltage but then unasserts if the voltage falls below the threshold a certain amount called the hysteresis.  While the mcu is booting, it must not use so much current that Vcc falls below the hysteresis.  The boot sequence typically does a bare minimum, then checks Vcc, and sleeps until Vcc is much beyond the the minimum.  That is, allowing time for the ‘challenged’ power supply to catch up and store a reserve.  Only then does the software proceed to use the radio, duty-cycled.

You could use a voltage monitor with higher hysteresis.  But they don’t seem to make them.  The hysteresis of the TPS3839 is only 0.05V.  You can play tricks with a diode/capacitor on the input of the voltage monitor to make it seem to have a higher hysteresis (to delay longer before un asserting.)  And there are application notes on the web about adding hysteresis to voltage monitors.  But they seem to apply to older voltage monitor designs, and don’t seem to apply to the ultra-low power TPS3839 (which samples Vcc.)

Also, you could design your own voltage monitor with more hysteresis.  For example, see the Nordic solar powered sensor beacon.  That uses a few mosfets to provide a 0.2V hysteresis (say booting at 2.4V and resetting at 2.2V).  Unfortunately, they don’t seem to have exactly documented how the design works.

Power Budget

A power budget calculates the average current of a system, given certain phases of certain durations, where each phase uses certain devices/peripherals.

Here the main phases are:

  • sleeping (say 1.5uA for 1 second)
  • radio and mcu on (say 6 mA for 1 milli second)

You can almost ignore any phases where only the mcu is active, it should be a small portion of your budget.

A discussion at Digikey.

Synchronization algorithms

These make your units wake at the same time, so they can communicate with each other.

A beacon is usually unsynchronized.  The thing that hears a beacon (e.g. a cell phone) has  enough power to listen a long time.  You also might not need to synchronize if you have a “gateway” that is always powered and listening.  (See Zigbee.)

This seems to still be a research topic, there is much literature to read and few open source code examples.

Testing is hard

With such a challenged, nanopower supply, testing is hard.  A bug may exhaust power so that the system brown out resets, losing information about what happened.

Most hardware debuggers make the target consume more power than the power supply can provide?  TI seems to have ultra-low power debugging tools, but I haven’t studied them.

You can implement fault/exception handlers that write to non-volatile flash so that you can subsequently connect to a debugger and read what happened.   Default handlers typically just infinite loop (which will brown out reset.)  Typical handlers will do a soft reset.  Unless your app makes a record or communicates that, you might not even know the system reset itself.

Agililent (formerly Hewlett-Packard) sells expensive instruments for monitoring power consumption.  These may tell you you when (in relation to other events) you are consuming more power than you expect, but not exactly why.

Over voltage

A solar cell is a current source, and provides a variable voltage.  Voc is voltage open circuit (when your capacitor is fully charge.)  It can exceed the Vmin of your radio (typically 3.6V.)

Voltage regulators (such as shunt regulators) that prevent that are themselves current wasters.

You can choose a solar panel whose Voc is less than the Vmin, but there are few choices in that range (Voc < 3.6V, Vope around 2.4V, for indoor light.)  Or you can require that your solar panel never be exposed to strong light.

I haven’t found a zener diode that would clamp the voltage to 3.6V, and not leak much, at such nano currents.

Energy Harvesting

This is another buzzword, but good to search on.  It often means: with a single coin cell battery.

Energy harvesting chips are available.  They solve some problems you might not have, such as over-voltage protection, or voltage boosting.

It often refers to other power sources such as heat or vibration.  Those power sources are usually even smaller than solar (light) power, but solar power is episodic (diurnal.)

Solar power in different setting differs by orders of magnitude.  Direct sun is ten times stronger than outdoor, blue-sky shade, which is ten times more than strong indoor light, which is ten timer more than  dim indoor light.



Framed Panels and Nested PCB’s using KiCad and OSHPark

This continues my earlier post.

About OSHPark

Here is an Element14 article about the OSHPark business model and company history.

Briefly, it says that OSHPark adds value for small makers by aggregating small boards from many customers into large boards that PCB manufacturers are equipped to make.  Some of added value is the software that runs the OSHPark business:  the web store, the software that aggregates many small PCB designs into a larger one, the software that understands and converts many different design file formats.

I appreciate their work and wish them continued success.

OSHPark and ad hoc panels (without frames)

A panel created according to my earlier post does not have any explicit support tabs or a frame.  I will call this an ‘ad hoc panel.’

OSHPark adds support tabs for you, between the PCB’s of your ad hoc panel.  (They also add support tabs on the outside of your panel, to the adjacent customer’s board or panel in the manufactured, huge, aggregate board.)

Unfortunately, OSHPark might also break apart your ad hoc panel at their convenience or need.  OSHPark breaks apart their aggregate, huge panels into customer’s boards.  While they are doing this, they don’t know which groups of boards are a customer’s ad hoc panel.  So OSHPark may break apart your ad hoc panel.

Just looking at the aggregate panel pictured in the above linked article, you can see that it might be difficult for the person separating customer’s boards NOT to break apart your ad hoc panel.

My point is: if you want your panel to stay together, you need to add a frame.  Otherwise, you are taking your chances.  The frame is what tells OSHPark not to break apart the boards.

Why create panels?

  • so you can save labor by stenciling or assembling boards in panels/batches
  • to save board costs by nesting odd-shaped boards

For the first purpose, the fact that OSHPark may break apart your ad hoc panel might defeat the purpose.  In my experience, making panels of 3 small boards, to stencil them by threes, for hand pick and place, it has not been a problem.  If OSHPark breaks apart your ad hoc panel in odd ways, you can always break them into individual units and stencil them by ones (using a corner of the same stencil for the whole panel.)

As I mentioned in an earlier post, OSHPark doesn’t always break your multiple board order into individual boards.  Sometimes you get ‘happenstance panels’ even if you did not order an ad hoc panel.  (Assuming your boards are much smaller than OSHPark cardboard shipping envelopes of about 5×7 inches.)

I am not really serious about volume production yet.  If you are, you should frame your panels.

Nesting odd-shaped boards into ad hoc panels

Say you have an L-shaped board.  OSHPark calculates the cost from the bounding rectangle.  That is, they will charge you for the empty space between the arms of the L.

If you nest two such L-shaped boards into an ad-hoc panel, the cost for the bounding rectangle of the panel will be less than twice the cost of the individual boards.

Other words for nesting are tiling or bin packing.

Tiling is partly how OSHPark subsidizes small makers, by fitting small boards into the wasted space of larger, odd-shaped boards.  If you create your own tiled, ad hoc panels, you save costs, but then someone else might be less subsidized.



Setting Up a Linux Development System for Embedded Wireless using TI LaunchpadXL-CC2650 EVM


A record of my learning experience.  Discusses general, high-level considerations. Gathers many links that I followed.


For advanced, C programmers who are new to TI’s tool chain for programming embedded devices.

Similar documents

CC26xx Family SW Quickstart Guide also covers this material.

This blog shows a similar process for an older EVM (SensorTag), but using Windows OS and CCS Desktop.

The Narrow Subject

Here I assume the CC2650 target (an mcu and radio system on a chip) but only discuss:

  • Bluetooth (the chip allows other protocol choices i.e. WiFi or Zigbee)
  • TI-RTOS (other RTOS choices might be various free OS’s)

This might apply to other TI chips such as CC13xx, CC2640, and other earlier chips.

The Broader Subject

Wireless networks, not necessarily IoT development.  My use case is not serious IoT: I don’t want to connect to the Internet and I don’t even want to talk to standard Bluetooth devices, just between two of my own.  I don’t even want Bluetooth protocol, it just happens to be what I studied first.


I could be wrong.  You should follow links to original sources.

Other target, IoT, and wireless network ecosystem choices

ARM mBed ecosystem also offers an online IDE, desktop development tools, an RTOS, and bluetooth stack.

The CC26xx target uses the ARM ISA.  You might be able to use the ARM ecosystem, but I think the bluetooth stack in the ARM ecosystem might not work on the CC26xx?  The CC26xx has two processors, a host (ARM M3) and a network (ARM M0) processor.  A Bluetooth stack should have an interface at the HAL layer between the upper layers of the BT stack and a network processor’s implementation of the lower layers.  I don’t know whether either the ARM bluetooth stack upper layers, or the TI network processor lower layers (in firmware on the M0), conform to any HAL interface standard.

(Note that TI also has much documentation on implementing “network processors”.  There, they are treating the CC26xx as a server for yet another processor, the application processor, say a powerful cpu of a desktop PC.)

ARM does not make chips (only the design IP for them).  You might consider whether using TI tools locks you into their chips, and whether using the ARM ecosystem would give you a choice of chips.

TI’s IDE Choices

CCS Cloud – “online IDE” or “online compiler”: browser and cloud based: few files stored or installed on your development system (host)

CCS Desktop – installed on your host computer, based on Eclipse IDE

Energia – (Arduino clone) does not support the CC26xx family target.

Dev System OS Choices

For CCS Cloud, shouldn’t matter, but it does: to burn to the EVM requires setting up communication via USB to the EVM, which is host OS dependent (drivers and permissions.)  CCS Cloud requires installation of TI Cloud Agent on your desktop.  All three major OS’s are supported.

For CCS Desktop, all three major OS’s are supported, but Windows seems to be favored.  E.g. installing the Bluetooth stack is biased: requires Wine on Linux.

TI’s instructions  for Building BLE Projects on Linux.  It acknowledges that TI does not officially support their BT stack on a Linux dev system (but they do support their IDE and RTOS.)


To develop, you need three components:

  • IDE (CCS Desktop or Cloud)
  • Bluetooth stack (or another wireless stack, i.e. library)

Using CCS Cloud, all three components come easy, automatically.

Using CCS Desktop, you must know the steps.

Installing CCS Cloud

Installation is minimal.  Search for “CCS Cloud Tools”.  Click on “CCS Cloud>Click to Start Developing”.  It will open in your browser.  When you first try to “Run” your target app, it will give you further instructions for installing:

  • a browser plugin
  • TICloudAgent

You must install TICloudAgent, and on Linux it depends on installing certain 32-bit libraries.  It’s web page seems out of date, it doesn’t show support for Ubuntu 16.4 or for this EVM (Launchpad.)

CCS Cloud is intended for starting programmers or small trials, i.e. for education and evangelism.  I don’t think the user base is large, yet.

I want to use it ( I have used Energia for small projects.)  But so far, I have had a fitful experience.  In other words, it seems somewhat fragile: requires refresh or restarting things.  Maybe slow.  But at least you can quickly experiment and learn the scope of your project (what might work, what else you need to learn.)

For example, at first ‘Run’ (burning to target) didn’t work for me, and after rebooting my dev system the next morning and plugging in the EVM after CCS Cloud was started, it did work.

For example, at first a project built successfully.  Then subsequent builds failed even though I had not changed a line of code.  The fix may be to delete a project and redownload it (using TI Resource Explorer.)  Maybe it is a consequence of changing between my two host computers.

Sometimes it fails to login (“too many logins”).  I guess there are limits on their servers?

The browser connection times out at inconvenient times (say every 30 minutes.)

Run (download to target)

“Failed to connect to target” : you don’t have the target plugged into a USB port on your desktop.

“Firmware update required” : the debugging interface half of the EVM board requires flashing.  This seems to be a warning, as download to the target seemed to proceed.

Installing CCS Desktop

Linux instructions.

A training video.

Additional notes

CCS Desktop is based on Eclipse IDE.  It is not a plugin that you can download from within Eclipse, but is downloaded and installed(?) separately (thats weird.)  If you are an Eclipse user, the overall look-and-feel is familiar, but specifics might not be.

The installer is 32-bit, but TI  says to use 64-bit Linux (that’s weird.)  You MUST follow the instructions for installing 32-bit library dependencies. (a 64-bit host will run 32-bit apps if the needed 32-bit libraries are also installed.)

The installer won’t run by double clicking it (because “>file *.run” shows it is 32-bit ELF?) but will run from the command line.  The installer is a .run instead of a .bin (thats weird?) but see this explanation of what a .run file is (essentially, an installation tool outside the approved Debian process.)

If you the installer starts but shows an error dialog “Failed to locate …libgcrypt…” you didn’t follow the instructions for installing that component.  You follow the link and click on “32-bit” (which points to ftp for a .deb file)  and expect to continue to install libgcrypt using “Ubuntu Software” installer app.

When the CCS Desktop installer runs, expect a wizard to run, that downloads and installs.

CCS Desktop: Installing TI-RTOS

You install TI-RTOS (development libraries) from within CCS.  Navigate to the TI App Center and choose “TI-RTOS for CC13xx and CC26xx”.

CCS Desktop: Installing Bluetooth Stack

TI’s instructions  for Building BLE Projects on Linux gives specifics for installing the BT stack on Linux using Wine (Windows emulator.)  Those instructions seem to be out-of-date.  I needed these changed instructions:

sudo apt-get install wine
sudo apt-get install winbind
(Download the Windows .exe installer.)
cd ~/Downloads
wine ble_cc26xx_setupwin32_2_01_00_44423.exe  (expect installer dialog)
cd ~/ti
cp -r ../.wine/drive_c/ti/simplelink/ . 

My changes to the instructions:

  1. Once you install the BLE SDK, I suppose it creates files in the proper place, and then you can uninstall Wine from your Linux computer?
  2. When I tried “>wine ble….exe”  it yielded errors about “ntlm” and needing package “winbind.”  And failed to create ~/<me>/.wine/drive_c/ti  (where it should be installing files.)  So I also installed package winbind.
  3. The installer did not seem to create .wine/drive_c/Program Files(x86\)/Texas Instruments/Boundary/  so I omitted the step of copying it.

(I haven’t successfully built a project yet.)

CCS Desktop: Importing Example Projects

I tried the TI Resource Explorer and did not have much luck finding

TI’s instructions  for Building BLE Projects on Linux also gives instructions for importing example projects.

CCS Desktop: Tweaking Example Projects

The instructions there for changing the linked resources (paths, capitalization of fileNames, and fileName wording) are slightly dated but generally accurate: you will need to use the principle and tweak the exact changes yourself.  For example, the filename “RF.c” seems to have changed in the latest release of BLE SDK.

If you get:

error: can't create session manager: can't find a JVM;
 the environment variable 'XDCTOOLS_JAVA_HOME' is set,
 but does not appear to be a directory containing a 64-bit
 Java Runtime Environment

Then see this post on TI Forum .


What are Images?

For the CC26xx, burning the target comprises two steps:

  • the app
  • the bluetooth stack

These are two different projects in the IDE.

TI calls them “images”.  I suppose that means they are loaded in different addresses of target ROM, and that the app on the target knows where to find the BT stack.  You only need to burn the BT stack once (unless it changes upstream, a new version.)

What are the symptoms of failing to burn both?  The app and not the BT stack:  does the app complain somehow?  The BT stack and not the app: nothing whatsoever happens, there is no app to boot?

Test Projects, CCS Cloud

How to use TI’s example projects to test your dev system.  These were written while I was using CCS Cloud; they might not apply to CCS Desktop.

Project Zero for CC2650

A demo app to burn onto your SimpleLink LaunchPad.   Essentially it sets up the Launchpad as a BT peripheral that a central device (a phone, etc.) can poll (see advertisements), connect to, and change attributes (to blink LED’s.)    This describes the demonstration, what a user sees.

As near as I can tell, this is NOT the app that is burned into a LaunchPadXL-CC2650 out of the box.  At that time, pushing the upper right button on the LaunchPad causes it to BT advertise, and for the green LED to blink.

This can be a test case for your development system.  If you successfully build and burn it, it should behave as described, talking to a BT scanner on another device.  Unfortunately, to see the results you need to use some of the free BT scanner apps, you need another BTLE enabled device, Android 4.3 or greater, or a recent iPhone or iPad that supports BT Low Energy.


This project prints “debug messages” once per second for a few seconds. It doesn’t use the radio.  It is intended to teach how to code semaphores etc.

CCS Cloud:  When you click the Debug icon, expect a dialog to open (the dialog that shows progress).  It should say, in order, paraphrased:

  • Building…
  • Loading…
  • Initializing…

The red/green led on the top half of the EVM should blink as the program is burned.

CCS Cloud: Then the dialog goes away and the debug panels of the IDE show new information, and a marker appears across from “main()” in the panel that shows the code.  The debugger is waiting for you to start the app.

Press the “Resume” icon in the debugger panel (looks like the standard “Play/Pause” icon on VCR’s).  Expect the program to run and print some messages into the Debug tab of the panel across the bottom of the IDE.  The final message should be “bigTime ended.”


This example project is configured for another EVM.  When you try to “Run” it on the LaunchpadXL-CC2650 EVM, you get the error “….Failed to connect….”.

To fix it, click right mouse button on the project in the Project Explorer Pane of CCS Cloud.  Expect a menu to pop up.  Choose “Project Properties”.   Expect a dialog to appear.  In the “General” section, in the “Connection” textbox, click.  Expect a pulldown menu to appear.  Choose “XDS110” (the type of interface on the upper half of this EVM.)  Choose OK and build again.

Repeat for the other half of the project, the …App… versus the ….Stack….

Other Notes

It seems like a few “Run” errors in red while burning, such as “Failed Device Reset”, are ~normal~ and that CCS Cloud retries and eventually succeeds.

Sometimes Ubuntu displays “You have just opened  a digital audo device” dialog meaning it has seen the Launchpad on the USB port somehow.  Choose “Do nothing” and “Do this always.”  Maybe it interferes with CCS Cloud if you don’t?

Cloud IDE for programming

About this post

The subject is software development environments that are easy to set up and use from anywhere.

This post’s quality is low:

  • written quickly
  • more questions than answers
  • from my limited experience, not exhaustive
  • it discusses programming embedded micro controllers, not programming in general

The problem

You want:

  • to minimize effort administering your development environment, and maximize time spent writing software (SetupEase)
  • to work from any physical location (Mobility)
  • to use version control (Versioning)
  • not to lose work (Backup)
  • to share (OpenSource)

Some software developers work in a single development environment in a single location.  Others may switch between many environments and many locations.  For example, software developers for embedded systems might switch environments for each brand of microprocessor they use.  They may develop at home and at work.

The State of the Art

AFAIK, there is not currently a development environment that gives you all of the above.

Solution Pieces

  • Github
  • Dropbox
  • Containers or virtual machines
  • IDE’s in the cloud


Github the software provides you Versioning and the website gives you some Mobility.  But it only gives you Mobility for your source and some parts of your development environment ( such as makefiles), not for your total development environment (such as what compiler you are using.)  And the Mobility is clunky, you can’t work in your open master repository, you must work in a clone and remember to push to origin master after each work session, so that your work will be available tomorrow from another location.


Dropbox gives you Mobility for your source files: anywhere you work, your files will be automatically synchronized (with slight lags.)  And you can put Github clones inside Dropbox.  But you still don’t have Mobility for your complete development environment, since your IDE or compiler is installed locally, not in Dropbox.


Containers or virtual machines give you SetupEase.  Someone else can install and configure your development environment, and you download and use the whole.  For example, a development environment for open source OS Mynewt is available in a container.

But containers don’t give you Mobility.  You must set up distinct (but identical) container instances in every location.  Any files you create in a container instance, and any modifications to the development environment, are local to the container instance.   Your container could include Dropbox having a Github clone, but you still must remember to push after each session, and that might not mobilize any modifications to the environment in the container instance.

IDE’s In the Cloud

Also known as “IDE as service.”  Here, you run your development environment in a browser.  A server:

  • stores your source files
  • stores your environment
  • does all the compilation
  • runs and debugs your app (with help from an agent to the target device)

An example is Texas Instrument’s CCS Cloud.  My knowledge is limited.  AFAIK it give you SetupEase, Mobility, and Backup.  It doesn’t seem to give you Versioning and Share.  It seems to let you clone Github repositories, but not commit in the clone, or push to the origin.

TI admits in the FAQ for CCS Cloud that for advanced work you probably will need to use CCS on the desktop.  In other words, CCS Cloud is only for experimenting or trials.

CCS Cloud does let you download any files from it, so you could use a manual process in which after every session, you download, commit, and push any files you have changed in CCS Cloud to your master Github repository in Dropbox.

Other examples might be “Particle online” and “mbed online.”  (I don’t know these.)


EmbeddedWeekly  blogs a little about this subject.  I read that before writing this post.


Using Energia with EZ430-F2013 LaunchPad on Linux

About this post

This pulls together various other posts and links.  Audience is someone who is new to embedded microprocessors (MCU) but otherwise  familiar with software development.


Energia is an IDE.  It is a port of the Arduino IDE (swapping out Atmel AVR mcu for the TI MSP430 mcu.)  In other words, it is the Wiring development platform, but specialized for a different embedded mcu.

The IDE lets you edit programs and write them (flash them) to a target board.  This particular IDE does not have integrated debugging.

MSP430 is a family of ultra low power microprocessors from TI.  See the FAQ.

The EZ430-F2013  is one model of development kit for the MSP430.  It includes:

  • an FET (flash emulation tool) hardware
  • a detachable target board (detachable is unusual, most have pluggable IC’s)
  • other IDE software tools on a CD

A FET is an adaptor from your development PC to the target board.  Adaptor: it has a USB connector on one end, and a connector to the target board on the other end.   It adapts from USB serial to Spy Bi Wire serial.  This particular FET and connected target board are in a USB stick form factor or package.  With the IDE, it lets you:

  • flash the memory of the target board
  • debug the target board using a version of gdb talking JTAG/SBW to the target

The target board is a small PCB having:

  • the MSP430F2013 model mcu
  • one LED
  • two rows of breakout pins for you to add circuitry
  • a four-pin connector to the FET.

You can also buy a  EZ430-F2012 (part number), which is a package of three compatible target boards, except they have the MSP430F2012 (model number) mcu.

Why this combination?

Pros of all TI’s other development kits:

  • cheap, TI seems to be subsidizing
  • target mcu is ultra low power, TI seems to be emphasizing low power for the IOT, and has many other low power chips
  • target mcu is small in area

Pros of this development kit:

  • the target mcu is VERY small (a few tens of mm squared)
  • you could use the detachable target board as a component (although it has an odd half-moon shape).  It’s the size of your thumbnail.

Pros of Energia:

  • it has an approachable language (a simple subset of C++)
  • it has many built-in libraries
  • you can also program in C++


  • its basic, low-end, and older
  • the target mcu has too small 2K flash memory for large programs
  • the target mcu has few IO pins
  • the target mcu has few modules (peripherals): only an ADC, and a few timers
  • its not very popular, most professionals use other development kits, other IDE’s, and other programming languages (assembler or C)
  • several IDE functions use the command line (debugging)
  • it flashes using SBW, which is slower than a full JTAG programmer
  • it doesn’t interface the serial port of the target board (to let you print)

For learning, its great.  But consider whether the target board will meet the needs of your application.

Install Energia

Download Energia   On Linux, expect a .tgz file to download.

Unarchive it.  Expect it to create a directory “energia….” in your home directory.

Follow the instructions for installation on that page (except for the udev.)

Setting up the udev

On Linux you must set up a UDEV.  If not, you may later see an error message:

ti3410: warning: can't detach kernel driver: Operation not permitted

which means, in Linux, you don’t have permission to write to the USB device.

However, the given instructions don’t work. ( The USB stick has ID  0451:f430  which is different from any listed in the downloadable udev rules.)

Instead use an editor to create a file named 46-TI_launchpad.rules in this directory location:

having this contents:
ATTRS{idVendor}=="0451", ATTRS{idProduct}=="f430", MODE="0660", GROUP="foo"

where ‘foo’ is the group that you belong to.  You need to be superuser, so use >sudo nano or >sudo vi to create the file.  What this does: at boot time, the OS gives permission for anyone in the group to read and write the OS device file (/dev/tty?).

Restart your computer.

Patch Energia for the MSP430F2012 or 2013

Energia doesn’t properly support this development kit (there are patches waiting to be approved and merged on GitHub.) But you can fix that by:

Edit ~/ener*/hardware/msp430/boards.txt.

Copy and paste the first block of text.

In the copy, change:

‘r2500’ to ‘uif’ after the word ‘protocol’.

‘msp430g2331’ to ‘msp430f2012’ or ‘msp430f2013’ everywhere in the copied block only

If you omit this step, when uploading you may see the error message:

usbutil: unable to find a device matching 0451:f432

Start Energia

Open a terminal.

>cd ~/energ*

Expect a GUI application to start.  Stuff will still scroll in your terminal window, but the same stuff appears in the bottom pane of the GUI.

Swapping target boards

You can pry the plastic USB case apart with a small blade or screwdriver.   It is split down the middle.  It has friction fit, plastic pins.  Pry one half straight up.   Then the target board pulls off the end.  You probably should saw the end off the plastic case so you can handle the unit but more easily change the target board (if you intend to flash more than one target board.)

If you intend to use the ADC of the F2012 mcu, swap the target board out first thing.  The F2013 has a different ADC (a SMA_16 16-bit) versus the F2012’s ADC10 (10-bit).  The ADC registers are at different addresses.  The MSP430 architecture (ISA) does NOT generate exceptions (trap) for all illegal addresses or illegal opcodes!  Instead, it quietly lets you read and write some addresses (device registers) for which there is no device.  In other words, if your program that uses the ADC doesn’t work as expected, maybe you are including the .h file for a different target and addressing the wrong ADC.  The ISA is subject to change between models, read the datasheets carefully.

Plugin your EZ430-F2013 USB stick

Plugin your EZ430 USB stick.  Expect it’s LED to start blinking.  (When powered up, it resets, and the factory programmed “blink” program starts running.)  The LED may never blink again, depending on your programming skills.

Test the Blink program

Choose File>Examples>Basics>Blink.  Expect a new program to load into the IDE.  This program is compatible with the target board (which has one green LED on Port1.Bit0).

Choose Tools>Board.  Expect to see a list of boards.  Select ‘LaunchPad w/ msp430f2012 (1MHz)’.  (Or …f2013)  Expect the item becomes selected, but nothing else.

Choose File>Upload.  Expect output from the compiler and an upload result message.

If it fails, try again.  Inexplicably, sometimes it fails to upload, with this:

fet: FET returned error code 4 (Could not find device or device not supported)
fet: identify failed

When it works, expect:

ti3410: warning: can't detach kernel driver: No data available
Device: MSP430F20x2
fet: FET returned NAK
warning: device does not support power profiling
Done, 788 bytes total

Note that here I have already swapped out the F2013 target board for a F2012.

Expect your USB stick blinking again.

Now you can go on to write other programs.

Using the serial port

The menu Tools>Serial Port remains greyed out (disabled) and will remain so.   The FET has two pins toward the target board that are not connected to the target board.  Thus the FET can not read the serial port of the target board, and your program will not be able to print to the serial port and expect it to appear on the IDE.

The target board does have breakout holes for the TXD and RXD pins of the target mcu.  You might be able to jumper them to the FET.

Probably the designers of the target board decided that since memory on the target board is limited, it would not hold a library implementing serial IO (in addition to other program code.)


You can use gdb on a command line to debug the target device remotely (the target supports JTAG so this is possible) as described by an Energia dev.

Energia invokes the mspgcc compiler with optimization.  You might need to alter you program (remove inlining) to insure that functions appear as symbols.

From an obscure post by Ingo:

mspdebug does not use debug symbols (the ones you enable with the -g compiler switch), just the plain symbol names that are also used for linking. However, in the ELF format, each symbol has a type field, and mspdebug only uses symbols of certain types (object, function, etc.). You can display the symbol table of an ELF object with “readelf –syms file.o”. Symbols whose type is listed as NOTYPE will be ignored by mspdebug.

An example of what you can do (see gdb for more):

  • set breakpoints (>break foo)
  • print object (variable) values (>print foo),
  • ctl-C interrupt the target and show the backtrace (>bt)

Programming in C++

You don’t need to use Wiring.  You can program in C++, C, or even assembly language.  A short blog.

Not using Wiring saves much program memory. For example, the  Stepper library with a few other Wiring libraries would not fit into the 2k memory.  But recoding relevant parts in C++ did fit.

To code in C++/C you might need to understand:

  • the gcc compiler variant that Energia invokes
  • the intrinsics to assembler that the compiler supports (section 6.8 of the above)
  • interrupt handling and the ‘vector’ pragma (section 6.7)
  • the runtime environment (section 6.  It sets up the stack, etc.)
  • the include file that defines target addresses, constants, and other language constructs (in this case “#include msp430f2012.h” or …f2013.h )  which are found at ~/ener*/hardware/tools/msp430/msp430/include/

Typical code flow

See TI’s Application Report MSP430 Software Coding Techniques.

But adjust to fit.  For low power, you will need to use interrupts, but you don’t need to use flags, you can have a state machine and enter low power mode from many states.

Development Kit User’s Guide

The development kit User’s Guide  :

  • includes a schematic
  • tells how to use the other IDE’s, but not Energia
  • gives instructions for opening the case

Using the FET for other targets

You can design your production PCB with a matching four-pin connector, and program/debug it using the FET portion of the development kit.  The four pin connector has Vcc, Vss, and two SBW signal lines.

You might be able to use the FET with a different target.  I haven’t tried it yet.  I don’t know of any impediments.  My opinion is that TI is downplaying the ability of the FET.  The User’s Guide says it will work with other devices in the ‘MSP430F20xx’ family.  (I am hoping it works with devices in the MSP430FRxxxx family.)

Ultra Low Power Hardware and Coding

Ultra low means: less than about 1uA average current.  That gives tens of years on a coin cell battery.  Or lets you use energy harvesting.

The mcu when active draws tens or hundreds of uA.  Thus to achieve ultra low power, the mcu must be sleeping (in a low power mode) much of the time, and use interrupts to wake up.

If you have external interrupts, the lowest power mode is LPM4 (the mcu and peripherals off, but external interrupts will wake.)  Called ‘Off Mode with RAM Retention’.  Draws 0.1uA.

If you don’t have external interrupts, sleeping is low power mode LPM3 with a timer peripheral running in the mcu to interrupt and wake the cpu up.  In this mode (called standby), the MSP430F201x draws 0.5uA.

If you need accurate time, you can implement a 32-bit  RTC in software, as described by a TI Application Report, using an external clock crystal (loses 1 second per month) to the 16-bit timer (which wakes up the system every few seconds to tick the 32-bit software RTC.)

If you don’t need accurate time, you can use the VLO portion of the clock module as the clock source for your timer.  That is the lowest power standby mode.  See the datasheet for the MSP430201x.

If you need even lower average power, you can switch power Vcc to the mcu, using an external chip such as the TPL5010 Nano Timer which draws only 35nA (0.035uA.)  But then you might lose any data saved in volatile memory (RAM) such as the context of your application (and the application must restart.)

TI makes MSP430FRxxxx‘s having FRAM and using as little as 0.35uA current in standby mode.  Some models have a 32-bit RTC implemented in hardware.  Check the datasheets, its not clear to me for which applications this family saves power.   The smallest member/package for this family has 24 pins, compared to the 14 pins of the F2012, and is 16mm square, about the same area.  (These packages are near the limits of what you can solder at home.)

More about JTAG and Spy By Wire (SBW)

See JTAG and SBW. JTAG uses many signal wires, SBW only two.  SBW is slower.

Also see section 28 Embedded Emulation Module of the MSP430x2xx Family User’s Guide.

In short, it means that you can use a software debugger (similar to gdb) to remotely debug a program on an  embedded MCU while in-circuit (soldered to a prototype or production  PCB) using only two wires to connect from the development machine to the PCB.  That is, you don’t need to simulate, you can debug under actual hardware conditions.  If the hardware timing conditions are not so severe that you need a more powerful solution.




Panelizing a PCB in KiCad


This is a tutorial for panelizing (producing a panel comprising replicates of a small PCB) in KiCad.

The goal is a separate design, a panel comprising a horizontal row of my boards separated by the 100 mil routing width that my fab uses.  The purpose is a panel that is an easily handled batch during assembly  (solder paste stenciling, placing SMD components, and moving to the reflow oven.)

This is specialized:

  1. uses KiCad
  2. replicates one small board,
  3. I don’t design internal support tabs
  4. I don’t design a frame around the replicates
  5. it’s a manual operation using fiducials and block copying

In this example, I assume the fab is OHSPark:

  1. requires 100 mil separation
  2. they will add internal and external support tabs
  3. they don’t require a frame (since I will accept if the panels break apart in shipping.)

Internal support tabs hold the panel together.  External support tabs hold my panel in the larger panel that the fab makes.

There might be other ways to do this.  At one time there existed Python scripts to automate this.

Overview of the process

Use fiducials (layer alignment targets.)  Create an initial fiducial pair at grid size 100 mils. Use a minimum grid size( 0.01mm) and nudging with the arrow keys when aligning copies.  Use block copy to copy both the PCB and nearby fiducials.

Here is a picture of the nearly finished result:



Before you start

You have a finished existing board design.  (Any changes to it will not automatically flow into your panel design.  You will need to redo your panel if the child PCB changes.)

Your zone outlines and all other components are within your PCB edge outline ( simplifies block copy.)

The line width of your board outline (in Edge.Cuts layer) is small (say the default of 0.15 mm).  This matches the line width of fiducials, making it easier to see when your board outline is corner aligned to a fiducial.  (Your fab cuts to the center of the graphic line defining the edge.)

Your existing board design need not be aligned to any particular grid size.  Your board size need not be a multiple of any particular grid size.  (Although it might be easier if your board is aligned to a 100 mil grid and a multiple of 100 mils in size.)

The process

Starting PCBNew app

Click on the PCBNew icon (in your desktop, launcher, or file browser.)  Expect a window showing an empty PCB design.  (Note you can’t start PCBNew from within your existing project, since then it opens your existing design, that you should keep separate.)

Import your existing PCB into the empty panel design

Choose File>Append Board.  Expect a file browser to open.

Select the foo.kicad_pcb file of your existing PCB design and choose the OK button.  Expect a floating view of your existing PCB design.

Click in the sheet anywhere to place the first copy of your PCB.

Add two fiducials on a 100 mil grid

Choose ‘100 mils’ from the grid combobox in the toolbar.  Expect the grid to change.

Select the fiducial tool by clicking in the “Add layer alignment target” icon in the right toolbar.  Expect the cursor to change to a pencil icon.  Click in the sheet near the upper right corner of the PCB copy.  Expect a fiducial symbol placed on the sheet, snapped to the nearest grid point. (It is in the Edge.Cuts layer.)

Repeat, placing another fiducial 100 mils to the right of the first fiducial.

Align the first replicate’s upper right corner to the left fiducial

Choose ‘0.01 mils’ from the grid combobox in the toolbar.

Zoom in so you can see precise alignment.

Choose the pointer tool.

Drag out a rect around the PCB.  Expect a “Block Operation” dialog to open.  Choose the OK button.  Expect an image of the PCB to follow the cursor (an the original to remain visible.)

Align upper right of the first replicate to the fiducial’s cross, and click the LMB (left mouse button.) Expect the PCB to be placed.

Delete the left fiducial

Using the pointer tool, click the RMB (right mouse button) on the left fiducial.  Expect a context menu to pop up.  Choose “Delete Target.”

Block copy the PCB and fiducial

Using the pointer tool, drag out a rect around the first PCB replicate and the fiducial to its right. Expect a “Block Operation” dialog to open.  Choose the OK button.  Expect an image of the PCB  and fiducial to follow the cursor, but for the original also to be visible.

Align upper left of the dragged copy to the  fiducial of the original.  Click the RMB ( right! mouse button.) Expect a context menu to pop up.  Choose “Copy Block”.  Expect a second replicate of your PCB to be placed.

(Also expect horizontal rat’s nest lines to appear, connecting nets in the left copy to nets in the right copy.  You can ignore those, or “Hide board ratsnest”.)

Note that unless your board is a multiple of 100 mils wide, the newly copied fiducial won’t be on a 100 mils grid.


Delete the left fiducial and again copy the right PCB ( or many of them) and the fiducial to its right.

You might make a few more copies.  You should not make more copies than will fit in the larger panels used in the fab.

Delete  fiducials

KiCad puts fiducials in the Edge.Cuts layer.  Some fabs (OSHPark) might deal with this as you expect, while other fabs may route out (drill) the fiducials!  A post on the KiCad forums discusses this.

You should probably delete the fiducials, so you don’t worry about how your fab interprets them.

Save As

Choose File>Save As and so forth to save the panel design.  You probably should create a separate folder to put it in.  In that separate folder, you can also put the Gerbers for the panel.

(If you choose File>Save you might get an error message, probably because on some platforms, KiCad attempts to save in the locked directory of the application file.)

Finishing up

You might want to run the DRC.  It should still work.

You now can plot Gerbers and generate a drill file.  (It seems like you must choose an absolute path for the drill file, else KiCad attempts to write it in a locked app directory?)

One advantage of a panel such as this: the solder mask Gerber layer will precisely align with the boards of the panel.  (You don’t need to panelize a solder paste stencil like you might for a happenstance panelization that the fab might create and deliver to you.)


I don’t think you need to be super accurate.  When I do it, the alignment seems a few pixels off, less than a mil off.  Use the arrow keys while dragging to nudge your PCB a few pixels.

Even if the distance between your PCB copies is a few mils off, the fab actually uses a router bit that is smaller than 100 mils (it cuts on the way into a slot, moves over, and cuts on the way out.)

If the outer edges of your panel are a few mils off, your panel will still probably fit in the jig for your solder paste stencil.

In other words, don’t worry about a few mils, because your home hobbyist processes don’t require that accuracy.


I haven’t tested this with OSHPark yet.




Fundamentals of mobile, indoor energy harvesting

This is a quick list of essential facts, without links or references.  I learned these working on my application: solar powered Calder mobiles (trademarked Solabiles.)

Energy harvesting:

  • not connected to the power grid
  • years, or forever, between any battery changes
  • harvests ambient or waste energy
  • harvests light, heat, or vibration

Light has the most energy, for mobile or ‘anywhere’ harvesting.  Only constrained points, such as on a hot surface (a body?) or on a vibrating motor, might have more harvestable energy.

Energy harvested is proportional to the light level.

Light levels indoors are exponentially smaller than outdoors.  Roughly:

  • full sun: 100k lux
  • shade but with full sky exposure: 10k lux
  • bright indoor: 1k lux
  • average home lighting: 100 lux

The lighting within a room can vary exponentially:

  • near a south facing window, overcast winter day: 1k lux
  • other side of the room: <100 lux

Lighting in a room can depend on the direction windows face:

  • near a south facing window, overcast winter day: 1k lux
  • near a north facing window, overcast winter day: 100 lux
  • other side of the north room: 10 lux

The human eye and brain hides the above facts.  It doesn’t seem that the lighting is so different in a room, but a luxometer tells the story.

Solar cells produce energy proportional to their area.

Solar cell technology probably is not going to get much better soon.  They might double in efficiency, but they probably won’t reach 100% efficiency.  You must make improvements elsewhere.

At low light levels (indoors), amorphous silicon solar cells produce more energy than crystalline silicon solar cells.

Solar cells and panels produce the most power at their maximum power point (see MPPT.)  In other words, when they ‘see into a load’ of the voltage of their MPP.  (I don’t really understand why, and the best water analogy I can come up with is:  a very thin sheet of water is a lot of water but has little pressure, and can’t do much useful work.)

You don’t necessarily need an “energy harvesting” chip.  They provide:

  • voltage boosting
  • MPPT
  • battery management (using a battery might bring its own set of problems to a design.)

If you don’t need either of those, you do your own MPPT: insure the voltage the solar cell sees remains near the MPP (whenever conditions allow.)

Ordinary capacitors, supercapacitors, and batteries use different technologies that each bring their own design problems.

At very low light levels, say <50 lux, the leakage of circuits is important to a design.  See my next post.