RT1052 auto reset

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 
2,851件の閲覧回数
Jay_Lin
Contributor I

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.

ラベル(1)
0 件の賞賛
返信
1 解決策
2,174件の閲覧回数
kerryzhou
NXP TechSupport
NXP TechSupport

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

元の投稿で解決策を見る

0 件の賞賛
返信
21 返答(返信)
2,799件の閲覧回数
kerryzhou
NXP TechSupport
NXP TechSupport

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

0 件の賞賛
返信
2,785件の閲覧回数
Jay_Lin
Contributor I

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

0 件の賞賛
返信
2,779件の閲覧回数
kerryzhou
NXP TechSupport
NXP TechSupport

You are welcome!

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

Best Regards,

Kerry

0 件の賞賛
返信
2,763件の閲覧回数
Jay_Lin
Contributor I

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?

 

 

 

 

0 件の賞賛
返信
2,759件の閲覧回数
kerryzhou
NXP TechSupport
NXP TechSupport

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

 

 

0 件の賞賛
返信
2,738件の閲覧回数
Jay_Lin
Contributor I

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?

 

0 件の賞賛
返信
2,727件の閲覧回数
kerryzhou
NXP TechSupport
NXP TechSupport

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

 

0 件の賞賛
返信
2,719件の閲覧回数
Jay_Lin
Contributor I

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?

0 件の賞賛
返信
2,712件の閲覧回数
kerryzhou
NXP TechSupport
NXP TechSupport

Hi @Jay_Lin 

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

 

Best Regards,

Kerry

0 件の賞賛
返信
2,630件の閲覧回数
Jay_Lin
Contributor I

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

0 件の賞賛
返信
2,619件の閲覧回数
kerryzhou
NXP TechSupport
NXP TechSupport

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

 

   

0 件の賞賛
返信
2,544件の閲覧回数
Jay_Lin
Contributor I

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?

 

0 件の賞賛
返信
2,441件の閲覧回数
kerryzhou
NXP TechSupport
NXP TechSupport

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

0 件の賞賛
返信
2,433件の閲覧回数
Jay_Lin
Contributor I

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?

0 件の賞賛
返信
2,377件の閲覧回数
kerryzhou
NXP TechSupport
NXP TechSupport

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

0 件の賞賛
返信
2,372件の閲覧回数
Jay_Lin
Contributor I

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?

0 件の賞賛
返信
2,358件の閲覧回数
kerryzhou
NXP TechSupport
NXP TechSupport

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

0 件の賞賛
返信
2,160件の閲覧回数
Jay_Lin
Contributor I

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?

0 件の賞賛
返信
2,175件の閲覧回数
kerryzhou
NXP TechSupport
NXP TechSupport

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

0 件の賞賛
返信
2,141件の閲覧回数
Jay_Lin
Contributor I

Hi, kerryzhou

Thanks for your reply, I will try your suggestions

 

thank you

0 件の賞賛
返信