問題タブ [stm32f4discovery]

Eclipse + GDB ハードウェア デバッグ + OpenOCD + STM32F4DISCOVERY (ST-LINK 経由) を使用しています。

すべて正常に動作します。

デバッグ完了後、ターゲット CPU は Halt モードのままです。デバッグ (Terminate が押された) 後にターゲット CPU がリセットまたは動作し続けるようにするにはどうすればよいですか?

以下のコードを使用して SPI を初期化し、加速度計から値を読み取ることができました

次に、これらのコードを 500Hz 割り込みのあるプロジェクトと組み合わせました。最初は常に機能しますが、ボードのプラグを抜いてから再度差し込むと、LIS3DSHにはまだ読み取り値がありますが（オシロスコープを使用してチェックしました）、SPIはゼロのみを読み取ります。SPI を再び適切に動作させるには、プロジェクト コードの短いバージョンをダウンロードする必要がありました (割り込みでほとんどのコードを削除します)。キックスタートのサイズ制限付き IAR ewarm を使用しています。これは、コードが制限を超えたためだと思いました。しかし、警告は表示されず、コードは 32kb 以下でした。

プラグを抜くまで機能するので、混乱しています。誰かが私にいくつかの提案をしてもらえますか? ありがとう

STM32F405 の内部フラッシュを使用して、再起動後に残るユーザー設定可能な一連のバイトを保存しようとしています。

私は使用しています：

保存したいデータにメモリを割り当てます。

プログラムの開始時に、最初のバイトが に設定されているかどうかを確認し0x42、そうでない場合は、次を使用して設定します。

その後、値をチェックインするuserConfig[0]と、わかりました0x42... 素晴らしい！

しかし、リセットを押して場所をもう一度見ると、もうあり0x42ません...

どこが間違っているのか分かりますか？私も試しました：

しかし、私は同じ結果を得ます..

プロジェクトに STM32F4 検出ボードを使用していますが、問題に正しく取り組んでいるかどうか疑問に思っています。ボタンを押すと、ルーチンを実行する外部割り込みがトリガーされます。遅延を使用しない場合、この部分は正常に機能します。ルーチンがサーボを動かしてから元の位置に戻すと、サーボが元の位置に戻る前に新しい PWM 出力に追いつくことができるように遅延が追加されます。遅延を使用して新しい割り込みルーチンを実行すると、ボードがロックされます。デバッグでは、コードが遅延ループで停止しているように見えます。

遅延は単純な sysstick ルーチンです。これを割り込み内に配置するのは悪い習慣 (つまり、クラッシュの原因) ですか? 別の方法を使用する必要がありますか? たとえば、設定時間後にサーボを返す外部割り込みルーチン内にワンショットタイマーを設定しますか?

ありがとう！

これらのマイクロコントローラーのデータシートとリファレンス マニュアルによると、GPIOG の場合は 128 バイトであることに気付きました (たとえば)。

0x4002 1800 - 0x4002 1BFF GPIOG (データシートより)

私の質問は、なぜ 128 バイト (1024 ビット) なのですか? すべての GPIOG レジスタは 40 バイトしか使用しません。ありがとう。

プロジェクトをビルドしようとしましたが、このエラーが発生しました。この方法で変数を定義しようとした問題が本当にわかりません。

そしてこの方法でも：

ありがとう

OCR アルゴリズム (具体的には GOCR アルゴリズム) を 32F429IDISCOVERY ボードに実装しようとしていますが、まだ何も返されません... OV7670 カメラからの画像を RGB565 形式でボードの SDRAM に記録しています。グレースケールになり、アルゴリズム自体に渡されます。このフォーラムや他のフォーラムから、GOCR は非常に優れたアルゴリズムであり、PC ではうまく機能しているように見えましたが、ボード上では機能しないという印象を受けました。OCRまたはGOCRを実装した経験のある人はいますか? 非常に奇妙な方法で動作するため、問題がどこにあるのかわかりません。ほとんどの場合、コードはアルゴリズムの別の部分で停止します...

OCR アルゴリズムの呼び出し:

32F429IDISCOVERY ボードに GOCR アルゴリズムを実装しようとしています。GOCR 自体は PC で非常にうまく機能しますが、ディスカバリー ボードではまだ不安定で使用できない問題がいくつかあります。アルゴリズムが正常に動作し、すべてがうまくいき、結果が素晴らしい場合もありますが、プロセッサがハード フォールト/デフォルト ハンドラでスタックすることがあります。クラッシュの原因と対処法はわかりませんが、スタック/ヒープがオーバーフローしたと考えられます。以下に、クラッシュの前後のプロセッサの状態を示す画像を添付しました。