RT1052 auto reset

[Jay_Lin]

Hi,

We found that our product (using RT1052) automatically restarts after running for a period of time (1~2 days).

We don't have any clues about this phenomenon, we want to find out first
1.Why does the MCU restart?
2. What is the last Function executed before restarting?

Is there any way to obtain relevant information?

Thanks.

[kerryzhou]

HI @Jay_Lin ,

   Thank you for your interest in the NXP MIMXRT product, I would like to provide service for you.

  At first, you need to know which detail type caused your auto reset.

  I think, you can add some code in your app, printf the reset type after you reset, then you will find the related situation, and fix it.

   Please printf the (SRC_SRSR) register after you reset, then test it again.

  Any updated information, please let me know.

Best Regards,

Kerry

[Jay_Lin]

Thanks for the information, I will test it and discuss it further with you.

[kerryzhou]

You are welcome!

Any updated information, just feel free to let me know.

Best Regards,

Kerry

[Jay_Lin]

Hi, kerryzhou

I put the SRC_SCR print operation at the front of the main loop. After observing it for one night, I found that the program restarted 12 times.

[2023-11-14 17:07:19.438] SRC_SCR: a0480520
[2023-11-14 22:22:23.086] SRC_SCR: a0480520
[2023-11-14 23:39:01.080] SRC_SCR: a0480520
[2023-11-15 00:29:50.894] SRC_SCR: a0480520
[2023-11-15 00:43:20.618] SRC_SCR: a0480520
[2023-11-15 01:29:40.704] SRC_SCR: a0480520
[2023-11-15 02:12:48.380] SRC_SCR: a0480520
[2023-11-15 03:47:08.368] SRC_SCR: a0480520
[2023-11-15 04:21:11.279] SRC_SCR: a0480520
[2023-11-15 04:47:26.585] SRC_SCR: a0480520
[2023-11-15 05:14:58.128] SRC_SCR: a0480520
[2023-11-15 07:08:42.976] SRC_SCR: a0480520

I try to use IMXRT1050RM.pdf to analyze the SRC_SCR message.

1010 0000 0100 1000 0000 0101 0010 0000

• 31–28
  mask_wdog3_rst : 1010 , wdog3_rst_b is not masked
• 25
  dbg_rst_msk_pg: 0 , do not mask core debug resets
• 17
  core0_dbg_rst: 0 , do not assert core0 debug reset
• 13
  core0_rst: 0 , do not assert core0 reset
• 10–7
  mask_wdog_rst: 1010 , wdog_rst_b is not masked

From the results, it seems that SRC_SCR does not indicate any reason for restarting. Is this understanding correct?

[kerryzhou]

Hi @Jay_Lin ,

   You are reading the wrong register, it is the SRC_SRSR, not the SCR!

   SRSR is the status register, SCR is the control register.

   Please do the testing again, it is really a pity that you reproduce the issues, but with the wrong register.

kerryzhou_0-1700014808505.pngkerryzhou_1-1700014814131.png

  Please do check again, any updated information, please kindly let me know.

Best Regards,

Kerry

[Jay_Lin]

HI ,kerryzhou 

The following log is the result of last night’s test

[2023-11-15 17:01:52.100] SRC_SRSR: 0x1
[2023-11-15 17:32:59.316] SRC_SRSR: 0x11
[2023-11-15 17:38:29.047] SRC_SRSR: 0x11
[2023-11-15 21:01:36.659] SRC_SRSR: 0x11
[2023-11-15 21:21:13.476] SRC_SRSR: 0x11
[2023-11-15 21:23:35.909] SRC_SRSR: 0x11
[2023-11-15 21:52:31.722] SRC_SRSR: 0x11
[2023-11-15 22:51:09.711] SRC_SRSR: 0x11
[2023-11-15 23:19:27.930] SRC_SRSR: 0x11
[2023-11-16 06:09:52.545] SRC_SRSR: 0x11
[2023-11-16 07:47:15.921] SRC_SRSR: 0x11

It looks like wdog_rst_b triggers the Reset event, but what I don't understand is why ipp_reset_b sets 1 in every SRC_SRSR?

I think ipp_reset_b should only be set to 1 during first power up.

Is there a way to know which function was last executed before triggering the watchdog?

[kerryzhou]

Hi @Jay_Lin ,

  From your situation, it is related to the :

kerryzhou_0-1700109507909.png

Your reset is mainly to the watchdog timeout.

ipp_reset_b need to do the clear at first, then it will be 0 if you don't do the software reset.

I already test it for the ipp_reset_b .

If you don't want this bit influence your result, you can write:

PRINTF("SRSR=%X\r\n",SRC->SRSR);

SRC->SRSR |=1;

Then, the next none POR reset, will just have the watchdog.

Now, your issues is mainly caused by your code, your code should blocking some area 

Which didn't do the feed watchdog, that cause the reset issues.

I think, you need to check your own software project, or you can add more frequently feed watchdog.

Wish it helps you!

Best Regards,

Kerry

[Jay_Lin]

HI, kerryzhou

Thanks for your opinion, I will analyze my program to confirm which part is causing the blocking.

If I suspect a HardFault is causing the watchdog to trigger, how can I confirm?

[kerryzhou]

Hi @Jay_Lin 

   Add  printf in hardfault ISR , check whether it can be printf or not

Best Regards,

Kerry

[Jay_Lin]

Hi, kerryzhou

I set a breakpoint in the Hardfault ISR and intercepted the Hardfault.

why this Hardfault occurs?
How to avoid this Hardfault occurs?

螢幕擷取畫面 2023-11-20 083236.png

 

[kerryzhou]

Hi @Jay_Lin ,

hardfault is caused by some abormal code.

 About how to check the detail code cause the hardfault, you can debug it, and check it.

You can refer to this post:

https://www.nxpic.org.cn/module/forum/thread-596127-1-1.html

https://mcuoneclipse.com/2012/11/24/debugging-hard-faults-on-arm-cortex-m/

kerryzhou_0-1700455560371.png

You can use the LR register to find which detail code cause the hardfault.

Wish it helps you!

Best Regards,

Kerry

[Jay_Lin]

Hi, kerryzhou

I found that the program would run to SEMC (Aliased) for execution inexplicably.
Because there is no code here, the program is stuck. Finally, the watchdog starts and causes the MCU to reset. I guess this is the cause of the current problem.

------------------------------------------------------------------------------------------------------------------

Jay_Lin_0-1700810604549.png

------------------------------------------------------------------------------------------------------------------

Jay_Lin_1-1700810651888.png

------------------------------------------------------------------------------------------------------------------

Jay_Lin_2-1700810698605.png

------------------------------------------------------------------------------------------------------------------

Jay_Lin_3-1700810849640.png

This is our space allocation. You can see that the location of 0x1nnnnnnn is not used.

Under what circumstances will the program suddenly run to 0x1nnnnnnn?

[kerryzhou]

Hi @Jay_Lin ,

  please also check, which detail code cause enter to the SEMC (Aliased)? Check the original code, which code, then you may know the details.

Best Regards,

Kerry

[Jay_Lin]

HI, kerryzhou

I have confirmed all functions, and no functions are placed in SEMC (Aliased). This can also be confirmed from the contents of the .map file.
I searched the entire project file and could not find the relevant string of 0x11dnnnnn. I began to suspect that it was When the MCU puts the external Flash program into the SRAM, the data may be interfered with during the communication process, causing the program to jump to an unexpected Address execution.

Is this possible?

[kerryzhou]

Hi @Jay_Lin ,

  Yes, I understand you didn't configure the code to SEMC (Aliased).

  So, now the issues is which detail c code let the mcu enter the SEMC (Aliased)? This is the abnormal situation, just when you enter this area, the the mcu enter fault, as you didn't configure it.

  So, you can consider, your code runs abnormally and runs away， so enter to the invalid area to your application. Can you do more debug to find, which detail code enter the SEMC (Aliased).?

Best Regards,

Kerry

[Jay_Lin]

Hi, kerryzhou

Thanks for the suggestion, I'll continue to monitor the program to see if there are any other clues about the crash.

As mentioned last time, the MCU was disturbed when it read data from external Flash and put it into SRAM, causing the program to execute to a position where it should not be executed when encountering abnormal data in SRAM. is it possible?

[kerryzhou]

Hi @Jay_Lin ,

  If your SDRAM aleady do the stress testing, and passed it, I don't think the SDRAM data write and save, and read will meet issues.

  But, if you use the cache, the operation is not good, it may meet hardfault issues.

So, you also can try to disable the cache, and test it, check whether it have issues or not.

Best Regards,

Kerry

[Jay_Lin]

Hi, kerryzhou

1. Our SDRAM has not been stress tested. Can you provide code and related resources for us to test?

2. How to turn off the cache for testing?

3. Are there relevant time parameters for MCU and SDRAM that can be set?

[kerryzhou · Accepted solution]

Hi @Jay_Lin ,

Answer your questions:

1. Our SDRAM has not been stress tested. Can you provide code and related resources for us to test?

=>Answer: 

You can refer to this blog:

https://www.cnblogs.com/henjay724/p/14564390.html

https://www.cnblogs.com/henjay724/p/14580257.html\

2. How to turn off the cache for testing?

=>Answer:

 in the void BOARD_ConfigMPU(void), modify :

SCB_EnableDCache();
SCB_EnableICache();
to
SCB_DisableDCache();
SCB_DisableICache();

3. Are there relevant time parameters for MCU and SDRAM that can be set?

=>Answer:  No directly tim parameters, just to the SEMC configuration to the SDRAM, in fact, if your SDRAM is working, the configuration is OK.

Best Regards,

Kerry

[Jay_Lin]

Hi, kerryzhou

Thanks for your reply, I will try your suggestions

thank you