Jump to content

Pin mapping when programming another chip through ISP

Recommended Posts

Just a quick question - probably obvious but I wanna make sure before I order some boards.


If I was using a FR5969 Launchpad as an ISP to program some FR5949 chips - will the hardware I2C pins 1.6 and 1.7 and the software defined I2C pins 3.5 and 3.6 still work even though they are at different physical locations on the chips?  My breadboard prototype version uses I2C on either set of I2C lines and works fine, but with a FR5969 and not the FR5949.  When programming another chip in a series does the pin map need to be defined in the energia_pins.h file for the FR5969? 





Link to post
Share on other sites
  • 2 weeks later...

Ok, I received the boards yesterday and have soldered a few up.


Even though the 1.6 / 1.7 I2C pins port / pins are at different physical locations on the 2 MCUs (FR5969 is 48 pin versus a FR5949 40 pin), where does this get defined in the pins.h file? 


Basically I don't understand how the pins numbers on the MSP430 datasheet from P1.6 and P1.7 (31 and 32 respectively) translate to the numbers seen in the pins.h file like

static const uint8_t MOSI    = 15;  /* P1.6 aka SIMO */
static const uint8_t MISO    = 14;  /* P1.7 aka SOMI */


Thanks in advance!

Link to post
Share on other sites

The pin numbers on the datasheet correspond to the physical way the pins are arranged on the chip. The pin numbers in Energia correspond to the way the pins are physically laid out and numbered around the LaunchPad. See the Energia pin maps, for example: http://energia.nu/wordpress/wp-content/uploads/2015/07/MSP430FR6989.jpeg


EDIT: The 14th and 15th pins are MISO and MOSI so as to work with the standard BoosterPack pinout. In a similar way, the other pins are selected to work with BoosterPacks that meet the standard.

Link to post
Share on other sites

Great, got it.  So how do I ensure when programming another chip in a series (such as the FR5949 using a FR5969 Launchpad) that the pins between the two chips correspond correctly?


If you want to meet the BoosterPack standard here are guidelines: http://www.ti.com/ww/en/launchpad/dl/boosterpack-pinout-v3.pdf


Make sure you have chip pins that meet the standard connected to the appropriate LaunchPad pin and then map it in Energia. If there is a chip in the family that already has a TI LauncPad then use that as a starting place. LaunchPads from TI usually have very good user guides, e.g. http://www.ti.com/lit/ug/slau535b/slau535b.pdf


You can find additional information on the TI site with a search.

Link to post
Share on other sites

Thanks for the response but I think i may have not explained clearly what I am trying to do. 


I have a embedded MSP430FR5949 based datalogger that I am trying to program using the MSP430FR5969 Launchpad as an ISP.  I intend on using P1.6 and P1.7 for I2C to control and read a digital temperature sensor.  I have been unable to get I2C to work on the MSP430FR5949 dataloggers but the original prototype using the MSP430FR5969 works fine. 


I assume the issue is due to pin assignment as one of the chips has 48 pins versus 40.  I modified the energia_pins.h file for the FR5969 to get SW I2C to work on P1.6 and P1.7 instead of P3.4 and P3.5. 


My original question was do I have to tell Energia that P1.6 and P1.7 is at physical pin location on the FR5949 chip than on the FR5969?  If so, what file do I need to modify? I don't see anything in energia_pins.h that identifies the actual physical locations of the chip pins, just the pin outs on the booster pack or Launchpad. 


I apologize if this is unclear. 

Link to post
Share on other sites

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...

Link to post
Share on other sites



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...

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...