Custom TX1/TX2 board: TX1 does not boot

Greetings –

I am working with a custom TX2 carrier board design that was closely derived from another custom TX1 carrier that has been working without any problems. However, while trying to test the new carrier board (with a spare TX1 module), the TX1 module does not appear to boot.

The power sequencing logic is all the same: a PMIC watches the 12VDC main power rail and pulls VIN_PWR_BAD# low until it exceeds 9.2V. The power button momentarily pulls POWER_BTN# low, and CARRIER_PWR_ON enables a cascade of other rails (5V, 3.3V, and 1.8V) to come up, each after the previous is stable. (On the previous carrier board everything worked at 11.1VDC, and I know the development board gets 19.2V, so I figure 12V should be fine.)

When the power button is pressed, CARRIER_PWR_ON goes high and the power supplies come up. The TX1 module power consumption appears to be about 1.5W which is about what I expect its idle level to be. (If I remove the TX1 module and drive the CARRIER_PWR_ON signal high to turn on the power supplies, I get a baseline power consumption for the rest of the carrier board so I know this 1.5W is just the TX1.)

However, I get no activity on either UART0 or HDMI so I see no indication that the TX1 is doing anything. I also see no link lights on an RJ45 Ethernet port if connected to a hub, and a USB keyboard does not appear to respond (caps lock and scroll lock buttons do not light).

The TX1 does appear to respond to some events: if I press and hold the power button, it will turn off after several seconds. Also, the reset button appears to cause CARRIER_PWR_ON to cycle.

If I move this TX1 back to its development board, it comes up fine. Also, two of these custom carrier boards appear to have identical behavior so I suspect it is the carrier, not the TX1 (though I do have another TX1 I plan to test with).

Some observations about the system that I thought might be relevant:

  • VIN_PWR_BAD# only appears to come up to 2.6V when the power supply is stable. The PMIC monitoring the input power is open-drain, so it should allow the voltage to come up whatever the TX1 module pulls it to. This voltage must be created by the TX1, and I'm not sure if this means something is fighting it. On an oscilloscope, it appears stable.
  • CARRIER_PWR_ON is really weakly driven. Touching a multimeter to a testpoint on this signal is enough to cause the board to reset. Should I be pulling this up to make it stronger?
  • New to this design is a supercap (0.22F, 3.3V) attached to VDD_RTC (pin A50). I do not see any voltage being applied to this when the TX1 otherwise should be on. Would having this at 0V instead of floating cause any issues with the TX1's power supervisor? The value on the development kit is 0.08F -- is 0.22F too large?
  • There is a heat sink attached but no fan connected. I don't think the TX1 can detect this so I doubt that would keep it from starting.
  • CHARGER_PRSNT# is left floating, but I can pull this down if it would help.
  • SLEEP# and CARRIER_STBY# are left floating as was done on the previous working design. Could it be suspending before it starts booting?

Can anyone see anything concerning here or suggest anything else I might want to look for?

Thanks.

Hi, it looks like the strapping setting problem, do you check the strapping chapter in OEM DG? All strapping pins design should follow that. Also you can refer to the strapping part of this comparison: http://developer.nvidia.com/embedded/dlc/jetson-tx1-tx2-interface-comparison-and-migration-1-1

I’ve made some progress on this – the TX1 now boots on one carrier board at least (still need to test the other two). I was plugging a USB-to-1.8V UART cable into UART0, and it looks like the footprint for that connector got flipped from the previous design to this one. Unplugging this helped. I’m not sure exactly what the mechanism was, but I suspect that this led to a bad ground reference which may have caused the TX1 to misinterpret one of the strapping signals.

I’m still puzzled over the very weak drive strength on CARRIER_PWR_ON – that makes me wonder if the board will be vulnerable to resets in very (electrically) noisy environments. The 2.6V level on VIN_POWER_BAD# is also still a concern. However, as long as the thing is running I can take at least the next step forward.

TLDR: hardware problem!