Sign in to follow this  
Followers 0
aegotheles

Pin mapping when programming another chip through ISP

12 posts in this topic

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? 

 

Thanks!

 

 

Share this post


Link to post
Share on other sites

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

aegotheles likes this

Share this post


Link to post
Share on other sites

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!

Share this post


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.

energia likes this

Share this post


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? 

Share this post


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.

Share this post


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. 

Share this post


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

aegotheles and energia like this

Share this post


Link to post
Share on other sites

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

energia and aegotheles like this

Share this post


Link to post
Share on other sites

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

Fmilburn and energia like this

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0