imxrt1061 Hard fault points to clock API call

[swisst]

Good day

I use imxrt1061 running ThreadX RTOS in my project. During the stability runs we occasionally can catch hard fault. It is hard to reproduce it and it occurs under unknown circumstances. It may occur approximately one time per 5000 test runs.

Usually it happens after controlled reboot - all activities are done, reboot initiated, main application (init thread) starts and during init thread execution it may fail

Here is a listing part (all functions inside CLOCK_SetLowSpeed call are located in I-TCM RAM)

601020d0 <CLOCK_SetLowSpeed>:
601020d0:	b580      	push	{r7, lr}
601020d2:	af00      	add	r7, sp, #0
601020d4:	f14c fd80 	bl	6024ebd8 <__CLOCK_SystemCoreClockSwitchLowPower_veneer>
601020d8:	f14c fd82 	bl	6024ebe0 <__CLOCK_DeinitArmPll_veneer>
601020dc:	f7ff ff8a 	bl	60101ff4 <CLOCK_ConfigSysPll>
601020e0:	2000      	movs	r0, #0
601020e2:	f14c fd3d 	bl	6024eb60 <__CLOCK_DeinitSysPfd_veneer>
601020e6:	2001      	movs	r0, #1
601020e8:	f14c fd3a 	bl	6024eb60 <__CLOCK_DeinitSysPfd_veneer>
601020ec:	2118      	movs	r1, #24
601020ee:	2002      	movs	r0, #2
601020f0:	f14c fd56 	bl	6024eba0 <__CLOCK_InitSysPfd_veneer>
601020f4:	2003      	movs	r0, #3
601020f6:	f14c fd33 	bl	6024eb60 <__CLOCK_DeinitSysPfd_veneer>
601020fa:	f14c fd55 	bl	6024eba8 <__CLOCK_DeinitUsb2Pll_veneer>
601020fe:	f14c fd1b 	bl	6024eb38 <__CLOCK_DeinitAudioPll_veneer>
60102102:	f14c fd11 	bl	6024eb28 <__CLOCK_DeinitVideoPll_veneer>
60102106:	f14c fce3 	bl	6024ead0 <__CLOCK_DeinitEnetPll_veneer>
6010210a:	f14c fd5d 	bl	6024ebc8 <__CLOCK_SystemCoreClockSwitchLowSpeed_veneer>
6010210e:	46bd      	mov	sp, r7
60102110:	e8bd 4080 	ldmia.w	sp!, {r7, lr}
60102114:	f05f be04 	b.w	60161d20 <SystemCoreClockUpdate>

and a stack printout

REBOOT OCCURED\n",
TYPE:     HARD FAULT\n",
--- Stack frame -------------------------------------------------------\n",
 IPSR= 0x00000003 >>>>> HardFault <<<<\n",
 R0  = 0x00000008\n",
 R1  = 0x5018505B\n",
 R2  = 0x400D8000\n",
 R3  = 0x00000080\n",
 R12 = 0x00000280\n",
 LR  = 0x601020E7\n",
 PC  = 0x60102100\n",
 PSR = 0x0100000E\n",
 SP (when faulted)  = 0x20077F08\n",
--- System Control Block (SCB) ----------------------------------------\n",
0x00080000 - CFSR     - Configurable Fault Status Register\n",
 > The processor has attempted to access a coprocessor\n",
0x40000000 - HFSR - HardFault Status Register\n",
 > Forced HardFault\n",
0x411FC271 - CPUID   - CPUID Base Register\n",
0x00481003 - ICSR    - Interrupt Control and State Register\n",
0x60100400 - VTOR    - Vector Table Offset Register\n",
0xFA050000 - AIRCR   - Application Interrupt and Reset Control Register\n",
0x00000000 - SCR     - System Control Register\n",
0x00070200 - CCR     - Configuration Control Register\n",
0x00F00000 - CPACR  - Coprocessor Access Control Register\n",

Please advise how this issue can be localized. Any suggestions are appreciated. Thank you

[swisst]

Hi @EdwinHz 

I do understand that the amount of information provided in the ticket is very limited but anyway that's all I have. So the issue is still here unfortunately

We got another hard fault during runtime with backtrace that points to memcpy function implemented in fsl_memcpy.S. So I checked several times that over code is linked exactly with fsl_memcpy implementation and not using library implementation.

00002e48 <memcpy>:
    2e48:	b5f1      	push	{r0, r4, r5, r6, r7, lr}
    2e4a:	2a00      	cmp	r2, #0
    2e4c:	d04b      	beq.n	2ee6 <ret>

00002e4e <src_word_unaligned>:
    2e4e:	f011 0303 	ands.w	r3, r1, #3
    2e52:	d006      	beq.n	2e62 <src_word_aligned>
    2e54:	f811 4b01 	ldrb.w	r4, [r1], #1
    2e58:	3a01      	subs	r2, #1
    2e5a:	f800 4b01 	strb.w	r4, [r0], #1
    2e5e:	d042      	beq.n	2ee6 <ret>
    2e60:	e7f5      	b.n	2e4e <src_word_unaligned>

memcpy is placed in ITCM memory and PC held 0x00002E54 value when hard fault occurred. I reviewed implementation of this function and see no differences with latest SDK.

I accidentally noticed that ticket so question arise and I could not find the answer -so due to we use xip approach in our project are there any document which describes memory access limitations when using xip and external QSPI flash ?

Thank you

[EdwinHz]

Hi @swisst,

Unfortunately, ThreadX is no longer supported by us. I highly recommend you look for support of this OS on the ThreadX services and support website: Eclipse ThreadX Services and Support | The Eclipse Foundation

I apologize for the inconvenience this may cause.

BR,
Edwin.

[swisst]

@EdwinHz
The question is actually not about ThreadX but more about xip approach and its limitations so due to we use xip approach in our project are there any document which describes memory access limitations when using xip and external QSPI flash ?

[EdwinHz]

Hi @swisst,

Do you also see this happening with example codes we provide for ThreadX on your board? Or only with that specific application you are running?

[swisst]

@EdwinHz 
Sorry for a late reply

I would say only our specific application because we already went too far from examples.

As you can see the main problem is unstable reproduce of the issue.

We use NXP USB middleware (CDC class device) so we have our logger and shell input/output over USB. My first assumption was that clock peripheral section was not de-initialized correctly before reboot. Reboot is controlled so some actions are performed in software (stop services, close connections) and NVIC reset request at the end. But from other side all peripherals should reset to default values on reset.