2129335_ja-JP

[#1]

imxrt1061 ハードフォールトはクロックAPI呼び出しを指しています

良い一日

私のプロジェクトでは、ThreadX RTOS を実行する imxrt1061 を使用しています。安定走行中に、重大な障害が発生する場合があります。再現が難しく、未知の状況下で発生します。テスト実行 5000 回につき 1 回程度発生する可能性があります。

通常、これは制御された再起動後に発生します - すべてのアクティビティが完了し、再起動が開始され、メインアプリケーション（init Thread）が起動し、init Threadの実行中に失敗する可能性があります。

以下はリストの一部です（CLOCK_SetLowSpeed呼び出し内のすべての関数はI-TCM RAMにあります）

601020d0 :
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 
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 

スタックのプリントアウト

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",

この問題をどのようにCANローカライズできるかアドバイスをお願いします。ご提案があれば歓迎いたします。ありがとう

Re: imxrt1061 Hard fault points to clock API call@エドウィンHz
質問は実際には ThreadX についてではなく、xip アプローチとその制限についてです。私たちのプロジェクトでは xip アプローチを使用しているSO、xip と外部 QSPI フラッシュを使用する際のメモリ アクセス制限について説明しているドキュメントはありますか?Re: imxrt1061 Hard fault points to clock API call

こんにちは@swisst 、

残念ながら、ThreadX は弊社ではサポートされなくなりました。このOSのサポートについては、ThreadXのサービスとサポートのWebサイト（Eclipse ThreadX Services and Support | The Eclipse Foundation）で確認することを強くお勧めします。

ご不便をおかけして申し訳ございません。

BR、
エドウィン。

Re: imxrt1061 Hard fault points to clock API call

こんにちは@EdwinHz

チケットに記載される情報量は非常に限られていることは承知していますが、とにかく私が知っているのはそれだけです。SO残念ながら、問題は依然として残っています

実行時に、fsl_memcpy.S に実装された memcpy 関数を指すバックトレースで別のハード エラーが発生しています。SO、コードが fsl_memcpy 実装と正確にリンクされており、ライブラリ実装を使用していないことを何度か確認しました。

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

00002e4e :
    2e4e:	f011 0303 	ands.w	r3, r1, #3
    2e52:	d006      	beq.n	2e62 
    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 
    2e60:	e7f5      	b.n	2e4e 

memcpy は ITCM メモリに配置され、ハード障害が発生したときに PC は 0x00002E54 値を保持しました。この機能の実装を確認しましたが、最新のSDKsとの違いは見つかりませんでした。

偶然そのチケットに気づいたSO疑問が生じましたが、答えを見つけることができませんでした。私たちのプロジェクトでは xip アプローチを使用しているため、xip と外部 QSPI フラッシュを使用する際のメモリ アクセスの制限について説明しているドキュメントはありますか?

よろしくお願い申し上げます。

Re: imxrt1061 Hard fault points to clock API call

@エドウィンHz
返信が遅くなってごめんなさい

すでに例から離れすぎているため、特定のアプリケーションについてのみ説明します。

ご覧のとおり、主な問題は問題の再現が不安定なことです。

私たちは NXP USB ミドルウェア (CDC クラス デバイス) を使用しているSO、ロガーとシェルの入出力は USB 経由で行われます。私の最初の仮定は、再起動前にクロックペリフェラルセクションが正しく初期化解除されていないということでした。再起動は制御され、SO、ソフトウェアでいくつかのアクション（サービスの停止、接続の終了）が実行され、最後に NVIC リセット要求が行われます。しかし、他の面では、すべてのペリフェラルはリセット時にデフォルト値にリセットされる必要があります。

Re: imxrt1061 Hard fault points to clock API call

こんにちは@swisst 、

あなたのボード上の ThreadX 用に提供しているサンプル コードでも、同様の現象が発生しますか?それとも、実行している特定のアプリケーションのみでしょうか?