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ファイルのデコード時間で比較してみましょう。
その1.フラッシュインターフェースは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から
プログラムを実行してみますか。

その2.フラッシュインターフェースは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ライブラリに修正を加えておきましたクソァ!

Comments

Post a Comment








Go to top of page