LIJsselstein

As a form of documenting... I just added another new MCU to Energia and -in short- had to do the following to get it working:
In Energia 1.8.7E21:
Copy from a close family member the following files and replace the model name with the new model name in the directory-/filename and file content:
\hardware\energia\msp430\variants\[existing-model]\ \hardware\tools\DSLite\common\targetdb\devices\[existing-model].xml \hardware\tools\DSLite\common\targetdb\options\[existing-model]_GNU.xml \hardware\tools\DSLite\common\targetdb\options\[existing-model]_TI.xml \hardware\tools\msp430\msp430\lib\ldscripts\[existing-model]\ \hardware\tools\msp430\msp430\include\[existing-model].h Add the new model to the following files:
\hardware\energia\msp430\boards.txt \hardware\tools\msp430\msp430\include\msp430.h \hardware\tools\msp430\msp430\lib\msp430mcu.spec Of course, check for differences between the two family members (e.g. missing or added peripherals, memory sizes) and edit the copied files accordingly.
After the above changes it might help to remove the temporary build tree. These are located in ~/.energia15 for Linux and  %userprofile%\appdata\local\Energia15 for Windows.

I think this is because, when there is no external XTAL connected, Energia (wiring) usually falls back to the VLO source (~12k Hz). But on the FR2433 the clock falls back to the REFO source which runs about 3x faster ( ~32768 Hz).
However the code in wiring.h does not reflect this. Please look around line 144 in wiring.c (hardware/energia/msp430/cores/msp430/wiring.c):
/* ACLK = VLO = ~ 12 KHz */ vlo_freq = 8000; /* Source ACLK from REFO */ CSCTL4 |= SELA__REFOCLK; Where I think it should be:
/* ACLK = REFO = ~ 32 KHz */ vlo_freq = 32768; /* Source ACLK from REFO */ CSCTL4 |= SELA__REFOCLK; Since Sleep() uses the clock for timing and Delay() uses the CPU frequency for timing, this could explain your difference.
Pinging @StefanSch

I'm using mspflasher and, indeed, another launchpad (5969 or 6989) to program my custom board. Haven't done any online debugging yet (not necessary so far). Some shell scrips help create the info sections and flash the info&program.

@@LIJsselstein,
 
I don't have any specific reason for singling out this repository.
 
A long time ago, in another job, I was writing C code for the Z80. The micro had to talk with the on-board metering system of a gigantic mining truck. The protocol used was called PLM2. It has since upgraded to PLM3. It turns out that it is too complex of a protocol for my tinkering.
 
So, I went on the hunt for source code examples which demonstrated packetized communication between the PC and a micro. Specifically, I was hunting for source code examples in python that showed me how to work with structures of packets.
 
Eventually, I would like to have a PC program that creates a SCADA like interface to my micro projects. I want to issue commands to the micro and receive back lots of data.  It seemed to me that this pytelemetry was a convenient example to consider.
 
Do you have other source code examples that you would like to share with us?
  I was on the hunt for source code examples which demonstrated packetized communication between the PC and a micro. 
 

This post covers my experiences with a Sharp IR sensor marked 2YOA2I F 7I  I received courtesy of @@bluehash clearing his desk a while back.

Sharp IR sensors can be obtained that cover ranges from 4 - 30 cm up to 100 - 550 cm.   This one has a listed range of 10 - 80 cm. The coverage envelope / angle was not listed in the data sheet but seemed relatively narrow. Current consumption is around 30 mA on average.   Response time is listed as 39 ms.  The output from the sensor is an analog voltage which is inversely proportional to the distance in a nonlinear manner.
 
Of particular note to those using TI microcontrollers is that it is a 5V device (the datasheet gives 4.5 to 5.5 V as the operating range for Vcc).  Most of my gizmos run off of 2 batteries at nominally 3V so I was interested in how it would work at lower voltages and ran a series of tests.  A bench power supply was used to supply constant voltage at 5.0, 4.5, 3.3, 3.0, and 2.5 Volts (accurate to better than 0.1 V).  I used a tape to measure the distance from the face of the sensor to a wall (distance accurate to 2 mm).  The voltage was measured with a digital multimeter and plotted against the inverse of distance to give a more linear curve.
 
Here are the results:

With Vcc set to 5.0 V and 4.5 V the output difference was minimal - the results are for all practical purposes the same and are in line with the datasheet.  The data for Vcc at 3.3 V and 3.0 V might be usable with the understanding that the curves began to offset some as Vcc drops, and that at 3.0 V the accuracy falls off at 15 cm, and at 3.3 V it falls off at 10 cm.  The sensor is not usable at 2.5 V.
 
If highest accuracy is required, a test like the one described here can be undertaken instead of just using the curve in the datasheet.

Yes, a collegue and I have been doing all of the above with a G2553 (and other chips like the 28 pin version and the FR2433) using sleep (LPM0), sleepSeconds (LPM3), interrupts, ADC and master/slave I2C. We found two bugs in the I2C implementations and made bugreports and pull-requests for them. At least one pull-request is over a year old and has not been pulled-in, not sure why. So, it depends a bit on your specific situation if you'll run into any problems or not. CCS we found especially useful to do register level debugging of our I2C problems after importing the Energia sketch (which does not work for our custom FR2433 board!) and using EnergyTrace++ (a very very cool tool when doing low power development).

To answer my own question: the error is triggered because, for 16 or 32 bit operations, the variable must be aligned on an even memory address, however the INFOMEM_CORRECTION_VALUE variable was defined on an odd address. Moving it from 0x1855 to 0x1856 solved the compiler error.

Energia and Arduino users eventually get to the point where they need more direct access to the hardware if they take on more complicated projects.  In addition to the direct access of registers using the provided header files, TI offers DriverLib which contains abstractions for accessing the peripherals.
 
To better understand the peripherals, and to check out DriverLib, I recently created 20+ short examples for my own edification.  All of them were written for the MSP430F5529 LaunchPad and most of the peripherals are covered.  In some cases pushbuttons, LEDs, resistors, potentiometer, etc. are required that you probably have on hand.  A multimeter is required, and in some cases an oscilloscope and logic analyzer are instructive but not necessary.
 

DriverLib SPI Example 13A_USCI_B_SPI_MCP41010_digiPot
 
All of the examples are located here:  https://github.com/fmilburn3/MSP430F5529_driverlib_examples
 
It is necessary to have some understanding of the registers before using DriverLib because the DriverLib documentation doesn't describe how the peripherals and their registers work.  The documentation for registers is located in the User

@@yyrkoon
 
I have the genuine Saleae and a chinese counterfeit. Their hardware and software is solid. The counterfeit ... well, you get what you pay for.
 
FYI, they are under pressure by the far east counterfeiters.  
 
Rest assured that the company is filled with good guys and their products are Made in the USA.
 
There's no sense in getting worked up about it. It isn't worth the stress.
 
Just switch off your emotions and select a logic analyzer based on its abilities.

So just last week I stood before some 300 fruit farmers at a university research center showing our little IoT soil moisture transmitter that may either lift the burden of manually measuring twice a day on multiple locations, or from the long wires crisscrossing their fields with gprs modems and bulky batteries. There was quite some interest both from farmers as from their consultants. The name 'IoT' may be hype but there are a lot of realy useful applications.

AFAIK, only G2 LP can be used as BSL hardware base.
 
http://www.ti.com/lit/pdf/slaa535    Launchpad-Based MSP430 UART BSL Interface
 
FR2xx and FR4xx devices can be unlocked by USER CODE ERASE (1A1A) command using mailbox system by SBW / JTAG.This can be done by MSP-Flasher (check erase options), and I guess by any LP with eZ-FET Lite on board..

 

I wrote this up the other week but forgot to post it.  Just a little power-user help for folks interested in really exploring the "potential" behind FRAM memory in Energia.
 
Tips & Advanced Tricks for using Wolverine with Energia 12   I've brainstormed a few things folks might want to play with if they're interested in getting the most out of their Wolverine LaunchPad and its built-in FRAM memory.  The FRAM memory, being modifiable yet persistent, is quite different from Flash and our C compilers aren't necessarily laid out to make it super-simple to use.  That said, it's not really that hard to use.   There are a few "tricks" you can employ with Energia 12 to get more out of your Wolverine-   1. Declare global variables as being part of the ".text" linker section, so they live in FRAM and are not copied to/fro RAM on bootup. (this is the "quick hack" way to do it, the long & canonical way to do this is to define a new section in the Linker Script assigned to the ROM segment and declare your arrays or variables as being a part of that section instead).   2. Write/read to the "High" memory segment -- the Wolverine happens to have a 16KB segment of its FRAM living from 0x10000 to 0x13FFF (that's above address 65536 decimal, outside the realm of what a 16-bit pointer can reference) which is unknown to the MSPGCC compiler that ships with Energia 12, since it doesn't support large-memory model.   3. Move your RAM to FRAM, giving you more RAM (stack & heap) if it's what you want.  This isn't always necessary since you can declare large arrays as a global in the ".text" section per #1 above.   Without further adieu, let me show you:   1. In your sketch, up top you can do something like this:   #define PERSIST __attribute__((section(".text")))   and then declare global variables with this new "PERSIST" keyword like such:   uint8_t DisplayBuffer[LCD_MAXIMUM_Y][LCD_MAXIMUM_X] PERSIST;   Your "DisplayBuffer" array will live in FRAM and won't hog up any of your RAM.  It will co-exist with program code, so be VERY VERY SURE not to make any "buffer overflow" mistakes and write before or past the end of its memory boundaries or you will corrupt your sketch's binary application code.  Take this doubly serious when the application in question involves Internet connectivity of any kind; I can imagine the spectacular headline on the blogs "IoT application sports buffer-overflow exploit where attacker can write any binary MSP430 code they want!"   Alternately, you can use the InfoMem segments:   uint8_t DisplayBuffer[512] __attribute__((section(".infomem")));   which has 512 bytes (maximum) available for your use; it lives outside the main code FRAM area and if you try writing beyond it, you attempt to write to the calibration data (TLV) FRAM segment which should throw an internal violation (not sure what happens, whether the chip halts or resets or does nothing, but the calibration info will remain safe).  Unlike other MSP430 chips, Info segment "A" can be written on these as the calibration data is stored in another "special" FRAM segment at 0x1A00.     2. I wrote some functions employing assembly language; which the current stable release of MSPGCC does understand (the extended-memory 20-bit instructions) that gives you a way to copy data to or from the higher memory segments. See here: HighMem.zip   The functions are called highmem_write() and highmem_read().  You can import the HighMem library into your sketch, and it should add: #include "highmem.h" to your sketch.   The functions are:   void highmem_write(uint32_t dstaddr, void *srcaddr, uint16_t len) You give it the FRAM destination address as a 32-bit integer (0x10000 or above), followed by a pointer to a buffer in your SRAM or lower FRAM, followed by the # of bytes you want to write.   The reciprocal of this is highmem_read(): void highmem_read(uint32_t srcaddr, void *dstaddr, uint16_t len)   Give it the FRAM source address as a 32-bit integer (0x10000 or above), followed by a pointer to a buffer in your SRAM or lower FRAM where you want the data to be copied into, followed by the # of bytes.  The # of bytes can be an odd or even number, as it uses byte-at-once transfers rather than word-at-once.  It uses DMA channel#2 to do the transfers.   For those using the FRAM to store a display buffer of some sort, this may be useful as a "bonus" loft or swap area for storing multiple versions of your display framebuffer.  The memory up there is not allocated by the linker, so you need to manage it yourself (keep track of which addresses you've used and how much data is stored there).  It's also not possible to reference the data directly by variables, because the MSPGCC compiler used in Energia 12 doesn't support the large-memory model (doesn't produce the 20-bit pointers and appropriate instructions for accessing it directly).  There is a later revision of MSPGCC (developmental) that does support this, but Energia isn't using it.  At some point in the future Energia will use the RedHat msp430-elf-gcc which does support large-memory model, but that'll be a while out I think.   Example sketch using these (writes a stock string to the highmem, then changes 2 bytes before reading it back into an SRAM buffer to be printed over the serial port)- #include <highmem.h> #include <string.h> const char *teststr = "What is this???"; void setup() { // put your setup code here, to run once: pinMode(P4_5, INPUT_PULLUP); delay(10); while (digitalRead(P4_5)) ; // Wait for S1 to be pressed so the user has time to open serial monitor Serial.begin(115200); Serial.println("HighMem test:"); highmem_write(0x10000, teststr, strlen(teststr)+1); // Write stock string to highmem } void loop() { char buf[128]; // put your main code here, to run repeatedly: buf[0] = 'a'; buf[1] = 't'; highmem_write(0x10000+10, buf, 2); // Write 2-byte modification to highmem highmem_read(0x10000, buf, strlen(teststr)+1); // Pull entire string from highmem to 'buf' Serial.print("HighMem string says: "); Serial.println(buf); while(1) delay(1000); } It prints "What is that???" instead of "What is this???", thanks to the modification performed in loop().     3. Edit MSPGCC's linker script for the msp430fr5969 to move "ram" into the FRAM address space.  Note you'll have to move the "rom" linker segment up appropriately to give room for the RAM.   From your Energia install, e.g. C:\energia-0101E0012, the MSPGCC compiler is stored under "hardware\tools\msp430".  The linker scripts live in: C:\energia-0101E0012\hardware\tools\msp430\msp430\lib\ldscripts with a separate directory for each chip.   Go into C:\energia-0101E0012\hardware\tools\msp430\msp430\lib\ldscripts\msp430fr5969 and locate a file called "memory.x". Open this in a text editor, you should see the default contents which look like this:   MEMORY { sfr : ORIGIN = 0x0000, LENGTH = 0x0010 /* END=0x0010, size 16 */ peripheral_8bit : ORIGIN = 0x0010, LENGTH = 0x00f0 /* END=0x0100, size 240 */ peripheral_16bit : ORIGIN = 0x0100, LENGTH = 0x0100 /* END=0x0200, size 256 */ bsl : ORIGIN = 0x1000, LENGTH = 0x0800 /* END=0x1800, size 2K as 4 512-byte segments */ infomem : ORIGIN = 0x1800, LENGTH = 0x0200 /* END=0x1a00, size 512 as 4 128-byte segments */ infod : ORIGIN = 0x1800, LENGTH = 0x0080 /* END=0x1880, size 128 */ infoc : ORIGIN = 0x1880, LENGTH = 0x0080 /* END=0x1900, size 128 */ infob : ORIGIN = 0x1900, LENGTH = 0x0080 /* END=0x1980, size 128 */ infoa : ORIGIN = 0x1980, LENGTH = 0x0080 /* END=0x1a00, size 128 */ ram (wx) : ORIGIN = 0x1c00, LENGTH = 0x0800 /* END=0x2400, size 2K */ rom (rx) : ORIGIN = 0x4400, LENGTH = 0xbb80 /* END=0xff80, size 48000 */ vectors : ORIGIN = 0xff80, LENGTH = 0x0080 /* END=0x10000, size 128 as 64 2-byte segments */ far_rom : ORIGIN = 0x00010000, LENGTH = 0x00004000 /* END=0x00014000, size 16K */ /* Remaining banks are absent */ ram2 (wx) : ORIGIN = 0x0000, LENGTH = 0x0000 ram_mirror (wx) : ORIGIN = 0x0000, LENGTH = 0x0000 usbram (wx) : ORIGIN = 0x0000, LENGTH = 0x0000 } REGION_ALIAS("REGION_TEXT", rom); REGION_ALIAS("REGION_DATA", ram); REGION_ALIAS("REGION_FAR_ROM", far_rom); PROVIDE (__info_segment_size = 0x80); PROVIDE (__infod = 0x1800); PROVIDE (__infoc = 0x1880); PROVIDE (__infob = 0x1900); PROVIDE (__infoa = 0x1980); What we're interested in here is the "ram (wx)" and "rom (rx)" definitions in the MEMORY { } declaration. The default setup puts RAM where it should be; at the Wolverine's 2KB SRAM segment starting at 0x1C00.  The "rom" is actually FRAM, but called "rom" since the main linker scripts are common to all the msp430 targets supported and expect to see the main program memory called "rom".   So for fun, let's move our 2KB RAM segment into FRAM.   It'll look like this:   ram (wx) : ORIGIN = 0x4400, LENGTH = 2048 /* END=0x4C00, size 2K */ rom (rx) : ORIGIN = 0x4C00, LENGTH = 45952 /* END=0xff80, size 48000-2048 = 45952 */ Note I used decimal for the LENGTH part so it's easier to think through.  We're putting our "ram" segment at the start of FRAM, and moving the start of the "rom" segment 2KB higher to compensate, but also telling the linker that its segment is now 2048 bytes (2K) smaller.  This last piece is very important; you'll see errors in compiling if you get it wrong.   Now one of TI's big marketing push is you can partition your FRAM to give more space to RAM vs. code.  Let's say you have a sketch that runs beautifully on the MSP430F5529 LaunchPad with its 8KB available SRAM, but bombs on the Wolverine.  You want to give the Wolverine 8KB RAM too so it'll work right.   It'll look like this:   ram (wx) : ORIGIN = 0x4400, LENGTH = 8192 /* END=0x6400, size 8K */ rom (rx) : ORIGIN = 0x6400, LENGTH = 39808 /* END=0xff80, size 48000-8192 = 39808 */ We put "ram" at the start of FRAM, gave it 8192 bytes (8KB), moved the "rom" segment up by 8KB and shrunk its total length by 8KB.   Note that unfortunately you can't just combine your existing SRAM and FRAM together since they are not contiguous in address space.  SRAM starts at 0x1C00 and ends at 0x2400, where FRAM starts at 0x4400; there is a 0x2000 (8KB) gap between those two.   It's always a good idea to keep the original ram & rom specifiers in that memory.x file but commented out so you can quickly go back to the original configuration.  Here's what it looks like: /* ram (wx) : ORIGIN = 0x1c00, LENGTH = 0x0800 */ /* END=0x2400, size 2K */ /* rom (rx) : ORIGIN = 0x4400, LENGTH = 0xbb80 */ /* END=0xff80, size 48000 */ ram (wx) : ORIGIN = 0x4400, LENGTH = 8192 /* END=0x6400, size 8K */ rom (rx) : ORIGIN = 0x6400, LENGTH = 39808 /* END=0xff80, size 48000-8192 = 39808 */   You can then comment out the 2nd ram/rom definitions and uncomment the first one (notice the "*/" after "LENGTH = " in the first 2 lines) to revert back to the default memory setup.   That said, unless you are just trying to run a sketch that works beautifully on the MSP430F5529 or Tiva-C due to its expansive RAM and won't on the Wolverine, there's probably no reason to hack your linker script when you can just declare big buffers as part of the ".text" section per #1 explained above.

USB and Low Power are indeed a very much desired set of coupled features. For example, making a portable device that runs from a small battery or solar cell that you want to configure or extract logged data from at the end of the day or something. Perhaps the battery recharges via a USB connection as well. So, having USB to communicate to the device when charging is a definite feature worth having. It can be low power when not connected to USB.

I've started this week using CCS to debug and analyse power consumption of my battery powered device using the Energia framework. CCS/EnergyTrace is a powerful tool when it works, however, I have one really really annoying problem with it: debugging does not work most of the time.
 
When it works, pressing the debug button will break the code on the first line in setup() and EnergyTrace is running during debug. When it doesn't work, the device seems to be running and debugging seems to run, but it won't stop in setup() or other breakpoint I set, Pauze button is greyed-out and EnergyTrace is not working. Stopping and starting debug many times will eventually lead to a functional debug session but it may take 10+ attempts. I've tried removing the debug configuration, restarting CCS, powercycling the launchpad....
 
Nothing seems to help consistently, but detaching/attaching during debug and then performing a soft reset is most consistent to resolve the breakpoint problem for one debug session, but then EnergyTrace still does not work.
 
There are no errors in the console. CCS 6.1.1 is completely up to date. Windows 7 Pro x64. FET on FR6989 launchpad used for programming G2553 device.

It doesn't sound right to me calling capacitors on signal lines "decoupling capacitors" sounds more like you've created an RC filter. With the R being the gate resistance of the driver behind the IO pin.
 
What you're actually seeing is the effects of transmission line theory! Basically when a digital signal changes state very quickly (slew rate, or edge rate) it creates harmonics. On modern chips, even slow (by clock rate) micro controllers, that can span into the 100MHz range. This basically oscillates in your PCB tracks due to their inductance causing ringing on the edges due to reflections from impedance mismatch. If this ringing is bad enough then you will get data corruption.
 
Adding a series resistor helps, because if you picture your PCB tracks or wires as transmission lines then the resistor acts to impedance match between the IC pins and your PCB tracks. a 50 ohm resistor is ideal for a 50 ohm transmission line.
 
Here is a quick primer that very concisely explains the basics of this stuff if you don't have a strong EE background.

For SPI pins if it's necessary maybe 10nF or less can be used, but also some inline resistors (say 50R) can be used instead of caps and might help better. USB uses 27R resistors plus 47pF caps on each signal at each physical endpoint IIRC for what it's worth.

Hello
I am trying to send data to browser using wifi module ESP8266 with MSP430G2553 launchpad.
ESP8266 work on 3.3V and MSP430G2553 also. So here i connected ESP8266 directly to the launchpad.
connections are-
Tx of ESP to Rx of Launchpad
Rx of ESP to Tx of Launchpad
VCC to Vcc
Gnd to Gnd
CH_PD to 3.3V
 
and i got code for energia from this forum only. code is as follows
#define SSID        "friends"         #define PASS        "walchand"         #define DST_IP      "things.ubidots.com"         #define idvariable  "569fc4ba76254229c49896a6"   // replace with your Ubidots Variable ID         #define token       "aIdUatYb4QqgntExGmdi6xIllonUaY3AxwJjs5UzCCVib9reI1dI2XFEnfeX"  // replace with your Ubidots token         int len;                  void setup()         {           // Open serial communications and wait for port to open:           char cmd[254];           Serial.begin(9600);           Serial.setTimeout(5000);           //test if the module is ready           Serial.println("AT+RST");           delay(1000);           if (Serial.find("ready"))           {             Serial.println("Module is ready");           }           else           {             Serial.println("Module have no response.");             while (1);           }           delay (1000);           //connect to the wifi           boolean connected = false;           for (int i = 0; i < 5; i++)           {             if (connectWiFi())             {               connected = true;               break;             }           }           if (!connected) {             while (1);           }           delay(5000);           Serial.println("AT+CIPMUX=0");           }                  void loop()         {           int value = analogRead(A0);                          //you can change ir to another pin           int num=0;           String var = "{\"value\":"+ String(value) + "}";           num = var.length();           String cmd = "AT+CIPSTART=\"TCP\",\"";           cmd += DST_IP;           cmd += "\",80";           Serial.println(cmd);           if (Serial.find("Error")) return;                      len=strlen ("POST /api/v1.6/datasources/");           len=len+strlen (idvariable);           len=len+strlen ("/values HTTP/1.1\nContent-Type: application/json\nContent-Length: ");           char numlenght[4]; // this will hold the length of num which is the length of the JSON element           sprintf(numlenght, "%d", num); // saw this clever code off the net; works yay           len=len+strlen (numlenght);           len=len + num; //fixed length of the string that will print as Content-Length: in the POST           len=len+strlen ("\nX-Auth-Token: ");           len=len+strlen (token);           len=len+strlen ("\nHost: things.ubidots.com\n\n");           len=len+strlen ("\n\n");           Serial.print("AT+CIPSEND=");           Serial.println (len); //lenght of the entire data POST for the CIPSEND command of ESP2866           //Serial.println(cmd.length());           if (Serial.find(">"))           {             //Serial.print(">");           } else           {             Serial.println("AT+CIPCLOSE");             delay(1000);             return;           }           Serial.print ("POST /api/v1.6/variables/");           Serial.print (idvariable);           Serial.print ("/values HTTP/1.1\nContent-Type: application/json\nContent-Length: ");           Serial.print (num);           Serial.print ("\nX-Auth-Token: ");           Serial.print (token);           Serial.print ("\nHost: things.ubidots.com\n\n");           Serial.print (var);           Serial.println ("\n\n");           delay(9000);           //Serial.find("+IPD"); clear the input buffer after the web site responds to the POST           while (Serial.available())           {             char c = Serial.read();           }           delay(1000);         }         boolean connectWiFi()         {           Serial.println("AT+CWMODE=1");           String cmd = "AT+CWJAP=\"";           cmd += SSID;           cmd += "\",\"";           cmd += PASS;           cmd += "\"";           Serial.println(cmd);           delay(2000);           if (Serial.find("OK"))           {           return true;           } else           {            return false;           }         } when i trying to connect to wifi then it is not working properly
it display only ..
 
AT+RST
Module have no response.
 
So what can be the problem?? And one more thing is that blue LED on ESP is not blinking continuously.
 

Initially I did not know how to invoke a new constructor. Some trial and error resulted in the following code in setup(). Hopefully this is useful for other users:
// Re-initialize the I2C library to use the USCI hardware Wire = TwoWire(0); @@Johann,
There appears to be a bug introduced in Energia 17 wrt I2C, Serial comms and MSP devices with USCI hardware. Itserik created a pull-request to fix this.

A tad cryptic. But the lab kit includes a set of common components needed if this was your first dive into electronics. It seems to be paired with a udemy course.
 
http://www.element14.com/community/community/learning-center/online-learning/moocs/ti-valparaiso-udemy?ICID=hp-moocsvalparaiso-ban
 
https://www.udemy.com/mcu_msp430/
 

Here's another users who ran into this problem. The following code will continue to suck ~160 uA even when in LPM3.
void loop() {   analogReference(INTERNAL2V5);   int v = analogRead(11);     sleepSeconds(10); } It is solved for me when I add two lines after analogRead() to shutdown the ADC:
void loop() {   analogReference(INTERNAL2V5);   int v = analogRead(11);     // end conversion and turn off ADC   ADC10CTL0 &= ~ENC;   ADC10CTL0 &= ~(ADC10IFG | ADC10ON | REFON);     sleepSeconds(10); } Thanks to this article. I only found this thread afterwards.
 
This Energia behavior bug(?) is still in version 0101E0016.