Certain part numbers of the TX1 stop working (will not power on)

We have purchased a lot of NVIDIA TX1s in the past, but on the latest order we received (P/N: 135-0657-000 R1) and have damaged a lot of the boards. It seems that some of the boards that we used to get in the past (P/N: 135-0620-000 R2 ) were more reliable.
Have there been any issues with P/N: 135-0657-000 R1? Does the R1 mean it is Revision 1? We have a few part numbers with R4 that also seem more reliable.

It is hard to explain how the boards were damaged. They work fine for a few days, and suddenly stop working. We have been using these on a new PCB, but the schematics for this new PCB have been working on a few other designs without any issues. For this new PCB, we have two different TX1s on a PCB and they both run off of 12V(with their own independent filtering capacitors). I have run the R2 board on both ports and it works fine, but the R1s seem to stop working after being used on and off for a few days. I am not sure if these are more prone to being damaged by static electricity or are more sensitive in general.

Hi ocampo,

Did you use Jetson TX1 module + carrier board, or just module + your own carrier board? And what’s the version number (699-82180-1000-xxx ) of corresponding R1, R2 board? Did you check the input current on damaged board? That is useful clue.

Hi Trumany,

I used the TX1 module with my own carrier board, but verified that it had stopped working with an NVIDIA Dev kit. The version number for the one that has been working reliably is 699-82180-1000-100 N(R2) and the one for the ones that have not is 699-82180-1000-400 N(R1). The units draw about 330mA @12V. When the power button is pushed it goes up to about 345mA for about 0.5sec and then drops back to 330mA.
Thank you for your help,

  • Felipe

I can’t offer details but do know for sure that R4 and R1 modules respond differently at power-up. We use the modules with a carrier card from Leopard Imaging. With this module the R4 SOM’s power-up immediately (no waiting for the Power Switch) which is the desired behavior for us. The R4 module does not auto-power-on.

Sperok,

That is what I am wondering. Like you mentioned, the R1 respond differently at power-up, maybe they also have different power suppression or circuitry that makes them more prone to being damaged. NVIDIA may have identified these issues and made changes to R2 and all the later revisions(if R really does stand for revision), which is why we have not seemed to encountered these issues with R2s.

Hi ocampo, thanks for you info. So all fails happened during work on your own carrier board, right? What’s the failure rate? Can you tell your own carrier board is designed based on which version, B02 or B04?

If your own board design well followed the OEM DG, the power sequence will be same as showed in it.

Truman,

I am guessing our design was based on the B02. We did the design based on the original development kit, but I don’t see the B02 Design files on the website anymore.
We have seen this issue on the carrier board as well(once or twice), but we don’t work as much on the NVIDIA dev kit as we do on our own carrier board, so we don’t see it as often. Also, we are currently testing different aspects of this new carrier board, so we interact more with the PCB, which maybe caused some ESD issues? We have seen this issue on 5 R1 modules and 0 R2 modules so far.

I just did a new design of the carrier board and included D13(zener diode) from OEM DG(B04), which I don’t think was there before(B02). I doubt this is causing my issues, but it can’t hurt to add it in.

Does the R refer to revision?

D13 is included in B02, you mean your old design does not include D13? That is a serious potential risk. The voltage tolerance of some capacitors on VDD_IN in R1 module is less than R2. That could be the reason of why R1 fail but R2 not. If your design needs often plug/remove, to enhance ESD protection is necessary, suggest to add more Zener diodes close to power DC Jack on carrier board.

As for the failure modules, you can file RMA request following the procedure from here: https://developer.nvidia.com/embedded/support In the event of RMA. We can check the root cause only when get the samples.

R is related to manufacturing, no need to care in this case. The board version number is -xxx in 699-82180-1000-xxx.

Our new design has the zener diode and we are still seeing the same issue. We have a 12V DC-DC supply that is very stable. When I look at it with a scope there is about 100mV pk-pk(max) and there are no noticeable dips or spikes at power up. It takes about 20ms to achieve the 12V. We are waiting about 1 second before engaging the B50-POWER_BTN, which should be plenty of time. Could the issue have something to do with the auto power on that sperok described on the R1 modules? Since it does not wait for the proper power sequence potentially something could get damaged that way?

Hi ocampo, heard from other thread seems this is related to U117 damage in module? U117 is a buffer for VIN_PWR_BAD#, if it is broken the power sequence will fail. How do you find it could be U117? You already opened module and check?

To compare if the VIN_PWR_BAD# failed, please measure the power up sequence with good and bad -400 module as figure 4 of OEM DG showing, and also you can measure if the signal is shorted to GND or high voltage.

Trumany, Yes. One of the boards smelled like it was burning, so I opened the heat plate and noticed that U117 was completely damaged.
I just noticed that the power input for VIN_PWR_BAD# is from 0-5V. We have had that connected to 12V for over a year and that has worked fine until now. There must have been a change in the voltage range of that buffer chip(U117), which is now causing it to get damaged. I have been testing with VIN_PWR_BAD# tied to a 5V line and it has been working so far. Thanks for the help!

Good to hear that.

U117 is not included in -100 module, its supply voltage is 5V.

And I’m curious about why you connect VIN_PWR_BAD# to 12V? In fact, the 5V pull-up of VIN_PWR_BAD# is in -400 module (no need pull-up in -100 module) , you mean you added a 12V pull-up to it on carrier board? It seriously violates the reference design. I think this is the root cause.