Unexpected stop-the-world pauses on i.MX RT 1176

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

Unexpected stop-the-world pauses on i.MX RT 1176

ソリューションへジャンプ
693件の閲覧回数
AtKr
Contributor I

Hi!

I'm writing some code for a RT1176 (using the M7 core) and it regularly (multiple times per ms) seems to "hang" in some spot where I don't expect it to. I've disabled all interrupts through the SCB and put in some debug pin outputs to measure it and the pauses still happen. So the issue isn't some interrupt.
Those pauses are usually 20 to 40 us in length, which is a big problem for me when the system is supposed to reliably do something every 50 us.

Interestingly, I managed to narrow the location of (one of?) those pauses and the code looks something like this:

Debug_PinSet(3, HIGH);
if ((structp->uint_a - structp->uint_b) > structp->uint_c)
structp->uint_c = structp->uint_a - structp->uint_b;
Debug_PinSet(3, LOW);

As you can tell, there is absolutely nothing happening that should take 20 us on a processor running at around 1 GHz. The same code was working fine on an LPC4088 before, which is even more confusing to me.

What is happening here?
And, more importantly: How can I prevent this from happening?

 

Thank you for your time!

0 件の賞賛
1 解決策
594件の閲覧回数
Omar_Anguiano
NXP TechSupport
NXP TechSupport

You might be correct. It is expected that executing from external flash is less efficient than using internal memories to execute your code.

Best regards,
Omar

元の投稿で解決策を見る

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

You are not the only one to observe this delay in 10's of uS when executing from external flash.  Disabling PREFETCH on the flash controller was one element of this fix. The behavior was as if the prefetch was not being interrupted, and the CPU stalled until the entire prefetch buffer was full.

0 件の賞賛
635件の閲覧回数
AtKr
Contributor I

Hi!

I am currently using the "iMX RT1176 uCOM" board by Embedded Artists together with MCUXpresso and a MCU-Link programmer/debugger.
The project is based on some SDK examples (GPIO and the in-application flash programmer I think), which is why some data is linked into SRAM_OC1 (as shown below).

.

I tried debugging the firmware (debug build configuration) through linking it to RAM and the pauses are gone, which is very good!

AtKr_2-1678181720393.png  AtKr_1-1678181684729.png

For the record, the memory used for a "normal" build looks like this in release configuration:

AtKr_3-1678181846482.png

Reading the MCUXpresso IDE User Guide I then set the "Global data placement" option in the "Managed Linker Script" section to SRAM_DTC_cm7 and it works just as well as if debugging from RAM (as I would have expected).
Here's the final configuration that I am using:

AtKr_4-1678182508103.png

 

Digging around in the RT1176 User Manual I came to the conclusion that by default the program code is somehow streamed from the onboard flash (via FlexSPI) into the instruction cache and I was experiencing a page miss. Is this assumption correct?

 

Thank you for your help!

0 件の賞賛
595件の閲覧回数
Omar_Anguiano
NXP TechSupport
NXP TechSupport

You might be correct. It is expected that executing from external flash is less efficient than using internal memories to execute your code.

Best regards,
Omar

0 件の賞賛
648件の閲覧回数
Omar_Anguiano
NXP TechSupport
NXP TechSupport

Hello
I hope you are well.

I suggest you load the code on the TCM RAM and load the code in Serial Download mode through the MCUBootUtility. Are you using any specific debugger?

Best regards,
Omar