i.MX8X disabling RESTART_RESET_TIMER

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

i.MX8X disabling RESTART_RESET_TIMER

ソリューションへジャンプ
1,002件の閲覧回数
gclaudino
Contributor I

Hello!

I'm currently working with a SOM using a i.MX8X chip. I'm trying to keep the system in Recovery boot for a while in order to do some tests but the system is resetting automatically after around 3 minutes. Reading the Reference Manual (i.MX 8DualX/8DualXPlus/8QuadXPlus Applications Processor Reference Manual, Rev. 0, 05/2020 - Chapter 5.7.3.3) I found that there is a timer called RESTART_RESET_TIMER that forces the system to reset if no data is detected in the USB. 

I tried to send some delay commands via UUU shell but it doesn't seem to stop this timer to reset the module. Is there a way to either disable it, increase the timeout or is there a proper way to poll data from USB constantly in recovery boot? Or would it be possible to authenticate SECO FW in recovery boot as it seems to be another way to stop this undesirable reset?

Thanks a lot.

Best regards 




ラベル(1)
0 件の賞賛
返信
1 解決策
978件の閲覧回数
seb_haezebrouck
NXP Employee
NXP Employee

Hi @gclaudino ,

Unfortunately there is no way to prevent this type of reset after 3 minutes. The behavior is not actually linked to USB activity. The RM is a bit confusing in this respect.

There is a hardware watchdog in the SoC SNVS module. This timer will expire after 300 ms. When the SECO ROM has authenticated the SECO FW, the SECO ROM will stop the watchdog.

At boot, the SC ROM will send the SECO ROM a RESTART_RESET_TIMER message regularly (with a periond < 300ms) for 3 minutes, and will then stop. So if no SECO FW was authenticated within 3 minutes, the SNVS WDOG will reset the SoC. If a SECO FW was authenticated during this delay, the WDOG was stopped by the SECO ROM.

The (confusing) reference to USB activity was supposed to mean that one needs to download a SECO FW and have it authenticated  (SDPS: boot -f valid_image_containing_a_seco_fw) to have the WDOG disabled. So there is no way to leave the board in SDP mode for more than 3 minutes.

Best regards,

Seb

元の投稿で解決策を見る

0 件の賞賛
返信
4 返答(返信)
986件の閲覧回数
gclaudino
Contributor I

Hi everyone. I also found that the same timer is present on the i.MX8 family. I still have no clue how to better deal with it, however.

I'm currently thinking about trying to send a MU message to the SECO but without success up to now. 

Do you have any update on it?

Thanks a lot

0 件の賞賛
返信
979件の閲覧回数
seb_haezebrouck
NXP Employee
NXP Employee

Hi @gclaudino ,

Unfortunately there is no way to prevent this type of reset after 3 minutes. The behavior is not actually linked to USB activity. The RM is a bit confusing in this respect.

There is a hardware watchdog in the SoC SNVS module. This timer will expire after 300 ms. When the SECO ROM has authenticated the SECO FW, the SECO ROM will stop the watchdog.

At boot, the SC ROM will send the SECO ROM a RESTART_RESET_TIMER message regularly (with a periond < 300ms) for 3 minutes, and will then stop. So if no SECO FW was authenticated within 3 minutes, the SNVS WDOG will reset the SoC. If a SECO FW was authenticated during this delay, the WDOG was stopped by the SECO ROM.

The (confusing) reference to USB activity was supposed to mean that one needs to download a SECO FW and have it authenticated  (SDPS: boot -f valid_image_containing_a_seco_fw) to have the WDOG disabled. So there is no way to leave the board in SDP mode for more than 3 minutes.

Best regards,

Seb

0 件の賞賛
返信
973件の閲覧回数
gclaudino
Contributor I

Hi @seb_haezebrouck , thanks for the answer!

So indeed the behavior was linked with this timer. I was trying to stay in recovery boot for a longer time to use the JTAG Interface. If there is no way to stop it, however, would you have any recommended documentation for me to read and check what can I do to better use this interface?

Best regards,
Guilherme

0 件の賞賛
返信
967件の閲覧回数
seb_haezebrouck
NXP Employee
NXP Employee

Hi @gclaudino ,

What do you intend to do ?

USB serial download is not supposed to be a steady permanent state. One would usually use it in factory to provision an initial software, or as a fallback state in case of a corrupted image preventing the device from booting.

If you need to attach to the CM4 or A53 processors with a debugger, I'd advise you flash an image (or boot it from RAM) containing a proper SECO FW, through uuu, and then attach your debugger.

Best regards,

Seb

0 件の賞賛
返信