0
\$\begingroup\$

I tried to build an open-source (and unfortunately not longer maintained) USB Audio interface (https://github.com/freeDSP/freeDSP-INFINITAS).

The project is built around a XMOS chip XE216-512 and a Lattice MachXO2 FPGA. While I did not thoroughly study the project's code/schematic, I believe the XMOS is handling the USB to I2S (or other protocol) conversion, and the FPGA manages the routing of audio channels to and from the external ADCs and DACs (located on an extension board that I still haven’t build).

I successfully assembled the PCB and flashed the two chips. Upon connecting the board to my computer, it initially functioned (Windows detected a new USB device called Infinitas) but just for a bunch of seconds. After subsequent tests, involving different computers and different USB cables, I noticed that one of the voltage regulators on the board caught fire.

The board contains three voltage regulators in SOT23 packages: two are used for the XMOS chip (3.3V and 5V) and one (3.3V) is used for the FPGA and its associated circuitry (a CS2100, and a pair of PCA9545A).

The regulator that caught fire was the 3.3V regulator used for the FPGA/CS2100/PCA9545A, a NCP1117LP.

I noticed that the FPGA was dead after the incident, and there was a short between 3.3V and GND, even after removing the dead regulator. Removing the FPGA from the board resolved the short. I have since acquired and soldered a replacement FPGA and a new voltage regulator (LDL1117S33R, should be equivalent), but before powering it up, I have some questions:

  1. do you think the regulator died because I used 12V DC input (that's what the project documentation calls for), and the 3.3V regulator needed to dissipate too much heat for this large voltage gap? The input voltage is solely directed to the three aforementioned regulators, and I guess that 7V-8V would suffice for 5V and 3.3V regulation, resulting in less heat generation.
  2. what else could have caused the chip to die? I checked for shorts all over the PCB before the first power up, and everything seemed fine. Also, the flashing of the FPGA was successful.
  3. since I still haven’t build the associated expansion ADC/DAC board, do you think a reason why the FPGA could have been damaged is because no ADC/DAC were connected to its data bus?
  4. apart from damaging the old FPGA, is there a possibility that I also damaged the CS2100 and the PCA9545A chips? Is there a way to determine, from their datasheet, if they have a sort of protection that the FPGA didn’t have for this sort of incident?
  5. if those two chips are indeed damaged, is there a possibility that they could now damage the new FPGA and the new regulator, or both?

sorry for my somewhat paranoid concerns about the FPGA chip, but since I don’t fully understand what happened when the regulator died, and why the old FPGA died too, I’m now trying to take care of this new (pricey) FPGA chip

\$\endgroup\$
1
  • \$\begingroup\$ Is the 12 V supply used directly for anything? Are you sure that the 3.3 V and 5 V regulators were not accidentally swapped? I guess you have soldered the XMOS and Lattice chips on now, but if not then you could check the voltages on their power pins before installing them. It's also worth going over the PCB with a magnifying glass or under a microscope after soldering to check for any solder spatter that could be creating a short circuit, and for poor solder joints. \$\endgroup\$ Aug 12 at 19:23

2 Answers 2

2
+25
\$\begingroup\$

Without the schematic, layout, BOM and physical board, all comments are wild guests, but here is my line of thought.

First, I wouldn't assume is proper board assembly. Maybe there are some bridge, component reversed, etc.

Second, I wouldn't assume is that you have a single issue and both problems are related to that unique issue.

How I would approach this issue is step by step. Start by soldering the power supply. Power it up with 12V, what does happen? What happens if you load it up? Then, I'd had parts one after the other. Debugging is an art, it takes time and patience. So take your time!

I would also be very careful with the manipulations to the board. You mentioned that many rails are shorted, I assume you use the beeper in your DMM to test it. I know many beepers model (even Fluke's one) that output more then 3.3V. If it is a DMM more directed toward electrician, you could blow your board with the beep beep. I would also be careful with ESD. Even if in debugging it's rarely the issue, ESD can give odd behavior.

Regarding your questions:

  1. I doubt your LDO blew up only for the 12V. You can do the power dissipation calculation quickly, but, for an LDO to blow up, there is something else wrong. Many have short protections and over current protection. If yours has it, I would be very surprised that it blew for too much of power. The most likely scenario would be incorrect pinout or wrong package. 2)As mentioned, your beep-beep could have blown your chip. Be careful for reverse polarity of that thing too! After a catastrophic failure of an LDO, there might have been the 12V to go through (at least, I wouldn't consider it impossible). Footprint/BOM is usually the main cause in new board release failure. Improper design can also be an issue.
  2. I would be very surprised if so. The digital links doesn't have the potential to blow a PCB. If it was supposed to send signals to control your power supply (unlikely) it might be an issue, but digital lines by themselves wouldn't blow a whole board. 4)Yes, they might have been damaged. Since nobody knows exactly happened at the failure of your board, we can't conclude any chips are still good. Usually, when you have one who gets killed, it often protect the others, but you can't be sure.
  3. I don't know how exactly they are connected. I would say, maybe, but unlikely. If they are only digitally connected, the only failure I could see is that they blow your LDO again and the same failures occurs. I wouldn't take the chance, time is more expensive then those chips.

My advice, from where you are, what I would do is:

  1. Beep-beep test a virgin PCB (at least for PSU and some critical traces that could have lead to the issue like power)
  2. Take a virgin board and solder only your power supply circuits
  3. Test this board with some loads. (solder dummy resistors). Ensure the current consumption is within specs.
  4. Once functional, solder your FPGA, do not solder anything not required for the FPGA to run. Then, test it again. Ensure the current consumption still makes sense.
  5. Add the remaining chips one by one and test. You can skip some steps, but the more you skip, the likelier you are to hit that failure.

Good luck!

\$\endgroup\$
0
\$\begingroup\$

My answer is rather sparse; sorry about that. I can't competently answer all your questions. Otherwise:

Q1: A linear regulator does not usually die because of an output short; the thermal protection should save it. Usually it can die because of: inverted input voltage, input voltage above the absolute maximum, or incorrect power sequencing (i.e. output voltage present before the input voltage. This can happen during programming if you do it in-circuit. Some LDOs are immune to this problem, some are not). In any case, something akin to a latchup occurs and the chip is fried.

Q4: they may be damaged, but keep in mind that FPGAs are particularly stringent in power supply requirements. Since the short no longer exists after you removed the FPGA, I'd bet that they are fine.

In general, if you are afraid of ruining another FPGA: add an crowbar circuit after the NCP1117LP. If the output voltage is to rise 10% above the expected one, the crowbar should pull the line dead down through a hefty MOSFET. Make the crowbar circuit on a separate onsie PCB, test it in isolation, and then add it to the rail it must protect. You can even test it on-site if you still haven't soldered the FPGA and you can tweak the output voltage of the NCP1117LP, but I believe just careful soldering and DMM checking can ensure you've protected the rail.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.