Power-up sequence

Kindly ask to get confirmation on my understanding of the power-up sequence.

  1. Main power source is connected – using DC Jack VCC_DCIN is powered from the AC/DC adapter, and the voltages goes (through FETs) to VCC_SRC_FET. VDD_3V3_PD is also created from VCC_DCIN. VCC_SRC_FET is used to create 5V_AO, and 3V3_AO is generated from 5V_AO.
  2. The carrier releases VDDIN_PWR_BAD_N which will be used later by the module.
  3. When the user press the power-button, the carrier VIN_PWR_ON signal is created, and switches on the supplies for SYS_VIN_HV (VCC_SRC) and SYS_VIN_MV (VDD_5V), then the carrier releases ‘MODULE POWER_ON’.
  4. When the module internal supplies are stable, and the VDDIN_PWR_BAD_N is high, the module asserts ‘CARRIER_POWER_ON’, which directly enables the VDD_1V8 and VDD_3V3 supplies, and is input to the SRC0GS22D. (The module also de-asserts SYS_RESET_n, but it is still asserted low by the carrier)
  5. When all supplies are OK, the carrier releases the SYS_RESET_N, and PERIPERAL_RESET_N, and the SOM starts running

Kindly asks for explanation on the usage of POWER_BTN_N input to the SOM - what are the purposes and usage.
(I assume that this is for long-power-button-off event)

PERIPERAL_RESET_N is not used on Xavier devkit currently, it is input pin to module from carrier board.
POWER_BTN_N is connect Xavier, in normal power on case, it is follow and same the BUTTON_POWER_ON* signal with a delay. it is used when system enter/exit SC7 , such as you press button a little time enter/exit SC7.

others understanding should be OK.

Thanks,
I try to follow the ‘Simplified button circuitry’, and added the D-FF which creates the BUTTON_POWER_ON* (in OD with the power-switch).
I think that there are missing some pull-ups, and have added them.

Kindly ask for a quick review, and if possible - for explanation of the need of the BUTTON_POWER_ON* circuitry.

Hi, there is a full design of simplified button circuity in OEM DG as you can see. Please follow it totally. The BUTTON_POWER_ON* is from power button.

Thanks.

I understand that this signal goes to Power-Button Supervisor or MCU, and they asserts VIN_PWR_ON.

I would like to understand what internal/output of the SOM is affected by the BUTTON_POWER_ON*.

I assume that in case of 10-second press, the SOM de-asserts CARRIER_PWR_ON to signal power-off event.

BUTTON_POWER_ON* is to enable MODULE_POWER_ON which is the enable of PMIC in module.

I’ll accept this as ‘no comment’.

I think that OP is correct. The simplified button circuity in OEM DG is missing a pullup on the BUTTON_POWER_ON* net. I believe it should be a 10k resistor pulled up to 3V3_AO. Adding this resistor to the OEM Design guide would help folks more clearly understand the simplified power button circuit.

The OEM Design Guide should be TOTALLY re-designed, from scratch, using components which are commonly available today.

We’ve sent the BOM to a contractor in China, and he had problems to purchase many components, e.g. U504 APW7307AZI-TRG, and Q512/520 - AOE6930, and we got to purchase them from suppliers like “AliExpress”, and we’re not sure on the quality of those.

As a contractor (Board/System Designer), if I’ll have an option - I’ll have to use alternative SOM - until having a good reference design.

Please consider this as a RED FLAG !!!

Hi ishay,

Dev kit carrier board is for customer to do development work with module not for production, it can be a reference for customer to make design more conveniently. Customer can choose other components if the characters are same/similar to the reference ones. As for U504 and Q512/520, it is not said in OEM DG that should be exactly same to that on dev kit.

I could ignore this thread and go on, but I care for Nvidia.

Customers don’t have resources to learn the full spec of the processor and the module board, and to design their carrier-board from scratch.
Customers want to put most of the resources in adapting the development kit to their specific application - e.g. having more cameras, more USB3 ports etc.
Customers expect to be able to take the carrier-board design, and be able to get a running system - with all power planes, Ethernet, debug port etc - with no need to design those from scratch.

My situation can be taken as example:
We’re doing contract-design, and a customer of us had an application which he started the investigation, and came to us with request to take the design of the carrier-board from the Dev kit, keep most of the circuitry such as the power supplies, Ethernet, M3, USB, and so on, and apply ‘minor modifications’, like adding additional M3. It was supposed to take very short time.

In actual, it took me a lot of time, most of it to understand how will the system get out of reset - as I used the ‘Simplified button circuitry’ - and there’s missing pull-up, and no explanation on this half-page, dense diagram - this was my request in this thread!

Other issues were also raised in this forum, and closed after a long time/discussion.

And now, when the PCB is in production, I’m getting information from the purchasing team that they can’t find reliable source to dual-FET used in DC-DC converter, and other ‘exotic’ parts, which are not supposed to be in reference design.

Could it be that I’m alone in this thinking?
I’ll stop replying on this thread - Nvidia got my mail-id, and are welcome to contact.

Wish you good business

Sorry for any convenience on design, we are glad to hear advice from customers and so improve our support. Regarding the questions, there is internal 100k pull-up on pins SR* and PB* of button controller (SRC0GS22D), so no need to add external pull-up on module_power_on line.

And about the sourcing problem, the components on dev kit even are validated, we can only suggest customer to purchase the ones have same or similar characters if the ones on dev kit are unavailable for customer. Hope you can understand this. Thanks.