Over a million developers have joined DZone.

Learning from Failure: QFN Package Corner Problem

DZone's Guide to

Learning from Failure: QFN Package Corner Problem

If you thought debugging software was tough, you should try tracing issues on hardware prototypes.

· IoT Zone
Free Resource

Cisco IoT makes digital transformation a reality in factories, transportation, and utilities. Learn how to start integrating with Cisco DevNet.

Every day, there is something new to learn. And having problems is always a good learning opportunity :-). Yesterday we were able to find a strange problem with our tinyK20 prototypes, just before we were about to send the design for manufacturing.

Kinetis K20 on tinyK20 Board

Kinetis K20 on tinyK20 board

Some of the prototype boards did not work properly: the external 32 kHz oscillator was not starting. Resoldering the oscillator or MCU sometimes solved the problem, but not always. Until the problem was found by [Christian B.] (thanks!) :-).

For the tinyK20 board we are using a Kinetis K20 (ARM Cortex-M4) in a QFN48 package. The picture shows the device with the bottom ground plane:

QFN48 Kinetis K20

QFN48 Kinetis K20

The following picture shows the placement of the package on the board:

Package Position on PCB

QFN48 package position on PCB

Question: can you spot a layout problem in above image? ;-)

The QFN48 package looks like this:

QFN48 Package (Source: Freescale)

QFN48 package (Source: Freescale)

What is not obvious right away: On the package of the Freescale Kinetis K20 (MK20DX128VFT5) there is a connection on the outside:

Ground Pad on the outside

Ground 'pad' on the outside

Yup, looking carefully at the data sheet again, it is here:

Corner Edge Pad (Source: Freescale)

Corner Edge Pad (Source: Freescale)

That connection has no real purpose. I believe these pads are from the manufacturing/packaging process. I believe these are just the remainders of something holding the package with the die during manufacturing and then are cut off. The metal contacts are present twice on each side of the package, and are connected to GND (not documented, but easy to verify).

The problem is that in our design we have traces under that ‘edge pad’:

Trace under Edge

Trace under edge

It happened that there was some solder on that trace, reaching high enough to connect to the ‘edge pad’ above to make a short cut to the GND :-(.

Problem Point

Problem point

Solder was flowing from the ‘real’ pad to the ‘outside,’ and was able to get high enough in some cases to make contact with that ‘edge pad’. And because these ‘edge pads’ were not easily visible by the naked eye, the problem was not obvious. :-(

Once the problem was identified, it was easy to check/verify the boards. :-)


It is easy to miss tiny and hidden connection points on such small packages. Having traces under the ‘edge pads’ can be a problem, especially with prototype boards without solder mask. The problem is less likely to happen with a solder mask on that trace/pin, but still a potential problem. So we need to change the trace to make sure we do not run into that problem for the boards to be manufactured. And yeah, after the fact things are easy and obvious. ;-) I hope that publishing this article might save someone lots of hours finding the same problem.

Maybe you had a similar problem too? I want to hear about it. :-)

Happy Cornering :-)

PS: thanks again to Christian for his ‘Eagle Eyes’ and for sharing the problem with me.


Cisco is a software company. Surprised? Don’t be. Join DevNet to explore APIs, tools, and techniques that developers are using to add collaboration, IoT, security, network priority, and more!

soldering ,chips

Published at DZone with permission of Erich Styger, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}