Jump to content
Sign in to follow this  
nobody

Launchpad Pin1.3 problem

Recommended Posts

Small warning for those who do not read manuals:

 

TI produces for us a very good kit at a very competitive price. But no thing is not entirely perfect.

 

Into this kit is pin P1.3 connected to button S2. OK, no problem. But for debouncing button, RC combination C34/R24 is also attached to P1.3.

 

And here's the problem. C34/R24 is not detachable. Still not problem to us? Look to the simple sample code:


#include "io430.h"
#include "intrinsics.h"

const unsigned char FONT[] = {  
 0x00, 0x06, 0x22, 0x00, 0x6D, 0x00, 0x00, 0x20, 0x39, 0x0F, 0x00, 0x70, 0x08, 0x40, 0x00, 0x52, 
 0x3F, 0x06, 0x5B, 0x4F, 0x66, 0x6D, 0x7D, 0x07, 0x7F, 0x6F, 0x48, 0x48, 0x39, 0x48, 0x0F, 0x53, 
 0x00, 0x77, 0x7C, 0x39, 0x5E, 0x79, 0x71, 0x6F, 0x76, 0x30, 0x1E, 0x76, 0x38, 0x15, 0x54, 0x3F, 
 0x73, 0x67, 0x50, 0x6D, 0x78, 0x3E, 0x1C, 0x2A, 0x76, 0x6E, 0x5B, 0x39, 0x64, 0x0F, 0x23, 0x08, 
 0x20, 0x77, 0x7C, 0x58, 0x5E, 0x79, 0x71, 0x6F, 0x74, 0x04, 0x1E, 0x76, 0x18, 0x15, 0x54, 0x5C, 
 0x73, 0x67, 0x50, 0x6D, 0x78, 0x3E, 0x1C, 0x2A, 0x76, 0x6E, 0x5B, 0x39, 0x30, 0x0F, 0x40, 0x00
 };                                    // ASCII table [0x20 - 0xFF]

/********************************************************************************************/
/*                    Test - minimalize power consumption of  MSP430G2211                   */
/*                                                                                          */
/*         I use one character from the display LCD-S301C31TR, connected to port 1          */
/*               P1.0 = Seg.A1, P1.1 = Seg.B1, P1.2 = Seg.C1, P1.3 = Seg.D1,                */
/*               P1.4 = Seg.E1, P1.5 = Seg.F1, P1.6 = Seg.G1, P1.7 = COM                    */
/*                                                                                          */
/*       Power consumption is 76uA/3.5V, 65uA/3V, 33uA/1.5V (problem is RC of P1.3)         */
/*          Without P1.3 power consumption is 3.2uA/3.5V, 2.7uA/3V, 1.35uA/1.5V             */
/********************************************************************************************/
int main( void )
{
 unsigned int i, j;

 WDTCTL = WDTPW + WDTHOLD;             // Stop watchdog timer to prevent time out reset

 BCSCTL3 |= LFXT1S1;                   // VLOCLK enable (my VLOCLK worked at ~~10kHz)

 TACCR0 = 50u - 1u;                    // 10kHz/200Hz = 50 - interrupt every 5msec (200Hz)

 TACTL |= TASSEL_1 + ID_0 + MC_1;      // Timer A clock source select: 1 - ACLK = VLOCLK
                                       // Timer A input divider: 0 - /1
                                       // Timer A mode control: 1 - Up to CCR0 

 TACCTL0 = CCIE;                       // Capture/compare interrupt enable

 __enable_interrupt();

//P1DIR = 0xFF;                         // Set all P1 to output direction
                                       // - alternative -
 P1DIR = 0xFF - BIT3;                  // Set all P1 to output direction (without P1.3)

 for(;                               // Never ending story
 {
   for(i=0; i<(128-32); i++)           // Browse ASCII table chars [0x20 - 0xFF]
   {
     for(j=0; j<100; j++)              // Any character displayed 0.5 sec
     {
       if(P1IN & BIT7)                 
         P1OUT = FONT[i];
       else
         P1OUT = ~FONT[i];

       __bis_SR_register(LPM3_bits);   // ZZZZZZZZZzzzzzzz..........
                                       // CPU, MCLK, SMCLK, DCO are disabled, ACLK are active
     }                               
   }     
 } 
}


#pragma vector = TIMERA0_VECTOR         // Timer A CC0
__interrupt void DELAY(void)
{
 __bic_SR_register_on_exit(LPM3_bits); // WAKE UP, BABY !!!
}

 

OK. The problem is here, what is the solution?

 

1) Do not use P1.3 (not good, this small cheap chips have a few pins ...)

2) Move your lovely chip out of the Launchpad to Breadboard. Thanks to SpyBiWire you need only four wires ...

3) Simply ignore this problem

4) Modify your Launchpad to fix this issue

 

Modify. But how?

 

My suggestion is: break the route from C34/R24 to pin P1.3 of IC1 socket. Remove pinheader J5. Drill two new holes between S2 and J5. Solder a new, six-pin header at location J5. Use two new pins on the pinheader for detachable connection from C34/R24 to button S2. Route S2 to P1.3.

 

And that is all. End of story.

Share this post


Link to post
Share on other sites

Wow, very nice catch for those looking for maximum power savings. :)

 

I think TI deemed this design acceptable because the LaunchPad is meant to be a development platform, not a final project platform. With the zero (or near zero) support part count, there is little reason to keep a final project on the LP. Would have been nice to have the jumper disconnect the RC combo also, though. Maybe they left it to make it easy for hobbyists to swap in their own external button.

 

For myself (and, I'm sure, many others), this power-draining configuration will not be a problem because either a) power consumption is not a concern (powered from USB/wall wart with overall low consumption), or B) I plan on moving to a dedicated board for the final design.

 

This is not to diminish the importance of sharing your find. I can definitely think of some projects where this will be VERY important. :mrgreen:

 

Thanks again!

Share this post


Link to post
Share on other sites

Those differences in current consumption were pretty significant. Good find. It would be pretty useful to someone who was testing the current consumption of their project while still developing it on the launchpad.

Share this post


Link to post
Share on other sites
I think TI deemed this design acceptable because the LaunchPad is meant to be a development platform, not a final project platform.

And let's not forget about schematic that is included in LP's User's Guide, studying it could save some headaches :)

Share this post


Link to post
Share on other sites
What if you use p1.3 as an input instead of an output? Mainly, swap p1.3 and p1.7 in your sample code.

I used all P1 as output. I drive seven LCD segments and COM (common electrode of LCD display). Swap will not bring any benefits. And to your question: If you use P1.3 as input, result is different. And it depends on what kind of signal you connect. Pullup resistor and integration capacitor is able to damage your input data, if you use source with high output impedance, or analog data.

 

But my post does not mean "Launchpad is not good, it needs to be repaired". I tell you "read the manuals, think about these things, and use them wisely".

 

It is also answer to questions type:

- I move my chip from Launchpad to breadboard, and my application work differently. Why?

- I enable internal pulldown resistor at P1.3 and the result not meets the expectations. Why?

- I use P1.3 as analog input, and the measured data are incorrect. Why?

- I write my own debouncing routine. I use the button S2 and the internal pullup resistor. But results not meets the expectations. Why?

- etc...

 

But if you use them wisely, there are also advantages.

- Allow you testing of how your system response to incorrect input connection

- Can be used as timing combination for voltage measurements at MSP430G2211 (use comparator and timer...)

- Reading from S2 button don't need debouncing (this is advantage, and also disadvantage - if you move your application to the Breadboard, be sure you also use the RC)

- Can be used as filter for filtrating short spikes from input data (if you use P1.3 as source of interrupt and/or wakeup, this filtration is very good thing)

Share this post


Link to post
Share on other sites

The bottom line, as GeekDoc already pointed it out, this is a development/proto board and there are some compromises and advantages when using it.

It is a good thing that you made everybody aware of P1.3 resistor "issue", but anyone who wants to develop on LP should get familiar with it first.

Share this post


Link to post
Share on other sites
...anyone who wants to develop on LP should get familiar with it first.

I think that was @nobody's overall point. He found this issue, and used it to point out that we should all pay close attention to the limitations of this great tool we all enjoy so much. :D

 

I am probably one of the worst offenders; I only find out about this stuff when I hit a problem and ask in these forums, or someone like @nobody points it out ahead of time for me. ;)

Share this post


Link to post
Share on other sites

Dang!

 

I was under the impression that there was a jumper to disconnect the push button but there ain't!

 

Thanks for pointing this out!

Share this post


Link to post
Share on other sites

FYI, new shipped launchpad doesn't include R34 and C24 that caused this problem.

 

This also mean everyone example code is wrong since they need to put P1REN |= BIT3; P1OUT |= BIT3; to get the pull-high.

Share this post


Link to post
Share on other sites
FYI, new shipped launchpad doesn't include R34 and C24 that caused this problem.

 

This also mean everyone example code is wrong since they need to put P1REN |= BIT3; P1OUT |= BIT3; to get the pull-high.

 

 

So the r1.5 launchpads have no hardware debouncing of the switch?

Share this post


Link to post
Share on other sites
Correct. They just didn't install the C24 and R34. So I guess everyone could just remove those 2 off their board... BUT just remember to use the in chip pull-up.

in that case It needs more than just a pull up resistor. New code would also need a software debounce check.

Share this post


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.

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

Sign in to follow this  

×
×
  • Create New...