Possible short between sys_vdd1_3v3 and GND killed C-SIP?

[Aleix]

Hello there folks,

First of all I hope everyone reading this is safe and sound in this troubling times. Since we’ve had quite a long confinment, I used the spare time to design a nice evaluation board for the C-SIP.
Boards arrived yesterday and I got hands on to mounting and testing.

I Started the design from al already produced board using the C-SIP, and to my surprise I think I might have accidentally killed the device.

I suspect the board had a short between sys_vdd1_3v3 and GND. Let me reproduce the steps taken and see if that’s indeed a possible cause:

– Powered up board et 5V and current limit at around 50mA, saw current peaking and voltage falling down at about 2.5-3V (here’s where I thought okay it needs more juice, the ethernet PHY I use alone consumes quite a bit)
– Disconnected everything to take a peek to see if anything appeared to be shorted, didn’t seem so. (mistake)
– Rose current limit of the PSU up to 150mA. (again, mistake)
– Upon power-up and a very brief current spike, current consumpption fell down to 25mA. I started de-soldering everything non-essential for the C-SIP to power up and here’s where I think I saw a bridge between sys_vdd1_3v3 and GND.
– Ufortunately I was with the hot air gun and the tweezers removing that component, so there’s no way to confirm that 100%.

After reconnecting power, the board was drawing close to 0 mA from PSU.

My question being:

Is it possible that a short between the mentioned power rails killed the PMIC inside the SIP in a way that the part is drawing almost close to 0mA?
Of course there’s no voltage on any of the power rails coming out from the C-SIP, and since I started the design from an already working board I was dumb enough not to include any test points. (again, mistake)

Could anyone confirm that this is a possible explanation so I can proceed and assemble another board or on the contrary do some more forensics to try figuring out another possible cause?

Thanks,

• This topic was modified 4 years, 7 months ago by Aleix.

Attachments:

1. 

   Capture-1.png
   

[Aleix]

Hi everyone,

Still untested but I think I found the issue (at least a major one). A while ago I started porting my Eagle libraries to managed libraries (to be able to add a 3D model of the device) and updating all footprints to comply with IPC7351.

I imported the C-SIP device from the Octavo-Systems library to my library NOT realising that in the BGA400 footprint (and all other footprints in the library)  ball A1 is not in the upper-left corner but in the lower-left corner. Changed the pad dimensions and added the corresponding courtyard and silkskreen marking ball A1 in the upper-right corner.

So, without having assembled another board, I think it’s quite safe to say that having the part placed in the board rotated 90º CCW seems a pretty solid root cause for this issue.

Please consider updating the library, this is a non-standard und unsafe practice (almost as evil as a center negative barrel jack :P) and can lead to issues in the design and assembly stage.

Since IPC guidelines and standards are not free, for those interested here’s a summary that can be handy when drawing footprints.

Have a nice weekend!

Attachments:

1. 

   Component-Zero-Orientations-for-CAD-Libraries.pdf
   

[Neeraj Dantu]

Aleix,

Thanks for pointing this out. The symbols we have do indicate the pin number A1. But, the origin should be as you pointed out on the upper left corner. We are glad that you were able to find the issue. We will add this change to our next release.

Best,

Neeraj

[Author]

Posts