Texas Instruments Educational Boosterpack II - Review

Table of contents

RoadTest: Texas Instruments Educational Boosterpack II

Author: satyavrat

Creation date:

Evaluation Type: Independent Products

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: The Educational Booster Pack II is a unique product, the closest competitor in that sense would be the Seed Studio Expansion Shield for the TI Launchpad Series

What were the biggest problems encountered?: The board I received was faulty, and hence I couldn't upload my code due to Flash Erase errors. After a lot of snooping around, I managed to run it on Code Composer Studio, but it still isn't being uploaded over Energia.

Detailed Review:

The MSP 432 is kind of like the flagship model of the Texas Instruments series of LaunchPads. It's their most recent offering and has something called Energy Trace technology. This allows the developer to get visual feedback regarding how much power the board is using at any given moment or within any function. This, coupled with Texas Instrument's ULP (Ultra Low Power) optimization standards built into Code Composer Studio, makes development of embedded applications on the MSP 432 platform a very energy efficient affair.


It has an inbuilt Stellaris debugger, which uses the XDS 110 drivers, so that an external debugger is not necessary, though the MSP 432 does have provisions for one.


Getting started with it, though, is something else. Apparently, I received faulty hardware, and it keeps throwing an error saying "Unkown Error : Mass Erase Failed".  I don't know why it's happening, but I do know that the Flash memory is being erased and therefore, new programs cannot be downloaded. I found a workaround for this on the TI websites, which suggested the following steps.


UPDATE : TI has kindly agreed to replace my faulty board, and a few of the functionalities that I haven't been able to test right now will be done in the near future.





  • Factory Reset your board as shown in the quick start guide.
  • Power cycle the board
  • Open Code Composer Studio
  • Go to Project > Properties > Debug > MSP432 Settings > Erase main and information memory
  • Build the project
  • Debug and Download the project to your board


This procedure results in the board being able to download and run the code, yet the error persists. This partially solves my problem, as now I can write my own code and burn it onto the board, but I am restricted to using Code Composer Studio, and not Energia, which is my preferred IDE for prototyping. However, there is a provision in higher versions of Code Composer to be able to import Energia projects or write code in an Energia format within the Code Composer environment. That's a relief because it saves me a lot of time, especially for testing modules. That said, the MSP 432 itself is a pretty straightforward board, with a Green LED telling you it's powered on, a Red LED telling you when it's debugging, and an RGB LED for you to play with. Input wise, it has two push button switches, which allow you to give a digital input to the board.


For future reference, the corresponding ports are;
  • Pushbutton S1     : P1.1
  • Pushbutton S2     : P1.4
  • Red LED              : P1.0
  • RGB LED Red     : P2.0
  • RGB LED Blue    : P2.1
  • RGB LED Green : P2.2




Code Composer Studio automatically generates the template for coding the MSP 432 when you select it as the target device by creating target configurations and building and debugging options autonomously, so all you have to do is write the code for your procedure. To turn on the LED, the following code is written.


#include "msp.h"

void main(void)
    WDTCTL = WDTPW | WDTHOLD;          // Stop watchdog timer
    P2DIR = 0xFF;                      // Initialize PORT 2 as output

    while(1)                           // Infinite loop
    P2OUT = 0x04;                      // Turn on Blue LED P2 = 0b0000 0100



Testing the Educational Booster Pack Mk II


The Educational Booster Pack Mk II, is an add-on board available for Texas Instruments based launchpads. It sits neatly on top of the signature 4 colums of pins that Texas Instruments has made as standard on all their LaunchPad devices. The Mk II is aimed at younger audiences and newer enthusiasts with minimal exposure to embedded systems. It is loaded with a fleet of bells and whistles and some unique features as well.


The Mk II, like its namesake from Iron Man, boasts of a huge number of sensors and actuators to help a maker prototype their application or even get introduced to the concept of a controlled embedded system. As it is an add-on to the TI LaunchPad series, the LaunchPad interacts with the Mk II over direct connections and sends or receives data to its peripherals.


The Mk II has a strong code support within the Energia IDE, which is an Arduino IDE clone meant for Texas Instruments devices.


The Mk II has on board the following peripherals;

  • TFT Color LCD
  • Microphone
  • 2-Axis Joystick with Push-Button
  • LCD Backlight Select
  • Light Sensor
  • Temperature Sensor
  • Servo Controller
  • 3-Axis Accelerometer
  • Push Buttons
  • Buzzer
  • Alligator Clip Connectors


I will be updating this post as and when I use the different functionalities of the Mk II, as of now, I've run preliminary demos for the following peripherals.
  1. RGB LED : [Pins 37,38,39]

    The RGB LED is a simple enough affair, with three pins from the LaunchPad powering the constituent coloured LEDs. The different intensities of these colours, which can be provided using an 8-bit analog value as the output, can result in any colour within the RGB spectrum.

    analogWrite(ledRed, *red LED intensity as 8-bit int*);
    analogWrite(ledBlue, *blue LED intensity as 8-bit int*);
    analogWrite(ledGreen, *green LED intensity as 8-bit int*);

  2. Joystick : [Pins 2,6,5]

    The Joystick has two separate analog pins to capture the horizontal and vertical yaw and pitch of the joystick and return an integral value between 0 and 4096. This 12-bit resolution enables precise location sensing of the joystick, resulting in a smooth motion of whatever it might be controlling. It also has one digital pin dedicated to the integrated push button for selection.

    int xst = analogRead(*Joystick X coordinate pin*);
    int yst = analogRead(*Joystick Y coordinate pin*);
    int joystickYState = map(yst, 0, 4096, 0, 255);

  3. Microphone : [Pin 6]

    The microphone is used mainly as a noise detector, however, with intelligent processing it just may hold the promise of speech recognition via its powerful 12-bit analog to digital converter. It can detect minute variations in sound, as it showed considerable change when I switched my fan on and off.

    int micval = analogRead(mic);
    int value = map(micval,0,4096,0,255);

  4. Buzzer : [Pin 40]

    This is a simple output device which produces a sound when supplied with voltage. However, when provided an analog value as input, one can change the intensity of the sound, and also by providing pulses of appropriate frequency, one can generate tones on it as well.

    analogWrite(buzzer, 128);


The accelerometer and LCD sketch doesn't seem to work on the CCS port of Energia, so I'll have to wait for the new Launchpad to arrive so that I can test it.





Many thanks to Texas Instruments for their timely assistance, else it would have been another board catching dust in my drawer, and I'd have missed out on a lot of fun! As stated before, the LCD and Accelerometer modules did not seem to work within Code Composer, however, both examples worked great on the new board, so I decided to write a little script on my own which displays the current tilt value for all 3 axes on the LCD.



I finally got a chance to play with the accelerometer and the LCD, the components that I had missed so much!


The accelerometer operates over a 10-bit ADC, giving very precise counts for tilts. Even the slight trembling of my hands wasn't left undetected. It is a robust 3-axis affair, allowing motion in all dimensions to be detected. The code for the same was very straightforward and could be understood immediately from the example.


The LCD though, was another matter. I still maintain that the LCD examples are far too convoluted to be of any use to a greenhorn embedded designer, because they've crammed almost all the functionality, save the image display into one example. And although it seemed intimidating at first, it became apparent after a while that the code in itself is not that difficult to understand. Implementing a custom variant, though is a bit nerve wracking. So, I went with the easiest of the lot, text display, and showed the readings for the accelerometer on the LCD.


const int xpin = 23;

const int ypin = 24;                

const int zpin = 25;

const int mic = 6;

const int jhor = 2;

const int jver = 26;




void setup()




    Serial.println("*** LCD_protocol");

    Serial.println("(All times in ms)");


#if defined(PicasoSPE)






#if defined(PicasoSPE)

    myScreen.setSpeed((uint32_t) 38400);

    mySerial.begin((uint32_t) 38400);

    Serial.println((uint32_t) 38400, DEC);












void loop()


  myScreen.gText(4, 4,"Satyavrat Wagle", redColour);

  myScreen.gText(4, 14,"____________________________", redColour);

  myScreen.gText(4, 34, "X-Tilt is "+String((int) analogRead(xpin)), whiteColour);

  myScreen.gText(4, 44,"Y-Tilt is "+String((int) analogRead(ypin)), whiteColour);

  myScreen.gText(4, 54,"Z-Tilt is "+String((int) analogRead(zpin)), whiteColour);








Using the Booster Pack for an MQTT Based Sensor Node


The application I had in mind was to use the Booster Pack on top of a CC 3200 WiFi board that I already had, in order to connect it to a local MQTT broker as well as a cloud analytics service, namely Thingspeak.com . MQTT is an upcoming IoT protocol that allows for lightweight messaging between hardware constrained devices. A couple of sweet features include the ability to segregate sensor readings into categories within the protocol itself, thus rendering any database management systems unnecessary for a purely sensor oriented node. Another feature is the ability to subscribe to a certain topic, which updates its data according to the sensor it is connected to.




I plan to use the prebuilt Energia sketch for the CC 3200 as the base, and upload the accelerometer and ambient light data to the cloud, however, there are some issues that I'm facing right now. Primarily that the ADC reference for the CC 3200 is 1.5V, which doesn't match up to the Booster Pack's 3.3V. So I'll be needing a voltage divider circuit to make it work, as shown in the ZumoRemote Project.


I'll update this as soon.





The product itself is very beautiful to look at aesthetically, and puts you in mind of an old NES controller crossed with a PSP. However, there are some issues that bother me.

  1. The stackable booster packs are much more robust and well rounded than Arduino shields, which pack in a meager number of IOs, along with better functionalities and peripherals.
  2. The joystick was, literally, a joy to use, with the on board 12 bit ADC giving you an insanely precise location. the Buzzer and Microphone worked adequately too. I had a lot of fun changing the pitch of the buzzer with the joystick to scare my dog.
  3. The Accelerometer module, the one I'd been looking forward to the most, doesn't seem to work. With the MSP 432, I can't program it over Energia and CCS tells me that the concerned libraries are not found. I'll wait for the new board to arrive and test it on there before coming to a conclusion.
  4. If this board is designed for younger electronics enthusiasts, it should be reverse engineer-able (if that's a word) pretty easily, as we are talking about potential makers who will want to use it for their own projects. Ambient light and temperature sensors working on I2C will only confuse them when they see the code itself. Without sufficient background in communication protocols, it's difficult to understand the flow of code. Replacing them with more basic sensors such as the LM35 for temperature and a photodiode, both of which work on ADC, would be a much better option.
  5. The LCD screen is devilishly hard to work on. I gave up my endeavors of getting it to display custom data for the time being, because it was getting to be 10% of the code that actually senses and/or actuates, and 90% of the code just for display purposes. A dedicated API or library for the screen with inbuilt functions would be a boon.

If this board had better documentation, and support in CCS, it would make a killer add-on to any closed loop control system or a sensor node. A few chinks here and there, but overall a very promising product.