THOR board design Power on

[HW1234]

1. By using our own carrier board, we were able to enter recovery mode, and THOR was discovered by the PC as an OTG. Can you explain that its power on timing is OK?

2. After using our carrier board for burning, we found that it would fail to burn and get stuck in the same position every time(

   

   ). Then the carrier board would lose power and pressing the THOR reset button would not work (the power supply of the carrier board is controlled by the module’s CARRIER_POWER-ON, and after it is pulled up, the power supply of the carrier board will be powered on sequentially);

3. After successful burning through the development kit, the module was moved to our carrier board and stuck in the same position, and the phenomenon was consistent with the above 2.

thor flash uart 202511281702.log (29.7 KB)

[KevinFFF]

Hi HW1234,

@HW1234

By using our own carrier board, we were able to enter recovery mode, and THOR was discovered by the PC as an OTG. Can you explain that its power on timing is OK?

Please check the power on sequence or the serial console log to confirm if the boot is okay.

@HW1234

After successful burning through the development kit, the module was moved to our carrier board and stuck in the same position, and the phenomenon was consistent with the above 2.

What’s the difference between the devkit and your custom carrier board?

[0000.949] W> PROD_CONFIG: controller prod table is empty in MB1 BCT.

This warning should be fine and it won’t block the boot up.
Could you share the full flash log when you flashed on your custom carrier board?

[HW1234]

@HW1234

fter successful burning through the development kit, the module was moved to our carrier board and stuck in the same position, and the phenomenon was consistent with the abov

1、flash and UART log

thor flash 202511281702.log (347.0 KB)

thor flash uart 202511281702.log (29.7 KB)

2、Our carrier board does not use an MCU for power on control timing. It is powered on step by step through the PowerGood of the power chip, starting with 3V3 (L53), followed by 12V, and finally 5V. Then, the module CARRIER_POWER-ON (L62) controls the power on of other power sources on the carrier board. This type of power on mode ORIN can start normally (ORIN does not have 3V3). During the power on process, PERIPHERAl-REET-N (L58) is NC on the carrier board. Is this possible.

[HW1234]

By observing with an oscilloscope, the place where the printing information stops, which is the time when the module actively lowers CARRIER_POWER_ON, completes the active raising of CARRIER_POWER_ON for about 800ms when the module is powered on. At this time, it should have nothing to do with the power on timing, right

[HW1234]

After examining the differences between hardware configuration and development kit, it was found that the development kit used G4 (Boot_CAIN_1), G5 (Boot_CAIN_SEL), and C55 (Boot_CAIN_0), while our carrier only used C55 as a regular GPIO. We are unsure if this will affect the MB1 BCT

[HW1234]

When the serial port printing stops, pulling down SYS-REET-N has no effect, only power off or pulling down MODULE-POWER-ON. The module also enters thermal protection, and the carrier board A61 (SYSTEM OC-N) is not used. Is this related to this? Does SYSTEM OC-N have to be pulled up externally

[KevinFFF]

[flash_bsp_jetson-t264_die0]: [executeShellCommand(177)] : stdout: b'Sending blob\nERROR: might be timeout in USB write.\n'
..
[flash_bsp_jetson-t264]: Flashing finished Unsuccessfully!!

From the log you shared, the flash is unsuccessful.

It fails in early boot stage(MB1) on the device as following.

[0000.949] W> PROD_CONFIG: controller prod table is empty in MB1 BCT.
[0000.955] I> Task: Pad voltage init
[0000.958] I> Tas

Please check the HW power-on sequence.
Additionally, sharing the oscilloscope waveform will be very helpful in highlighting any discrepancies from the devkit’s behavior.
I will also request our HW team to check your status.

[HW1234]

thank you

Oscilloscope image 1, yellow is 3V3 (SYS_VIN_SV), after 60ms, green 12V (SYS_VIN_HV) and blue 5V (SYS_VIN-MV) are powered on

Image 2, yellow 5V (SYS_VIN_MV), followed by a delay of more than 50ms through RC for the green MODULE_POWER_ON. Then the module starts to power on, and after the power on is completed, the blue CARRIER_POWER_ON is pulled up. At this point, the carrier board starts to power on, and after about 800ms, the module actively lowers the CARRIER_POWER_ON.

Afterwards, lowering the SYS_RESET_N of the module cannot cause the module to reload Flash. Only by shutting down the power and restarting or lowering the MODULE_POWER_ON can the above process be repeated.
Our module on the carrier board has a SYSTEM_OC_N（L52） of NC and no other overcurrent detection protection.
Because when the fault occurred, MODULE_POWER_ON remained at a high level, it is suspected that it entered Thermal Shutdown due to thermal protection

Our carrier board POWER_BTN_N(L61)、PERIPHERAL_RESET_N（L58）、MODULE_SLEEP_N(J60)、SYSTEM_OC_N（L52）is NC

[HW1234]

YELLOW is MODULE_POWER_ON,GREEN is CARRIER_POWER_ON, BULE is SYS_RESET_N.

After the module pulls up CARRIER_POWER_ON for 19ms, the carrier board pulls up SYS-REET-N, and the module begins to enter power on reset. After about 800ms, the module pulls down CARRIER_POWER_ON because SYS_RESET_N has passed through the logic device of the carrier board, so SYS_RESET_N is also pulled down

[HW1234]

Our power supply on the carrier board was not connected to the module for testing. We saw that there is a PMIC control on the carrier board in MB1. I wonder if this is the cause of our problem?

[HW1234]

We did not use the MCU recommended by the development kit for controlling timing on our carrier board. The power on timing is achieved through the PowerGood of the power chip itself combined with RC charging

[ChrisB_NV]

Oscilloscope image 1, yellow is 3V3 (SYS_VIN_SV), after 60ms, green 12V (SYS_VIN_HV) and blue 5V (SYS_VIN-MV) are powered on

This looks ok.

Image 2, yellow 5V (SYS_VIN_MV), followed by a delay of more than 50ms through RC for the green MODULE_POWER_ON. Then the module starts to power on, and after the power on is completed, the blue CARRIER_POWER_ON is pulled up. At this point, the carrier board starts to power on, and after about 800ms, the module actively lowers the CARRIER_POWER_ON.

The RC for MODULE_POWER_ON looks ok also. The circuit it drives has VIH of ~2V and ultimately results in the CARRIER_POWER_ON signal going high, which you do see on your capture. As mentioned in the Design Guide, CARRIER_POWER_ON pulls up to 3.3V on the module, and that rail is controlled by the power sequencer. CARRIER_POWER_ON going low means the power sequencer deliberately turned the 3.3V rail off for some reason.

Afterwards, lowering the SYS_RESET_N of the module cannot cause the module to reload Flash. Only by shutting down the power and restarting or lowering the MODULE_POWER_ON can the above process be repeated.

This makes sense - the SYS_RESET_N does not affect the power sequencer. The power sequencer can only be recovered by the MODULE_POWER_ON or a power cycle.

The input signals to the power sequencer that can cause shut down are overtemp detected by a thermal sensor monitoring Thor and its own local temp, the carrier asserting VDDIN_PWR_BAD_N low, or the Thor SoC itself triggering the shutdown.

Can you confirm that the carrier board does not assert VDDIN_PWR_BAD_N low?

Are you able to check if the MODULE_SHDN_N signal goes low? This would indicate that an input signal to the power sequencer caused it to shut down. Otherwise, the power sequencer itself has its own thermal shutdown as well.

What is the cooling setup when this happens? Would you be able to provide a photo of the module and its cooling solution?

Our power supply on the carrier board was not connected to the module for testing. We saw that there is a PMIC control on the carrier board in MB1. I wonder if this is the cause of our problem?

Can you please explain this further or perhaps provide a diagram to show what you mean?

[ChrisB_NV]

Are you able to monitor the THERM_ALERT_N signal also? If this is related to thermal, the ALERT could go low just before the MODULE_POWER_ON goes low.

[HW1234]

THERM’ALERT-N cannot be monitored, it has been disabled on the carrier board

@ChrisB_NV

The input signals to the power sequencer that can cause shut down are overtemp detected by a thermal sensor monitoring Thor and its own local temp, the carrier asserting VDDIN_PWR_BAD_N low, or the Thor SoC itself triggering the shutdown.

1、

Yellow is CARRIER_POWER_ON， Green is VDDIN_PWR_BAD_N ，Blue is MODULE_SHDN_N

As you can see, when a fault occurs, VDDIN_PWR_BAD_N and MODULE_SHDN_N are at a high level and there is no problem

2、THERM_ALERT-N carrier board is NC and cannot be detected.

3、

Yellow is CARRIER_POWER_ON， Green is VDDIN_PWR_BAD_N ，Blue is MODULE_POWER_ON

It’s a bit strange, from the waveform, the voltage of VDDINuPWR_SAD-N is only 4V, but in fact, the module’s internal 10k is pulled up to 5V. Our design is like this, theoretically VDDINuPWR_SAD-N should be 5V.（5V_PG is Power_Good of The 5V power module，is OD）

[HW1234]

@ChrisB_NV

What is the cooling setup when this happens? Would you be able to provide a photo of the module and its cooling solution?

1、

The module casing is cold during a malfunction

[HW1234]

At present, there is no fan connected, only the radiator shown in the picture is used

[HW1234]

I also checked that there was no drop in 12V(SYS_VIN_HV), 5V（SYS_VIN_MV）, and 3.3V (SYS_VIN_SV),after powering on

[KevinFFF]

Hi HW1234,

Is the current issue localized to a “specific module” or is it affecting “multiple modules”?
The root cause may stem from the PMIC within the module.
Please acquire more Thor modules for cross-validation.

[HW1234]

@KevinFFF

Is the current issue localized to a “specific module” or is it affecting “multiple modules”?
The root cause may stem from the PMIC within the module.
Please acquire more Thor modules for cross-validation.

Is the current issue localized to a “specific module” or is it affecting “multiple modules”?
The root cause may stem from the PMIC within the module.
Please acquire more Thor modules for cross-validation.

I have tried two modules, and they can start normally on the development kit’s carrier board. However, when they are placed on the carrier board we designed, they get stuck and cannot start normally

[HW1234]

Is there any other possibility that the module will automatically lower the power supply of the load board after loading flash for 800ms?
Is it possible that the module needs to verify other information on the carrier board, such as overcurrent detection, because our carrier board was not designed?