STM32F7を使ってみる7 -秋月さんよりF7Discovery販売記念-

※とある大切な方の訃報を受けて霊場めぐりをしていたため更新が一週間以上遅れて
　ます。すみません。

先々週末、秋月さんよりSTM32F7-Discoveryが販売されました。
入手しやすくなった事によって皆さんもF7に触れるチャンスができたと思います。
ねむいさんもF7ネタで一つ記事を書きたかったのですがいまいち"ぱんち"が弱く
更新に躊躇していたので今回の販売開始は渡りに舟でした。しかももう一つ嬉しい
ニュースも同時にでてきました。


●OpenOCDがSTM32F7の内蔵フラッシュ書き込みに正式対応
7月上旬、私が最初にいじりだしたころからF2/F4系と別系統のSTM32F7のテスト用
ドライバは存在していたのですが秋月さんの販売と時を同じくしてOpenOCDにF7系の
フラッシュ書き込みサポートがF2/F4ドライバに正式にようやく追加されました。

Corex-M7はL1キャッシュを持つのでフラッシュ書き込みルーチンを呼び出すとき
にメモリバリア命令を張って意図した手順で書き込みのための命令を実行させる
ようにしないといけませんでした。
最初にコミットされた時はそんな理由でF7専用のフラッシュになっていましたが
同じMPUを持つF2/F4系でも問題が無かったため結局stm32f2x.cに統合されています。

> "C:¥Devz¥Coreutils¥bin¥make.exe" program

openocd  -s C:/Devz/ARM/OCD/tcl -f target/stm32f7discovery_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.10.0-dev-00104-gf3be0f6-dirty (2015-11-13-09:52)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.org/doc/doxygen/bugs.html

Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD

adapter speed: 2000 kHz

adapter_nsrst_delay: 100

srst_only separate srst_nogate srst_open_drain connect_deassert_srst

Info : Unable to match requested speed 2000 kHz, using 1800 kHz

Info : Unable to match requested speed 2000 kHz, using 1800 kHz

Info : clock speed 1800 kHz

Info : STLINK v2 JTAG v24 API v2 SWIM v11 VID 0x0483 PID 0x374B

Info : using stlink api v2

Info : Target voltage: 3.219974

Info : stm32f7x.cpu: hardware has 8 breakpoints, 4 watchpoints

stm32f7x.cpu: target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0x01000000 pc: 0x0803276c msp: 0x20010000

auto erase enabled

Info : device id = 0x10016449

Info : flash size = 1024kbytes

stm32f7x.cpu: target state: halted

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x20000046 msp: 0x20010000

wrote 786432 bytes from file main.elf in 18.501879s (41.509 KiB/s)

stm32f7x.cpu: target state: halted

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20010000

stm32f7x.cpu: target state: halted

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20010000

stm32f7x.cpu: target state: halted

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20010000

verified 600552 bytes in 2.451303s (239.251 KiB/s)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:21

書き込みはこんな感じです。以前と全く変わってませんね〜。
私が提供しているバイナリはもちろんSTM32F7-Discoveryに対応しています★
また、以前も伝えましたがSTLink/V2-1のファームは2.24.11以降にアップデートして
おいてください。古い番だとmbedのMSCの方のインターフェースと干渉して書き
込みが必ず失敗してしまいます。秋月さんで購入できる奴はさすがに最新版に
なってるはずですのでたぶん問題ないでしょうけど。


●MPUとSDRAMのキャッシュ設定
過去にも少し触れたMPUの事ですが、F2/F4系ではほとんど出番がなかった代物ですが
L1キャッシュが実装されたF7系では極めて重要な意味を持ちます。しっかり考えて設定
しないとパフォーマンスに大きな影響が出てしまいます。

書くいう私もキャッシュの概念をよく理解してなくてDMAで無駄に苦戦したり
してましたが新たにFMCを使ったSDRAMで手落ちを見つけてしまいましたorz


↑AN4667より引用
通常はFMCはD-Cacheを通じてアクセス速度の向上が行われているのですが、それが
有効なアドレス領域はCortex-M7のコア上で制限があります。
SDARAMが割り当てられるアドレス(0xC0000000~)ではご覧のとおりキャッシュ
メモリの恩恵にあやかることができません。


↑AN4667より引用
FMCのSDRAMのアドレスをリマップしてキャッシュが効くアドレス領域に変える
方法もありますがMPUでキャッシュ可の領域に設定してしまう方が簡単です。


MPUの設定はこんな感じです。キャッシュ有効の時に"MPU_ACCESS_NOT_BUFFERABLE"
とするとライトスルーとなります。
ライトバックは"MPU_ACCESS_BUFFERABLE"です。

なお、FMCやSDRAMを有効にしてなくてもMPUはそれらと完全に分離しているので、
設定した瞬間にいきなりHardFaultとかになることはありません。
また、QSPIの領域については前途のとおり元からキャッシュ可になっていますので
特にMPUを設定する必要はないです。


てわけで早速いつものjpegファイルのデコード時間で比較してみましょう。
その１．フラッシュインターフェースはAXIM

↑MPUは何も設定してないSDRAMのD-Cache無効状態です。
　最適化スイッチは-Ofast、FONTX2ドライバは内蔵フラッシュからです。


↑MPUを使ってSDRAMのD-Cache有効、ライトスルーです。
　最適化スイッチは-Ofast、FONTX2ドライバは内蔵フラッシュからです。


↑MPUを使ってSDRAMのD-Cache有効、ライトバックです。
　最適化スイッチは-Ofast、FONTX2ドライバは内蔵フラッシュからです。


予想通りキャッシュ無効のデフォルト状態の方が断然はやi...
…
？？？
？？？どういうことなんだ？？？(←C.V.櫻井のイケボで)

キャッシュ無効が一番早いじゃないですかー！？たぶんAXIMバス経由でプログラムを
実行してるからバスのトランザクションとかキャッシュラインが干渉しまくって
逆にパフォーマンスが低下してしまったのでしょうね。
･･･すみません適当な考察で…てわけでAXIマトリクスの影響を受けないITCMから
プログラムを実行してみますか。

その２．フラッシュインターフェースはITCM

↑MPUは何も設定してないSDRAMのD-Cache無効状態です。
　最適化スイッチは-Ofast、FONTX2ドライバは内蔵フラッシュからです。


↑MPUを使ってSDRAMのD-Cache有効、ライトスルーです。
　最適化スイッチは-Ofast、FONTX2ドライバは内蔵フラッシュからです。


↑MPUを使ってSDRAMのD-Cache有効、ライトバックです。
　最適化スイッチは-Ofast、FONTX2ドライバは内蔵フラッシュからです。

ITCM経由だとバスの競合が減りますので確かにキャッシュが効いているのが
分かりますね★
所で本来ならライトスルーよりライトバックの方が早くなるはずなのですが、
ライトスルーの方がほんの少し早い結果になりました。キャッシュを効かせて
いるとキャッシュヒットとミスの時のブレ幅がかなり大きく出てくるので
そっちの方が気になるくらいですけど。

おきぱのF7のサンプルではAXIM/ITCMの両方でSDRAM領域のMPU有効・ライト
スルーキャッシュ設定にして更新しております。
以前はQSPI-ROMにFONTX2ドライバを置いていた場合文字の表示で崩れる
ことがあったのですがSDRAM領域もMPU・キャッシュ有効にするとそれが
一切発生しなくなったという副次的効果が見られましたのでAXIMだと
若干パフォーマンスが落ちますが敢えてMPUを効かせています。

もちろんキャッシュを経由するとDMAの問題がまた持ち上がってきますが
私のサンプルではDMA2Dをそうなる使い方はしてないのが分かったので
DMA対策は特に行わず様子見としております。

さらについでですがCubeF7もV1.2.0になってHALライブラリもV1.0.2に
アップデートしておりますので差し替えてあります。
でもSDMMCのuint64_tで処理しなきゃならない処理がuint32_tのままで
まだ治ってないので私自らHALライブラリに修正を加えておきましたｸｿｧ！

Go to top of page