Software summary
Bootloader: U-Boot
Kernel version: 6.6.94-7.3.0-g7642ad324113 #1-Torizon SMP PREEMPT Thu Jul 3 08:47:26 UTC 2025
Kernel command line: root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/e54388c03b414f15de5038757766a36da4957b04d84c897e8d44a069401c4dec/0
Distro name: NAME=“Torizon OS”
Distro version: VERSION_ID=7.3.0-build.18
Distro variant: VARIANT=“Docker”
Hostname: verdin-am62-15645393
Hardware info
HW model: Toradex Verdin AM62 WB on Verdin Development Board
Toradex version: 0075 V1.2A
Serial number: 15645393
Processor arch: aarch64
This is my first time working with toradex and torizon products. i am having a problem with a recurring instability issue on a Verdin AM62 module, resulting in network disconnections. i don’t have a heatsink installed on the SoM.
I made a SSH connection to the ivy board over Putty. For at most 1 minute the system works correctly after that, the SSH connection abruptly terminates. The final error displayed by my client is “Network error: Software caused connection abort”.
I have observed that this disconnection reliably occurs when the SOM’s temperature reaches approximately 60°C.
I would like to ask: Is a hard system crash/disconnection at 60°C the expected thermal protection behavior for the Verdin AM62? Or could this temperature trigger a different underlying issue (e.g., related to power management or a software fault) that I should investigate?
Any suggestions or information you can provide would be greatly appreciated.
Hi, I’m the Toradex AI Assistant.
I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.
Did you like my answer?

Thermal Protection Behavior on Verdin AM62
The system crash/disconnection at 60°C is not the expected thermal protection behavior for the Verdin AM62. Based on the thermal management documentation, the AM62 SoC has much higher thermal thresholds(1):
Expected Thermal Thresholds
For the Verdin AM62, the thermal management system uses these temperature trip points(1):
- Maximum Junction Temperature: 105°C for IT variants(1)
- Passive Trip Point: Typically set at 10°C below the critical temperature(1)
- Critical Trip Point: Set at the maximum junction temperature(1)
Normal Thermal Protection Process
The thermal protection should work as follows(1):
- Dynamic Voltage and Frequency Scaling (DVFS) automatically optimizes power consumption by adjusting CPU clocks and voltage based on demand(1)
- Thermal Throttling forces reduction of system clock when reaching certain temperatures, independent of DVFS(1)
- Critical shutdown only occurs at much higher temperatures (around 105°C for your module)(1)
Investigating the Issue
Since your disconnection occurs at only 60°C, this suggests an underlying issue rather than normal thermal protection. Consider these troubleshooting steps:
Monitor SoC Temperature
You can monitor the actual SoC temperature using(2):
cat /sys/class/thermal/thermal_zone0/temp
Check Power Supply
The Verdin AM62 has a power dissipation range of approximately 1.1W - 3.1W(3). Ensure your power supply can handle the load, especially during thermal stress.
Verify System Stability
- Check system logs for thermal-related messages before the disconnection
- Monitor CPU frequency scaling behavior
- Verify that DVFS is functioning properly
Recommendation
The disconnection at 60°C indicates a problem that needs investigation rather than expected thermal behavior. While adding a heatsink would help with thermal management, the system should remain stable at 60°C without one, given the much higher thermal thresholds of the AM62 SoC(1).
Best regards, Toradex AI Assistant.
Hello @gvallasciani ,
Welcome to the Toradex community!
It’s not expected that the Verdin AM62 would disconnect at around 60 °C, since this temperature is within the normal operating range.
Could you clarify if the SSH session always drops after a specific procedure, or if the disconnection happens repeatedly in different situations? Also, are you able to reconnect afterwards, or does the module remain inaccessible until a reboot? These details would help us better understand whether the issue is related to networking, power, or software.
Best regards,
Daniel Morais
Hi Daniel,
To answer your questions:
1. Could you clarify if the SSH session always drops after a specific procedure, or if the disconnection happens repeatedly in different situations?
The disconnection happens repeatedly under different situations. It usually occurs a short while after opening the SSH connection and starting to perform tasks, such as trying to connect to a Wi-Fi network or just reading the temperature.
2. Are you able to reconnect afterwards, or does the module remain inaccessible until a reboot?
No, once the SSH session drops, the module becomes completely inaccessible over the network. It does not respond to pings or new SSH connection attempts. The only way to regain access is to perform a hard reboot.
To power the board, I am using a 12V, 3A power supply, and I do not have a heatsink installed.
Please let me know if there are any specific tests you would like me to perform.
I look forward to your comments.
Thank you,
Best regards
Hi Gaston,
Thanks for answering my questions.
Could you please try keeping the serial console open while reproducing the issue, so we can see if the system logs any errors?
Also, please keep pinging 8.8.8.8 to check if the problem still occurs, and try configuring a static IP as another test.
Let us know the results of these tests.
Best regards,
Daniel Morais
Hi Daniel,
Thank you for your prompt response and suggestions.
I’m happy to report that I have resolved the issue. The network connection is now completely stable.
The root cause turned out to be an incorrect device tree. I was using the device tree for the Verdin Development Board while working on an Ivy carrier board. This mismatch was causing frequent errors during peripheral queries (I2C, UART, etc.). My theory is that these errors were generating excessive interrupts, which in turn led to network instability, causing the pings to fail and the SSH connection to drop.
Once I switched to the correct device tree for the Ivy board, the instability disappeared entirely.
I use this post to change de device tree ETH2 on Verdin AM62 with Ivy Carrier Board
Because I discovered this solution shortly after your reply, I didn’t get to perform the tests you suggested (monitoring the serial console and setting a static IP), as changing the device tree fixed the root problem.
Thank you again for your support. I’m posting this solution here so it can serve as a reference for anyone who might encounter a similar issue in the future.
Best regards,
Gaston