問題タブ [stm32cubeide]

実験の途中で、誰かが解決策を知っていることを願っている問題に行き詰まりました。

バックグラウンドで継続的に実行されるはずの PWM モードで TIMER1 を使用しています。STM32F401 では Timer1 更新イベントを使用して ADC をトリガーすることはできないため、次の設定を使用しました。

TIM1: トリガ イベント選択_出力コンペア(OC1REF) ADC1: 外部トリガ変換ソース_ タイマ 1 キャプチャ コンペア 1 イベント

ADC1 を介して特定の値を検出する際に、メイン出力を無効にする必要があります (タイマーを無効にしたくない)。したがって、BDTR レジスタの MOE ビットをクリアしました。

ただし、MOE ビットを無効にすると、実際には ADC トリガが停止します。

メイン出力のみが無効で、タイマーがまだ動作している場合に、ADC が適切なトリガーを取得できない場合に考えられる問題は何ですか?

これが適切な方法ではない場合、出力を単独でオフにする適切な方法は何ですか?

私は STM32 ベアメタル プログラミングを学んでおり、そのクエストでは STM32F429ZI MCU を使用しています。私はインターネットで多くの例を読みましたが、それらはすべて 1 つのリンカ スクリプトしか使用していません。これらの例が私の MCU 用に完成されている場合、リンカー スクリプトは、機能 (?) に関して STM32CubeIDE によって生成されるものと同じになると考えています。

ここで私の質問です。STM32CubeIDE を使用してプロジェクトを生成しSTM32F429ZITX_FLASH.ldたSTM32F429ZITX_RAM.ldときに、2 つのリンカー スクリプトを取得しましたが、ビルド ログを確認すると、 1 つのリンカー スクリプトしか使用されていませんSTM32F429ZITX_FLASH.ld。STM32CubeIDE は、プロジェクトのビルドに 1 つまたは 2 つのリンカー スクリプトを使用しますか? 1 つしか使用しない場合、なぜ 2 つのリンカー スクリプトが生成されたのでしょうか。

以下に、ビルドログを投稿しました。ビルドログで見つけたコマンドは次のとおりです。

arm-none-eabi-gcc -o "STM32F429ZI-Test.elf" @"objects.list" -mcpu=cortex-m4 -T"/home/biomed/STM32CubeIDE/workspace_1.4.0/STM32F429ZI-Test/STM32F429ZITX_FLASH.ld"

Micron MT25Q Quad_SPI フラッシュを搭載した STM32F469 チップを使用しています。フラッシュをプログラムするには、開発された外部ローダ プログラムが必要です。問題は、QSPI フラッシュの検証が非常に遅いことです。

ログ ファイルを見ると、フラッシュが 150K バイトのブロックでプログラムされていることがわかります。ただし、検証は 1K バイト ブロックで行われています。さらに、チップは各ブロック チェックの前に再初期化されます。私はこれを STM32cubeIDE と STM32cubeProgrammer の両方で直接試しました。

外部プログラマ プログラムには、正しいチップ構成情報が含まれており、64K ページ サイズが指定されています。プログラマに大きなブロック サイズを使用させる方法がわかりません。SRAM のどの部分が使用されているかを理解しているようで、オンボード SRAM の残りの 256K を QSPI フラッシュのプログラミングに使用しています。データを読み戻すために同じサイズを使用するか、外部ローダーで Verify() 関数を使用することができます。Read() を呼び出してから、データ自体をチェックしています。

何か考えやヒントはありますか？

新しい外部ローダーの作成に関する観察事項をいくつか追加させてください。最初の観察は「しない」ことです。サポートされている外部チップを選択し、ピンアウトして既存のローダーを使用できる場合は、それを実行してください。STM が提供するサンプル プログラムは 4 つだけですが、50 個の外部ローダーが必要です。ハードウェア設計が外部ローダーを備えたデモ ボードの回路図をコピーする場合は、問題なく開発作業を行う必要はありません。

外部ローダーは完全な実行可能ファイルではありません。Init()、Erase()、Read()、Write() などの基本的な操作を行う関数のセットを提供します。秘訣は、main() がなく、プログラムの開始時に起動コードが実行されないことです。

外部ローダーは、「*.stldr」に名前が変更された ELF ファイルです。プログラミング ツールはデバッグ情報を調べて、関数の場所を見つけます。次に、パラメーターを提供するようにレジスターを設定し、関数を実行する PC を設定してから、実行します。これを機能させるために、非常に巧妙な作業が進行中です。プログラマーは、戻り値 (R0) を見て、成功したかどうかを確認します。また、関数がコアをクラッシュさせたか、それともタイムアウトになったかを把握することもできます。

外部の書き込みを非常に楽しいものにしているのは、デバッガーがプログラムを実行しているため、コードが何を行っているかを確認できるデバッガーが存在しないことです。呼び出された関数からの return() でエラーとエンコードされた情報を出力して、何が起こっているかについてのヒントを与えることにしました。

外部ローダーは「完全な」プログラムではありません。スタートアップ コードがないと、多くのオンチップ機能がセットアップされず、機能しないものもあります。少なくとも私はそれを理解できませんでした。正しく構成されていないのか、デバッガーがその使用をブロックしていたのかはわかりません。外部ローダーの例を見ると、非常に単純な方法で記述されており、HAL を呼び出したり、割り込みを使用したりしていません。クロック チェーンを構成するには、コア セットアップ関数を提供する必要があります。タイマーや割り込みが機能していないため、その Hal_Delay() メソッドは決して戻りません。私はそれらを機能させることができず、NVICが何らかの形で無効になっているのではないかと疑っていました. HAL_delay() 関数を、コア クロック レートとループごとの命令サイクルに基づいて回転する for ループに置き換えることになりました。

アプリ ノートでは、基本機能をデバッグするためのスタンドアロン プログラムを開発することを提案しています。それは良い考えですが、挑戦です。外部ローダーを開始する前に、QSPI に必要な操作を実行させましたが、HAL を呼び出す C++ アプリケーションから実行しました。そこから外部ローダーを作成するのは、機能を取り除いて置き換える長い作業でした。ヒントは、例がレジスタ レベルで記述されていることです。私は、QuadSPI ペリフェラルとチップの命令セットを同時に直接処理するのが得意ではありません。

プログラムの通常の起動は排除されます。main() が呼び出される前に行われるすべてのこと (たとえば、startup_stm32f469nihx.s 内) はあなた次第です。これには、クロック チェーンを設定してコア クロックをブーストし、ペリフェラル バスを機能させることが含まれます。プログラムはオンチップ SRAM で実行されるため、初期化された変数はすべて正しくロードされます。データを移動する必要はありませんが、スタックと初期化されていないデータ領域はゼロにすることができます/まだゼロにする必要があります。

これが誰かに役立つことを願っています！

In short, SLAK bit won't reset when SLEEP bit is manually reset. In details :

I am trying to achieve a successful transmission in loopback mode before venturing into making a network. I had it working at a point after a lot of documentation reading, but now I have a new issue. (Sadly I do not remember what I changed, played with the timings maybe)

After setting the peripheral to loopback and providing coherent bit timing values (so I may have played with them but they are back to being ok), I generate the code with Cube. This implies that the flow should first exit the sleep mode, enter the init mode, do the settings, exit the init mode, and start normal mode. According to the reference manual :

If software requests entry to initialization mode by setting the INRQ bit while bxCAN is in Sleep mode, it must also clear the SLEEP bit. [...] After the SLEEP bit has been cleared, Sleep mode is exited once bxCAN has synchronized with the CAN bus [...]. The Sleep mode is exited once the SLAK bit has been cleared by hardware

and

To synchronize, bxCAN waits until the CAN bus is idle, this means 11 consecutive recessive bits have been monitored on CANRX.

According to wiki

A 0 data bit encodes a dominant state, while a 1 data bit encodes a recessive state

So

Checking the code generated by Cube this is exactly what is happening. I pasted here the essential part from stm32f4xx_hal_can.c :

The SLEEP bit of CAN_MSR is reset and waits for the SLAK bit from CAN_MSR to be reset by the hardware. CAN_TIMEOUT_VALUE is set to 10, basically giving time for the 11 recessive bits to settle in.

And this is where I am stuck. SLACK would not reset... I tried to remove if ((HAL_GetTick() - tickstart) > CAN_TIMEOUT_VALUE) so that the MCU waits indefinitely for a SLAK reset. Did not help.

Looking at the CAN_MSR RX register, giving the current value on RX, while waiting for SLACK to change, I noticed that it is always at 0. So I tried to set GPIOs as pull-up and pull-downs for RX and TX, but I think it has no effect since, in loopback mode, RX of bxCAN is isolated from GPIOs :) This meaning also, that the issue should not be on the hardware side (like wiring and stuff, external things, not internal hardware). Leading me to believe that something is wrong during the global HAL_Init() or MX_GPIO_Init() or other stuff, but since it is generated by Cube and I did not change anything, I don't see how it could have an effect on SLAK not going away.

My idea was maybe to do a software reset, on something, but I don't know where this path will lead me since powering off and on the chip do not resolve the issue...