MSP430G2553 issue in Transistor interfacing

Ajit65 · Sep 13, 2023

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 · Sep 13, 2023

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

Ajit65 · Sep 14, 2023

Nigel Goodwin · Sep 14, 2023

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 · Sep 15, 2023

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 · Sep 15, 2023

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 · Sep 17, 2023

danadak said:
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 · Sep 17, 2023

Ajit65 said:
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 · Sep 17, 2023

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 · Sep 17, 2023

danadak said:
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 · Sep 17, 2023

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

Resistor pull down VAST needed.

Nigel Goodwin · Sep 17, 2023

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

danadak · Sep 17, 2023

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 · Sep 17, 2023

danadak said:
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 · Sep 17, 2023

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.

MSP430G2553 issue in Transistor interfacing

Ajit65

New Member

rjenkinsgb

Well-Known Member

Ajit65

New Member

Nigel Goodwin

Super Moderator

Ajit65

New Member

danadak

Well-Known Member

Ajit65

New Member

Nigel Goodwin

Super Moderator

danadak

Well-Known Member

Nigel Goodwin

Super Moderator

danadak

Well-Known Member

Nigel Goodwin

Super Moderator

danadak

Well-Known Member

Nigel Goodwin

Super Moderator

danadak

Well-Known Member

Similar threads

MSP430G2553 issue in Transistor interfacing

New Member

Well-Known Member

New Member

Super Moderator

New Member

Well-Known Member

New Member

Super Moderator

Well-Known Member

Super Moderator

Well-Known Member

Super Moderator

Well-Known Member

Super Moderator

Well-Known Member

Similar threads

Privacy & Transparency

Privacy & Transparency