Hey, I am using a custom TX1 carrier board that is constantly printing this message to syslog: WARNING - Battery Over Current Limit hit, please refer to the Jetson Power management application note
It only prints the message when put under high loads. When the board is idle, the message doesn’t appear. We do have batteries in our device, but the message appears when they are both plugged in and unplugged.
I have found the section of the device tree file, tegra210-jetson-tx1-p2597-2180-a02-devkit-24x7.dts, that this warning message comes from, which is sysedp_reactive_capping@3 (very last section).
I looked up sysedp_reactive_capping and it refers to some battery management system that I am not familiar with.
Does anyone know the details about this section of the dts file?
Is there any downside to removing this section of the dts file?
I tried removing it and didn’t notice any differences aside from the message disappearing, but I imagine it is a bad idea to remove something from here without fully understanding what it’s doing.
The current-critical-limit-ma of channel 0 (VDD_IN) is calculated from system EDP limit and input voltage of Jetson-CVM.
The critical current limit = System EDP limit / VDD_IN voltage
The system EDP limit for the Jetson TX1 module, as part of the Jetson TX1 Developer Kit, is defined at kernel/arch/arm64/boot/dts/tegra210-jetson-cv-base-p2597-2180-a00.dts
sysedp {
compatible = “nvidia,tegra124-sysedp”;
nvidia,margin = <0>;
nvidia,min_budget = <0>;
nvidia,initial_budget = <40000>;
};
Critical current limit for 19V VDD_IN = 40,000 / 19 => 2105mA
The system integrator must configure the correct critical current limit based on moduleJetson-CVM input voltage.
For example, the critical current limited for 8V VDD_IN is calculated as below.
Critical current limit for 8V VDD_IN = 40,000 / 8 => 5000mA
If the over current happen, system performance will be throttled so as to reduce power consumption. And then will show same warning message as mlft described.
How about another current monitor circuit such like ina3221 which address is 0x42 for VDD_MUX/VDD_5V_IO_SYS/VDD_3V3_SYS and ina3221 which address is 0x42 for VDD_3V3_IO/VDD_1V8_IO/VDD_M2_IN ?
If the over current happen from the two current monitor, could we see any message and is the policy is also to reduce power consumption?
According to your response "this 2 INAs will not report interrupt to system", did you mean we couldn't detect this condition from the warning message the same with above discussion if the over current happened.
When over current happen in this two INAs, what's the action which TX1 will make?
We have one issue that the TX1 module crashed(we could no longer connect to TX1 in remote method such as SSH), and the relative power control was disabled at the same time by TX1, is this an over current case?
Assume we are talking about the dev kit, not about your own designed carrier board.
Yes, usually you can take this two INAs as no use because their interrupt pins are unconnected, you can see this in schematic.
Generally these rails will not over current unless some components damaged, the INA in module is to monitor GPU/CPU rails which are often dynamic with workload.
According to point 2 you mentioned that “these rails will not over current unless some components damaged”, Is this because of the current limitation setting, I could check the value via sysfs nodes refer to this link( [url]Jetson TX1 - INA226 (Power Monitor with i2C Interface) - Jetson TX1 - NVIDIA Developer Forums), and the setting for channel-0/channel-1/channel-2 are 8190/32760/16380 respectively? It seems that it’s not easy to touch the limitation especially the channel-1 and channel-2.
Another question.
I could see the current limit setting of 0x40/0x42/0x43 via sysfs nodes, and 0x40 setting in device tree file, but couldn’t find the 0x42/0x43 setting at the same device tree, could I modify the 0x42/0x43 setting? If yes, which device tree file could I find?
Please note the INAs on carrier board are just for reading the current/voltage value of the rails, no hardware interrupt will generate even if the threshold reached as the pins are unconnected.