Conflicting Pin Assignments for NPN Transistor in KiCad Layout vs. Datasheet

[Mohamed Salah]

Hello KiCad Community,

I'm writing to seek advice regarding conflicting pin assignments I've encountered while working on KiCad V8.0.1.

In the footprint of KiCad layout SOT-23, the NPN transistor is labeled with pins:
PIN 1 as collector
PIN 2 as base
PIN 3 as emitter.

please check the attachment screenshot.

However, the datasheet for this transistor "2N2222" specifies pins as follows:

PIN 1 as base
PIN 2 as emitter
PIN 3 as collector

which is the standard pinout configuration for most NPN transistors.

I've already printed a PCB with this layout, and now I'm concerned about the correctness of the pin connections. Has anyone else experienced a similar issue while working with KiCad v8.0.1  with conflicting pin assignments between the layout and the datasheet? How did you resolve it?

Any advice or insights would be greatly appreciated.

Thank you!

Mohamed Salah

[Mohamed Salah]

Hello KiCad Community,

I'm writing to seek advice regarding conflicting pin assignments I've encountered while working on KiCad V8.0.1.

In the footprint of KiCad layout SOT-23, the NPN transistor is labeled with pins:
PIN 1 as collector
PIN 2 as base
PIN 3 as emitter.

please check the attachment screenshot.

However, the datasheet for this transistor "2N2222" specifies pins as follows:

PIN 1 as base
PIN 2 as emitter
PIN 3 as collector

which is the standard pinout configuration for most NPN transistors.

I've already printed a PCB with this layout, and now I'm concerned about the correctness of the pin connections. Has anyone else experienced a similar issue while working with KiCad v8.0.1  with conflicting pin assignments between the layout and the datasheet? How did you resolve it?

Any advice or insights would be greatly appreciated.

Thank you!

Mohamed Salah

I wanted to provide an update that this issue has been resolved by updating the transistor symbol to base/emitter/collector, and the footprint SOT-23 now matches with the standard. I hope this information is helpful for anyone else who may encounter a similar issue in their PCB design process.

Now I need to reprint the PCB again

[fourfathom]

It's not just KiCad.  I make my own KiCad symbols and footprints, and use JLCPCB assembly.  The JLC/LCSC footprint orientation and pin/pad associations vary depending on part #.  The same-type transistor or IC from different companies (and different JLC part #s) footprint may be rotated 0, or 90, or -90 degrees.  The pin/pad issue isn't a problem since I get that correct in KiCad, but the orientation differences mean that I need to have a different KiCad component/footprint for different JLC part #s, or I have to manually rotate some parts during the JLC design entry.

So just because it looks good in KiCad doesn't mean that the assembly will be correct.  Pay attention!

[Doctorandus_P]

There are so many things (slightly) wrong with this thread...

1. There is no 2N2222 in KiCad's default libraries, and you did not mention which exact footprint / symbol you used.
2. 2N2222 is a TO92 device.
3. You show a datasheet of an MMBT2222, (and that is a SOT-23 device).
4. MMBT2222A is in KiCad's default libraries, and it's pinout is the same as in the datasheet you show.

KiCad also has generic transistor symbols. Have a look at the Q_NPN_XXX devices, where the XXX is EBC in all 6 possible pin ordering combinations.

So be careful with the assumptions you make. As fourfathom mentioned: Pay attention! In PCB it is common to use the Trust, but verify approach. It is common to do a careful check for pinout for each and every library symbol and footprint you use, and then create personal libraries for all parts that you use and have been verified to be correct (or corrected). In the old days when having PCB's manufactured was expensive, this was all the more true, but even with the cheap PCB services, a faulty PCB  can cause a delay of weeks for your project. Sometimes faults can be very subtle, for example some transistors can be bought in different pinouts, even in the same package. Another historical fuckup, is that the location of pin 1 on a SOT-23 package is not defined unambiguously, although it seems the "alternative" pin numbering for this package have become very rare.

[Uky]

Been there - Done that. I ended up renaming pins to what they were in reality. SOT-23 pinning is pretty much standard but
I chose to rename schematic symbols  E, B, C and match those designations also on the PCB footprint. Same thing with FET's
S,G, D and A, C. For diodes. Since I have encountered single diodes in SOT-23 packages and that the orientation of the diode varies (!)
I then create a footprint dedicated to that specific type like 1N(something) underscore A,C, NC, etc. Same thing with odd
transistor footprints where there are two devices in a single 6-pin package. Then E1, B1, C1, E2, B2, C2 etc...

One specifically nasty thing is DSUB-connectors for PCB. The footprints are the same for male and females but the pinning is NOT.
Then a descriptive text is added in a documentation layer visible when instantiating the footprint on to the board. Such a practice
cad reduce the number of board spins considerably.

My 5 cents...

[John B]

I think I had this issue in my last project with a SOT23 device.

The best case is if the datasheet shows an image of which pin they are calling pin 1. 2 and 3. Thankfully SOT23 devices only orient in one direction, so you can check KiCAD's assigned footprint to the datasheet diagram.

[fourfathom]

I think I had this issue in my last project with a SOT23 device.

The best case is if the datasheet shows an image of which pin they are calling pin 1. 2 and 3. Thankfully SOT23 devices only orient in one direction, so you can check KiCAD's assigned footprint to the datasheet diagram.

But know that the JLCPCB orientation may not be the same as the datasheet orientation. Probably the case for any assy service.