aegotheles

Which OS?
On macOS, see under ~/Library/Energia15.

EMT low power unfortunately is not well documented but quite simple. How low of a power the device goes into depends on what interfaces are open and what device the Sketch runs on.
 
The quick reference:
 
If all Sketches are in delay() the idle loop is entered. The idle loop is a TI-RTOS task that consults the power manager and then determines what level of low power it can go to. Make sure that all unused pins are in the appropriate state according to the datasheet. Usually this is output high. Make sure that sensors that are connected are put into sleep mode if you intend to go to low power. Make sure that you call the .end() function on peripherals. e.g. Wire.end(), SPI.end(), Serial.end(), etc. This releases the constraint that the peripherals .begin() functions sets in the power manager. Use inter task communication interfaces to communicate to other tasks when low power should commence. Examples of the low power intertask communication can be found in the Energia examples under File->Examples->10.MultiTasking. Typically you would want to go for semaphore of Event. Pending on a semaphore also acts as low power mechanism. If you pend, the task stops becoming runnable and wont execute again unless the semaphore is posted. Hope this helps.
 
I do have low power example Sketches in the pipeline but I won't be able to get to the in the next month or so.
 
Robert

Just wanted to say thanks!  It took about a week in my spare time, but I was able to create a new energia_pins.h and boards file by comparing what Luke did in his tutorial as you had suggested.  It was pretty straightforward once I was pointed in the right direction.   

Just wanted to say thanks!  It took about a week in my spare time, but I was able to create a new energia_pins.h and boards file by comparing what Luke did in his tutorial as you had suggested.  It was pretty straightforward once I was pointed in the right direction.   

@@aegotheles
 
So, the problem seems to be how to map a different package with a different number of pins, in your case 40 Vs. 48 pins. Note again that pins.energia.h is mapping the ports and their bits to "nicknames" on the LaunchPad that are convenient for the user and make sense in the way the LaunchPad is arranged.  There may, or may not, be exact correspondence to the pin numbers that TI gives in the microcontroller data sheet.
 
Luke Beno did something similar a while back for the MSP430G2553.  He used a 32 pin package where the LaunchPad uses a 20 pin (or 14 pin) package.  He then mapped the ports / bits in his package to the pins on his board (that is, the pin numbers he gave the board and printed on the silkscreen). 
 
Here is a link to his original posts: http://forum.43oh.com/topic/8750-new-msp430-wireless-sensor-node/
 
And here is a link to the modified pins_energia.h: https://github.com/analog-io/iot_sensor_node
 
Have a look at the two different G2553 packages and how Luke adapted pins_energia.h and see if this helps...

OK - I misunderstood (and still might ).  But, looking at pins_energia.h for the fr5969 there is the following:
 
There is this section which I guess your question was aimed at...
static const uint8_t SS = 8; /* P3.4 */ static const uint8_t SCK = 7; /* P2.2 */ static const uint8_t MOSI = 15; /* P1.6 aka SIMO */ static const uint8_t MISO = 14; /* P1.7 aka SOMI */ static const uint8_t TWISCL1 = 9; /* P3.5 SW I2C */ static const uint8_t TWISDA1 = 10; /* P3.6 SW I2C */ static const uint8_t TWISDA0 = 15; /* P1.6 UCB0 */ static const uint8_t TWISCL0 = 14; /* P1.7 UCB0 */ The individual pins on individual ports actually get set below this which is of course what is important
 
For example this section:
// Pin names based on the silkscreen // static const uint8_t P1_0 = 26; static const uint8_t P1_1 = 28; ... Numbers associated  with the LaunchPad pinouts are assigned to variables associated with ports/pins
 
then there is an array with timers for the pins, example:  T0A1,          /* 26 - P1.0 */  in const uint8_t digital_pin_to_timer[].
 
And so on for digital_pin_to_port[], digital_pin_to_bit_mask[], etc....
 
So my questions are...
did you put the datasheets side by side and check where these assignments might not make sense in pins_energia.h and need to be changed? what modifications did you make to pins_energia.h? did you set up a new folder under variants? did you modify boards.txt? can you put an oscilloscope or logic analyzer on the pins and see if there are any wiggles?  
EDIT:  I haven't actually modified Energia to work with a new chip.  Maybe some day somebody will write up a tutorial on how to do it...

I compared the pin diagram of the FR5949 and FR5969 and I2C is on the same port/pin (P1.6/P1.7) so in theory this should work. Note though that you are compiling for the FR5969 and not for the FR5949. This could have issues.
 
I would advice to create a different variant and add that to the boards.txt file.
 
Robert

#1 and #2 no, although I recommend using the native datatype of the info e.g. "int16_t" or "uint16_t" for signed or unsigned 16-bit integers respectively. For #3 - yes. That will be the array size, e.g. the number in brackets, like:
 
__attribute__((section(".text"))) uint16_t SampleStore[256]; // FRAM storage space for 256 16-bit samples
 
Sent from my Galaxy Note II with Tapatalk 4

Actually for #2, it does not need a "physical address" but what it DOES need is an array subscript, e.g.:
 
SampleStore[15] = data;
 
How you store the current # of samples is a good question. Another FRAM variable could be used:
 
__attribute__((section(".text"))) int SampleCount = 0; // Current # of samples stored in SampleStore, initialized as 0 on first flashing
 
Then you would store samples with:
 
SampleStore[sampleCount++] = data;
 
And each run of that statement stores data in a unique location, and "SampleCount" increments likewise, surviving across resets.
 
Sent from my Galaxy Note II with Tapatalk 4

Also to be clear, those FRAM variables or arrays should be declared in the global context, i.e. outside of any function.
 
Sent from my Galaxy Note II with Tapatalk 4

Lastly, check out this thread: http://forum.43oh.com/topic/5474-energia-and-wolverine-tips/
 
Sent from my Galaxy Note II with Tapatalk 4

So I don't recall offhand if Energia provides an "EEPROM" library like Arduino per se, but you will find reading/writing FRAM is actually a little more obvious than you think. The practice is to define an array of bytes but declare it with __attribute__((section(".text"))) so that the compiler & linker stuffs it in the same segment of memory (FRAM) as the rest of the code. Then you don't use read or write calls to hit it- you just literally access the array like you would any array you've declared in RAM.
 
The magic is that its contents retain all changes across resets, unlike a true RAM array. It will get erased if you reflash the sketch or flash a new sketch though.
 
Sent from my Galaxy Note II with Tapatalk 4