i.MX8X disabling RESTART_RESET_TIMER

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX8X disabling RESTART_RESET_TIMER

Jump to solution
638 Views
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 




0 Kudos
1 Solution
614 Views
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

View solution in original post

0 Kudos
4 Replies
622 Views
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 Kudos
615 Views
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 Kudos
609 Views
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 Kudos
603 Views
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 Kudos