5

ポインターがアドレス A5 または FF を指しているように見えるランダムな時間に発生するハードフォールトに問題があります (私の許容メモリ空間は 80000000 以上でそれをはるかに下回っています)。これら 2 つの値を持つ常に同じポインターのようです。

このエラーが発生する cg2900 と呼ばれる fm/bluetooth/gps チップと通信する STM32F205RE プロセッサを実行している組み込みシステムを使用しています。

デバッガーを使用すると、数回のテスト実行中にポインターがアドレス A5 と FF をそれぞれ指していることがわかります。ただし、ランダムな時間に発生するようです。テストを 1 時間失敗せずに実行できる場合もあれば、20 秒でクラッシュする場合もあります。

何らかの形で干渉する可能性のあるさまざまなタスク (ラジオ用、ブルートゥース用、その他の定期メンテナンス用) を切り替えるスケジューラとして freeRTOS を実行しています。

これの原因は何ですか?カスタム ハードウェアを実行しているため、(潜在的に) ハードウェアの問題である可能性は否定できません。問題のデバッグにアプローチする方法についての指針 (しゃれは意図されていません) はありますか?

編集:

さらに調査した結果、特定のポインターだけでなく、クラッシュする場所は非常にランダムであるようです。ハードフォールト ハンドラーを使用して、これらのレジスターの次の値 (すべての値は 16 進数) を取得しました。

クラッシュ前のセミロングラン (分):

R0 = 1
R1 = fffffffd
R2 = 20000400
R3 = 20007f7c
R12 = 7
LR [R14] = 200000c8  subroutine call return address
PC [R15] = 1010101  program counter
PSR = 8013d0f
BFAR = e000ed38
CFSR = 10000
HFSR = 40000000
DFSR = 0
AFSR = 0
SCB_SHCSR = 0

クラッシュするまでの非常に短い実行時間 (秒):

R0 = 40026088
R1 = fffffff1
R2 = cb3
R3 = 1
R12 = 34d
LR [R14] = 40026088  subroutine call return address
PC [R15] = a5a5a5a5  program counter
PSR = fffffffd
BFAR = e000ed38
CFSR = 100
HFSR = 40000000
DFSR = 0
AFSR = 0
SCB_SHCSR = 0

別の短いもの (秒):

R0 = 0
R1 = fffffffd
R2 = 20000400
R3 = 20007f7c
R12 = 7
LR [R14] = 200000c8  subroutine call return address
PC [R15] = 1010101  program counter
PSR = 8013d0f
BFAR = e000ed38
CFSR = 1
HFSR = 40000000
DFSR = 0
AFSR = 0
SCB_SHCSR = 0

非常に長時間 (1 時間以上) 実行した後:

R0 = e80000d0
R1 = fffffffd
R2 = 20000400
R3 = 2000877c
R12 = 7
LR [R14] = 200000c8  subroutine call return address
PC [R15] = 1010101  program counter
PSR = 8013d0f
BFAR = 200400d4
CFSR = 8200
HFSR = 40000000
DFSR = 0
AFSR = 0
SCB_SHCSR = 0

ほとんどの場合、同じポイントでクラッシュするようです。以前の提案に従ってメモリを調整しましたが、まだ同じ問題があるようです。

御時間ありがとうございます!

敬具

4

4 に答える 4

4

あなたのコメントでは、このポインタは一度明示的に割り当てられ、その後は書き込まれないと述べています。その場合、少なくともそれを宣言しconst、割り当てではなく初期化を使用する必要があります。

arraytype* const ptr = array ;

これにより、コンパイラは明示的な書き込みを検出できます。ただし、関係のないコーディングエラーによってポインタが破損している可能性が高くなります。

Coretx-M3オンチップデバッグは、データアクセスブレークポイントをサポートします。問題のポインタにこのようなブレークポイントを設定して、ポインタへのすべての書き込みアクセスがトラップされるようにする必要があります。初期化が中断され、その後、意図的またはその他の方法で変更が行われます。

考えられる原因は、隣接するアレイまたはスレッドスタックのオーバーランです。

于 2012-12-29T11:27:39.293 に答える
3

アレイを再配置しようとしても同じ問題が続く場合は、

次に、いくつかのタスクがオーバーフローしています。

あなたが述べたように、あなたは FreeRTOS を使用しており、動作がランダムであるため、xTaskCreateの呼び出しでSTACK_SIZE

の設定に何か問題がある可能性があります 。これは通常、割り当てられたサイズが実際に必要なサイズよりも小さい場合に発生します。

usStackDepthに関するドキュメントを読むと、がバイト数ではなく乗数を表していることに気付きました。

個人的には、組み込みボードのハードウェアの問題を除外し、FreeRTOS の構成の問題に焦点を当てます。

于 2012-12-29T21:38:41.517 に答える
1

問題の原因はメモリ ストレージにあることが判明しました。プロセッサーを最高速度 (120 Mhz) で実行し、1.8 ボルトの電源 (主に 3 ボルト用に設計されています) を使用していたため、メモリとの競合状態が発生しました。より高い待機状態を使用して解決しました。

于 2013-01-15T12:16:03.247 に答える