Possible short between sys_vdd1_3v3 and GND killed C-SIP?
- This topic has 2 replies, 2 voices, and was last updated 4 years, 7 months ago by
.
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,
Attachments:
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!
- You must be logged in to reply to this topic.