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 用に提供しているサンプル コードでも、同様の現象が発生しますか?それとも、実行している特定のアプリケーションのみでしょうか?
查看全文
