MSP430G2553 issue in Transistor interfacing

[Ajit65]

I am facing a problem while switching a transistor. I am trying make the LED blink through a transistor. The program works when I am taking the power (3.3V) from the evaluation board (i.e. MSP-EXP430G2ET). But code does not work when I am using external power (8.33V) to power the LED. I am using a BC547 transistor. A current limiting resistor of 470 ohms in series with LED and a base resistor Rb of 2.2K ohms (which allows around 3.7 mA to the base of the transistor) used when the power is 8.33V. While taking the power from the LDO I am using a current limiting resistor of 220 ohms and same Rb. The code is given below,
#include <msp430.h>

void main(void)
{
WDTCTL = WDTPW | WDTHOLD; // stop watchdog timer
P1DIR |=BIT3;
unsigned int i;
while(1)
{
P1OUT ^= BIT3;

for(i=0; i<=30000; i++) ;
}
}

 

[rjenkinsgb]

How to you have the transistor, power and LED etc. connected?

 

[Ajit65]

 

[Nigel Goodwin]

Well that's only a small part of the circuit - does the 8.33V supply share a common ground with the processor and the emitter of the transistor?. But if in doubt, measure the voltages - with it switched ON, there should be 0.7V (or so) on the base of the transistor, 0V on the emitter, slightly more than 0V on the collector, and 2.5V or so (depending on the LED colour) on the top side of the LED.

 

[Ajit65]

Thank you very much Nigel. As microcontroller and the transistor circuit both were having different ground instead of common ground, the current from the pin was not able find a path back to the microcontroller's ground as a result it was not working. Thanks again!

 

[danadak]

One minor item, when processor starts up usually most outputs are in
tri-state (actually configed on startup as inputs). So that leaves base of
transistor floating, and leakage can turn it on. With todays LEDs even at very
low currents one can see them emit. Best practice is add a R from base to ground,
roughly 10X the value of the base R to processor pin, to absorb leakage and to
hold off LED turn on until processor takes control of the pin.

The R value is stated as 10X the base R. Its really calculated from leakage hot
to not turn on the transistor. But 10X is a good rule of thumb. And it
does not rob much base drive from the NPN as supplied by processor output.


Regards, Dana.

 

[Ajit65]

One minor item, when processor starts up usually most outputs are in
tri-state (actually configed on startup as inputs). So that leaves base of
transistor floating, and leakage can turn it on. With todays LEDs even at very
low currents one can see them emit. Best practice is add a R from base to ground,
roughly 10X the value of the base R to processor pin, to absorb leakage and to
hold off LED turn on until processor takes control of the pin.

The R value is stated as 10X the base R. Its really calculated from leakage hot
to not turn on the transistor. But 10X is a good rule of thumb. And it
does not rob much base drive from the NPN as supplied by processor output.


Regards, Dana.

Thanks for suggestion.

 

[Nigel Goodwin]

Thanks for suggestion.

It's always a good idea, but in the VAST majority of cases it makes no difference at all. It was more of a concern in the ancient days of germanium transistors, when transistors leaked quite a bit

 

[danadak]

It's always a good idea, but in the VAST majority of cases it makes no difference at all.

In the VAST majority of cases it has the additional properties of terminating a floating
node, eg. base of transistor, from stray pickup, like almost ever present AC line coupling, when
output is effectively in tri state, powered up as an input. Doubly important if driving a
MOSFET. And less we forget pay attention to leakage coming in/out of GPIO from protection
diodes when configed as inputs. Todays parts better, trust, but verify operative word.

So I recommend in the VAST majority of cases using the pulldown at power device input.


Regards, Dana.

 

[Nigel Goodwin]

In the VAST majority of cases it has the additional properties of terminating a floating
node, eg. base of transistor, from stray pickup, like almost ever present AC line coupling, when
output is effectively in tri state, powered up as an input. Doubly important if driving a
MOSFET. And less we forget pay attention to leakage coming in/out of GPIO from protection
diodes when configed as inputs. Todays parts better, trust, but verify operative word.

So I recommend in the VAST majority of cases using the pulldown at power device input.


Regards, Dana.

Nothing you claim there makes the slightest practical need for it, as I said it's a good idea to always add them, but in the VAST majority of cases (unless you're deliberately building something to cause such an issue) it makes no difference.

Don't let bases float, don't tri-state outputs, and don't switch them as inputs - all even more basic requirements than adding extra resistors, which are unlikely to be needed.

 

[danadak]

Most processors start up GPIO as inputs these days.....

Resistor pull down VAST needed.

 

[Nigel Goodwin]

And the first thing you do is set them to outputs - not a problem.

 

[danadak]

And the first thing you do is by design, insure safety is guaranteed, not
a hope it will work right, not a throw of the dice.

Processors and their PLLs and timing startup and latency can take enough
time to kill someone. So insuring HW does nothing stupid while SW has not
taken control is in most industries I know at the top of design list. Its even
why many non stop designs now use redundancy, NASA website full of
papers on these concepts. Many processors now, before executing user
code, execute their own internal firmware kernels, more time to do something
bad if HW not properly designed.

 

[Nigel Goodwin]

And the first thing you do is by design, insure safety is guaranteed, not
a hope it will work right, not a throw of the dice.

Processors and their PLLs and timing startup and latency can take enough
time to kill someone. So insuring HW does nothing stupid while SW has not
taken control is in most industries I know at the top of design list. Its even
why many non stop designs now use redundancy, NASA website full of
papers on these concepts. Many processors now, before executing user
code, execute their own internal firmware kernels, more time to do something
bad if HW not properly designed.

Might be a possible concern in a spacecraft, but not in a hobbyist, or indeed normal commercial, setting.

It's certainly good practice, but rarely makes the slightest difference.

 

[danadak]

I functioned as a FAE for several manufacturers, calling on Medical accounts, Router and switch
companies, heavy industrial, NORMAL COMMERCIAL companies and activities, and safety was
of topmost concern. We come from two different design environments.

It's certainly good practice, but rarely makes the slightest difference.

All I can say is WOW !

We agree to disagree.