Questions regarding TTP sensor reset configuration and thermal zone definitions on custom board

Robotics & Edge Computing Jetson Systems Jetson Thor
,
1

Hi NVIDIA Support Team,

We are currently working on a custom carrier board based on the Thor T5000, running software release r38.2. We are tuning our thermal management strategy and have a couple of questions regarding the hardware thermal sensors and trip points.

1. TTP Sensor Reset Configuration: Is it possible to disable the TTP (Thermal Trip Point) sensor hardware reset function? If disabling it is not supported or not recommended, is there a way to increase the temperature threshold for the TTP reset? (If so, could you point us to the relevant device tree bindings or BPMP configurations?)

2. Thermal Zone / Sensor Definitions: We are monitoring various thermal zones but would like to confirm their exact physical definitions or the specific clusters they represent on the Thor SoC. Could you clarify what the following temperature readings specifically refer to?

  • Tj

  • TCPU

  • TGPU

  • Tsoc012

  • Tsoc345

Any documentation links or guidance on this would be greatly appreciated.

Thanks in advance for your help!

2

Here’s 38.2 Thermal Docs

And Thermal Design Guide pdf

4

企业微信截图_17763919135095
企业微信截图_17763919135095726×638 94.4 KB

How is TTP temperature measured and what is the software shutdown policy based on it?

5

We suspect the hard reset might not be triggered purely by the internal T.SoC hitting the 118°C limit. During our stress tests, our external thermocouple measurements showed that the TTP surface temperature reached 87°C just before the system performed a hard reset. Meanwhile, the internal SoC sensors we monitored via sysfs were still well below the 118°C threshold.

This leads us to a few follow-up questions:

  1. Is there a hardware-level protection mechanism (or BPMP logic) that signals the PMIC to force a hard reset specifically when the TTP exceeds the 80°C limit mentioned in Table 2-1?

  2. Or perhaps the shutdown is triggered by a combined condition (e.g., the algorithm determines cooling is unreliable if TTP > 80°C AND T.SoC > 90°C)?

  3. Is there any specific register (in PMIC or BPMP) we can read after the reboot to pinpoint the exact source of the last thermal trip?

Any insights into the internal logic of this reset would be greatly appreciated. Thanks!

6

This holds some information.

https://docs.nvidia.com/jetson/archives/r38.4/DeveloperGuide/SD/PlatformPowerAndPerformance/JetsonThor.html#thermal-specifications

sudo dtc -I fs -O dts -o ~/live.dts /proc/device-tree
grep thermal live.dts

grep . /sys/class/hwmon/hwmon*/*

grep . /sys/devices/platform/bpmp/bpmp:i2c/i2c-5/5-004c/hwmon/hwmon*/*

grep . /sys/devices/platform/nvtherm-oc-event/hwmon/hwmon2/*
7

On Jetson products, the TTP acronym stands for Thermal Transfer Plate, not Thermal Trip Point.

Per the last sentence of section 4.5 of the Thermal Design Guide: The Thor SoC thermal trip settings cannot be altered. These settings are implemented by NVIDIA to meet product safety and reliability standards.

Tj is explained in section 1.3.3: The Thor SoC junction temperature (Tj) represents the Thor SoC die temperature read from the highest of the internal temperature sensors.

TCPU, TGPU, Tsoc012, and Tsoc345 are temperatures from the the various areas of the SoC: CPU, GPU, and SOC domain. SOC includes memory controllers, encoders/decoders, etc. Their locations on the SoC die are not documented in the Thermal DG since the TTP is the direct interface to the cooling solution, not the SoC die.

@whitesscott shared the software and hardware thermal documentation links (thank you).

As per Note 2 in Table 2-1, the T.TTP temperature is the max to maintain specified performance and reliability. Exceeding this temperature will not necessarily cause a system shutdown but will result in reduced performance (due to throttling) before a shutdown could trigger. Section 4.3 covers software thermal management and 4.4 covers hardware throttling.

In section 4.5:

The following thermal trip mechanisms have been Implemented:

  • Internal sensor-based thermal trip. Failsafe thermal trip is guaranteed by using the thermal trip signal directly from the SoC to the PMIC. After the failsafe thermal trip, the system will reset without the user pressing the power button or equivalent input.
  • T.diode and temperature-monitor-based thermal trip. When the external temperature monitor detects that the T.diode temperature is above a pre-programmed thermal trip, the monitor’s THERM output signals the PMIC to reset the system without any software control. This is a backup mechanism to the internal sensor-based thermal trip, so it is intentionally margined to a higher temperature to avoid contention with internal sensor-based thermal trip.

I will check with the software team supporting the forum.

9 
cd Linux_for_Tegra/source/hardware/nvidia/t264/nv-public
nv-soc/tegra264-soc-thermal.dtsi
nv-soc/tegra264-soc-thermal-shutdown.dtsi
nv-soc/tegra264-soc-thermal-slowdown-disable.dtsi
nv-soc/tegra264-soc-thermal-trip-event.dtsi
nv-soc/tegra264-soc-thermal-slowdown.dtsi
include/kernel-t264/dt-bindings/thermal
include/kernel-t264/dt-bindings/thermal/tegra264-thermal.h

lsmod|grep thermal
thermal_trip_event     12288  0
tegra_bpmp_thermal     12288  0

Linux_for_Tegra/source/kernel/kernel-noble/drivers/thermal/tegra/tegra-bpmp-thermal.c
Linux_for_Tegra/source/kernel/kernel-noble/drivers/thermal/thermal_trip.c
10

There isn’t a BPMP or PMIC side “last thermal trip source” register you can read after reboot. The reset cause is only latched in the PMC (PMC_IMPL_RST_STATUS and the reset trace buffers), and in current Jetson Thor releases this is not exposed to Linux, so in practice you can only see it via the early MB1 UART log (rst_source / rst_level) printed at boot.