To simulate the use of Nano device in cold areas, we did some boot tests at low temperatures. The system seems to boot fine, but the MIPI camera function is affected by low temperature.
Our further verification is divided into 3 steps:
Put the device at 0℃ for 2 hours and boot it up, the camera has no image. After 4-7 minutes of power-on, maybe because the device is getting hot, the camera image appears.
Put the device at -10℃ for 2 hours and boot it up, the camera has no image. Compared to stored at 0℃, restoring the camera image requires the device to run longer.
Just restore the Nano module to room temperature and boot, the camera works fine.
At first we suspected a fault with the camera module, but after step 1 and step 2, we felt it was related to Nano module. Remove the camera module, do the same test as in step 2, the UART serial port has the same print.
From system startup to camera function recovery, the typical print is as follows:
I have no experience with this, so I want to know three things:
“pacam_set”-“pdcam_start”-“pdcam_stop”-“pdcam01_power_off”, what might such a cycle represent?
video4linux video0/1: frame start syncpt timeout
“tegra-vii2c …”, Is this related to PMIC or BPMP? Nano Camera.txt (38.9 KB)
Thanks to all who would like to offer some guidance, I look forward to our discussion.
according to Jetson Nano System-on-Module Data Sheet, the operating temperature range is within -25 to 97C.
I’m curious about your test step-3, don’t it be normal output logs if you removing the camera module without modify device tree?
please refer to below…
it looks you have pdcam01 camera driver, those messages should be embedded in your camera kernel driver. it simply prints the kernel operations. you may consider those logs as information.
in addition, I assume these logs also pop-up under the normal condition.
[ 256.508079] #### pdcam01_set_mode stub function ########
[ 256.513766] #### pdcam01_start_streaming stub function ########
[ 256.520194] #### pdcam01_stop_streaming stub function ########
these were actual failures.
since you’ve already removing camera modules, it’s expected VI engine cannot wait start-of-frame and report timeout errors.
[ 238.115493] tegra-vii2c 546c0000.i2c: no acknowledge from address 0x2c
[ 245.283041] tegra-vii2c 546c0000.i2c: no acknowledge from address 0x2c
...
[ 247.242052] video4linux video0: frame start syncpt timeout!0
[ 247.386010] video4linux video1: frame start syncpt timeout!0
Thank you for your introduction to these failures. Seems like all the problems revolve around the camera input?
In step-3, you think we should get a normal log without the camera?
Confusingly, our testers just told me that without the camera, these prints would not occur at room temperature; after cryogenic storage, it will appear. I’ll check this information carefully.
However, due to the experimental conditions, we cannot only store Nano module at low temperature. If we do that, it will quickly regain its temperature when we try to put it back into the device.
In step-3, the Nano module and the carrier board are always attached. I know the temperature range of Nano. Everything seems to point to the problem being caused by the board after cryogenic storage.
It left me with no idea. If you have some suggestions about testing, please guide our team work. We will continue our efforts. Thanks!
how about fully disable camera support from device tree config to reproduce this again?
please looking for your kernel messages (i.e. $ dmesg | grep DTS) to ensure the dtsi files you’re using…
here’s main device tree for Nano A02 series.
for example, $public_source/kernel_src/hardware/nvidia/platform/t210/porg/kernel-dts/tegra210-p3448-0000-p3449-0000-a02.dts
you may try removing Nano support cameras, i.e. IMX219 and IMX477 from include files.
this will disable camera supports after you rebuild the device tree blob and update the binary to the target,
please have a try, for narrowing down the issue, thanks
