ねむいさんのぶろぐ

いろいろ試す28

おいおいついにGW来たと思ったらもう一ヶ月経っちまいましたよどういうことだYO!

●STM32L0シリーズを使う

数年前に買ったのですけど暖めすぎて腐っちゃいましたてへ♥

STM32L0シリーズはCortex-M0+をコアに持つ低消費電力特化型のARMマイコンとなって
おります。
この評価ボードSTM32L0538-Discoveryも低消費電力に特化した作りとなっています。

主役のSTM32L0は基板裏面にあります。

目玉はこの電子ペーパーです。電源を切っても表示内容が保存されるという優れもの
ですが通常のドットマトリクス液晶のように簡単には扱えずかつ画面書き換えも長い
時間掛かるのでもっぱら静止画表示に留めておくのがまともな使い方といえます。
L0シリーズ初期のSTM32L053C8が使用されております。

この電子ペーパーのドライバにはSTM32L152が使用されてたりします。

こちらが表示して２ヶ月経過した後の画面です。電源を落としても表示内容が保た
れるのですが時間の経過と共にやはり薄れていきます。おもなターゲットとされて
いる店舗の価格表示板での使用を考えたら十分すぎる保持時間ともいえます。
でも白黒なのはウケるのでしょうか？？？？あとはテキストリーダー用途とか？？

フリーの開発環境から使う場合はおなじみOpenOCDで内蔵フラッシュに書き込みます。
※L0シリーズはかなりクロック落とさないとコケまくります。気を付けてください。

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

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

Open On-Chip Debugger 0.10.0+dev-00143-gf6449a7-dirty (2017-05-20-14:25)

Licensed under GNU GPL v2

For bug reports, read

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

adapter speed: 300 kHz

adapter_nsrst_delay: 100

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

none separate

srst_only separate srst_nogate srst_open_drain connect_deassert_srst

Info : Unable to match requested speed 300 kHz, using 240 kHz

Info : Unable to match requested speed 300 kHz, using 240 kHz

Info : clock speed 240 kHz

Info : STLINK v2 JTAG v28 API v2 SWIM v18 VID 0x0483 PID 0x374B

Info : using stlink api v2

Info : Target voltage: 3.240553

Info : stm32l0.cpu: hardware has 4 breakpoints, 2 watchpoints

Info : Unable to match requested speed 300 kHz, using 240 kHz

Info : Unable to match requested speed 300 kHz, using 240 kHz

adapter speed: 240 kHz

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

xPSR: 0xf1000000 pc: 0x08002148 msp: 0x20002000

STM32L0: Enabling HSI16

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

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

adapter speed: 1800 kHz

adapter speed: 1200 kHz

auto erase enabled

Info : Device: STM32L0xx (Cat. 3)

Info : STM32L flash size is 64kb, base address is 0x8000000

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000000e msp: 0x20002000

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000000e msp: 0x20002000

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000000e msp: 0x20002000

wrote 16384 bytes from file main.elf in 3.218750s (4.971 KiB/s)

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20002000

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20002000

verified 16096 bytes in 0.140625s (111.778 KiB/s)

Info : Unable to match requested speed 300 kHz, using 240 kHz

Info : Unable to match requested speed 300 kHz, using 240 kHz

adapter speed: 240 kHz

adapter speed: 1200 kHz

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:04

書き込み時のログはこんな感じです。
ねむいさん謹製STM32L0デバイス向けフラッシュ書き込み用cfgはねむいさんのOpenOCD
バイナリにもちろん収録済みです！

L0シリーズのフラッシュ書き込みは数年前からOpenOCDに対応していたのですが1Word
ごとのﾁﾏﾁﾏ書きしか対応しておらずねむいさんも｢使えねぇ！｣と判断して肥やしに
しておりましたが今年になってようやくマイコン側ローダーのソースが見直され、
まともに使用できるようになりました。
ちなみ何故そうなってしまったかというとCortex-M3シリーズのSTM32L1シリーズと
フラッシュ書き込み用コードと同じ扱いにしてしまったせいでM0+で使用不可能な
M3の命令がローダのバイトコードとして使用されてしまっていたからなのでした。

ねむいさん当時はNuvotonやKinetisのサポートに躍起になっていたのでSTM32に
関しては簡単なコードの追加程度しかコミットできなかったのですが細かい事
考えたら先にすすめませんのでとりあえずどんどん活用していこうと思います。
いずれはNuvotonもローダのコード見直したいですね～。

というわけでおきぱのラインナップに追加しましたのでよろしくお願いします！
おなじみのUARTにリターゲットしたprintfの実行とメモリ液晶にFONTX2ドライバを
用いて文字表示する内容となっております。
もちろんHALライブラリ対応となっております☆

●過去の記事の正当性について考
3月下旬から続いておりますがぶろぐ上でDropBoxの画像が表示されなくなった問題を
ぽちぽちと地道に修正しております。
201705末現在はアクセス数が多かったESP32・ESP8266・ダイトレ・六甲・STM32F4の
の記事はすべて修正が完了し、STM32F7の修正もほぼ終えたところです。残りは
2016年度以前の小ネタ関連の記事全部と東海自然歩道の記事となりました。

それに伴って自分が書いた過去の記事の内容の見直しも適宜行っています。特に
リンク切れが目立ちますが治せるものは何とか治しています。さすがに3年以上前
の記事になるとどうしても今では誤った概念であると判明したりその時は通じた
手法が現在では通じなかったりといったことが沢山出てきます。ですが対応にも
やはり限界はあります。
こちらの方は私の５年前のぶろぐ記事を参照して知りたい情報が消滅し到達できなかった
ことに言及されておられますが2012年のねむいさんは既に｢CMSISv3以降を使え｣と
アドバイスしているのでそれに従わず自己流でされて勝手に困られて私のせいにされ
てもそれはちょっとちがいますよと、特に免責事項はぶろぐのプロフにも明記して
ありますので私に何年も前の内容を補償する義務はないです。と。
これだけははっきりと真実を伝えたかった。
ていうかへろへろハイカーとかいうのホントなんなんでしょうね…audinさんの旧
ブログのアドレスの居抜きで出来たサイトのようですけど…
とはいえこのまま放置するのは私としても心苦しいので2017年の内容に即したものに
情報を修正させていただきました。

一方こちらの方が指摘されたENとBOOT間違えてた件はESP-WROOM-32から放射された
電磁波の影響からか私の頭がぼけてて完全に私のミスです。

なんにせよどっかの壺にまた｢こいつが書いてることはデタラメ｣とか書かれないよう
世間に公開する前に一息おいて精読して間違いを修正する癖を習慣づけてこれからは
なお一層のこと気を付けて行こうと思いまし、た！

●FatFsが0.13に更新
ChaN氏のFatFsも5月中旬に更新しておりました！
主な更新内容は"syscalls.c"やoptionフォルダ内のコードページ変換テーブル
が廃止されてffsystem.cとffunicode.cに変更されたこと、あと幾つかの定義も
接頭語に"FF_"が付与されて他のソースコードとの定義のバッティングが低減され
てたことです。

exFAT関するルーチンは初登場以降日進月歩で進化しまくっているので皆さん自身
でforumや更新情報を常に確認した方が良いでしょう。

ねむいさん的にはdefineの接頭語に"FF_"が付与されたのが効きました。自分で書
いた部分にも多数のFatFsのdefineで切ってあったので見逃さないように修正して
廻ったので大変です。ですが何とか全部治すことが出来ておきぱに置いてるサポート
中の4種のFatFs移植例も無事0.13対応となっております☆

・STM32F7(HALドライバ使用)
・STM32F4(SPL使用)
・STM32F1(SPL使用)
・LPC4088

おっと、最も重要な事柄が変更されていたのを忘れておりました。
今回の更新からChaNさんのFatFsに関するページは全て英語のみになり日本語に訳
された解説が完全に消滅しました。

昨今のembedded事情を鑑みると有益な情報は凡て英語圏のコミュニティに集約されて
行くのが必然でありこの流れは避けられない事柄ですがねむいさんの知能レベルで
すら英語で意志の疎通が問題なくできておりますので皆さんにとっても問題ないはず
です…よね?(威圧)

●SDカードの規格がV6.00にバージョンアップ
昨年秋にSDv5に更新と報じましたが早いものでA1クラスの定義が追加されたV6.00へと
早々に規格がバージョンアップしております。もう巷ではそのA1クラスのロゴが乗った
SDカードが出回っているようです。

A1クラスの利点は小さいサイズのちまちま読み書きのスピードが一定値以上保証されて
いるという点ですが随所で上がっているベンチマークを見る限りではA1策定以前から
存在する高価格帯の高性能カードと比べると大きな有意差はなさそうです。

ねむいさんは次買うカードはS.M.A.R.T.が採れるDelkinのMLCのやつに決めてますので
しかも今はフラッシュメモリも3D-NANDへの過渡期でSDカードそのものの値段がどん
どん高くなっているのでA1ロゴ付きのカード見かけても手を出さないと思います。
ていうか民生用SDカードの値段が高くなり相対的にDelkinのやつがお求めやすい
値段になっちまいましたので運よく特別収入が発生したら即買いしたいと思います！！
いきなり1000万とか手に入らないかしら…

STM32F7を使ってみる18 -CubeF7がv1.7.0になった(ついでにCubeF4も上がった)-

当らないミサイルやGWが日本に迫る中、STマイクロがリリースしている統合ファーム
ウエアパッケージ群のCubeF7がアップデートしV1.7.0になりました。
ややこしいですがCubeF7中のHALライブラリ本体は1.2.1(CubeF7v1.6.1時)から1.2.2
へとバージョンアップしています。

変更点はCANのライブラリのバグが修正されたことくらいで前回私が指摘していた
幾つかのSDMMC関連ライブラリに関するバグの致命的な部分はそれより前のCubeF7v1.6.1で
修正されていますがまだバグが残ったままとなっています。
でもねむいさんはCubeF7v1.6.1v1.5.0をベースに最新の奴にアジャストしてるので何も影響あり
ませんけどー！！！

ちなみにCubeF4とかの他の品種もアップデートしているようですがHP上で数字だけ
変わっても変更直後はまだ従来の奴だったりする罠がありますのですぐに落とそう
とせず一日ほど待ってからの方がよいです。
ねむいさんは新しモノ好きなのでよくSTマイクロの罠に引っかかるたちです。
この件は昔からフォーラムでたびたび指摘されていますが今に至るまで真剣に対処
されず連携の取れて無さが見て取れるようでちょっと悲しいです。

ちなみに私は現在もDropboxの画像表示できなくなった問題にひたすら対処して
いる段階なのでマイコンその他のアイテムに関する深い解説記事が取れずお預け
状態となっておりますがおきぱのプロジェクトファイルの更新はライブラリの
アップデートとともに月一ペースで更新しておりますのでよろしくお願いします。
今月もちょっと早いですけど5/1版のいつものを更新しました。OpenOCDも新しい
のがマージされたら常に更新掛けてますのでよろしくお願いします。

やる気を保つために次回更新予定のネタを少しお見せします。
OpenOCDのSTM32L0への対応が漸く使い物になるレベルになったので解説を絡めながら
Discovery基板を動かしていく予定です☆

STM32F7を使ってみる17 -とっくの昔ですがCubeF7がv1.6.0になっていた-

前回少しだけ触れましたが、STM32F7向けのHALライブラリCubeF7のバージョンが
v1.5.0(CubeMXの場合v1.5.1)からv1.6.0に上がっておりました。

主な変更点はARMv8系コアのSTM32F7x2・7x3シリーズのレジスタ定義が追加された
事と、SDMMCドライバの大変更、さらに悲願のマルチメディアカード&eMMCサポート
の追加です。

eMMCのサポートはねむいさんも歓迎すべき事柄なのですがソースコードを読み解くと
その期待は完全に裏切られました☠なぜなら…

１.初期化シーケンスさえしっかり記述したら同一のソースコードで読み書きできる
　　はずなのになぜかSDカードとMMCのソースコードがわざわざ分離されている。
　　(↑まじふぁっく)

２."１."のおかげでSDカードとMMCが同時に使用できない。
　　(↑まじふぁっく)

３．MMCの処理中でMMCv4以降のカードで必須のExtCSDレジスタを取得していないため
　　4GB以上のeMMCが全く使用不可能。昨今のeMMCは最低8GBからなので全く無意味。
　　(↑まじふぁっく)

４．DMA転送のコードが適当で使い物にならずデフォのポーリング版しかまともに
　　動作しない。v1.5.0の時は私が手を加えなくともある程度まともに動いていた。
　　(↑まじふぁっく)

５．SD/MMCとも両規格で指定されている電源投入->動作電圧到達後1mSec待ちその
　　後74クロック空撃ちする処理が無くたまにイニシャライズすら失敗するカードが
　　出る。eMMCは一部カードでbootシーケンスの際に74クロックが必須。
　　(↑まじふぁっく)

６．まともなはずのポーリング版でも一見動いてるように見えるけどランダムで
　　ReadもWriteもエラー発生するのが判明orz v1.5.0に戻すと全く問題なし。
　　(↑馬鹿野郎)

私を含め外人さんたちも憤慨していますが最終的にねむいさんのコードで動いたYO!
とのことで胸をなでおろしております。
CubeF7とは関係ないですがこちらの方は歓喜の絶叫を上げております。

ねむいさんはChaN師の｢xxの上手な使い方はxxを使わないことである｣と言う
格言に倣いCubeF7v1.6.0にv1.5.0のSDカードのドライバ(ややこしいですがHALライ
ブラリ自身のバージョンはv1.2.0)を無理やり移植してやりましたよｵﾗｰ！

無理糞移植なものでねむいさんの環境以外で使用するには多少コツが要ります。
１．"stm32f7xx_hal_conf.h"内の"#define HAL_SD_MODULE_ENABLED"をコメント
　　アウトし"#define HAL_MMC_MODULE_ENABLED"を有効にする。

２．ねむいさん謹製の無理糞ドライバ"sdmmc_stm32f7.c"をプロジェクト/makefile
　　のビルド対象にする。

３．"diskio.c","ff_gen_drv.c"はv1.5.0の物を流用する。

４．内部変数はDTCMからとるようにリンカ/スキャッタファイルを設定しておく。
　　(アライメントずれとデータキャッシュ不整合対策です)

"１．"で何故本来は不必要なはずの"#define HAL_MMC_MODULE_ENABLED"を有効にして
いるかと言うと、これを有効にしておかないとstm32f7xx_ll_sdmmc.cで必要なロー
レベルの関数がビルドされずエラーになるからですファッ●ク！
ちなみに"#define HAL_MMC_MODULE_ENABLED"と"#define HAL_SD_MODULE_ENABLED"
を両方とも有効にしていると定義がぶつかって
またまたビルドエラーになりますフ●ァック！１１！！１

そんなこんなでCubeF7v1.6.0でも安定してFatFsが動作するようになっております。
FatFs0.12cの最新パッチやCMSISv5の最新版ヘッダフィルを適用した4月版のソース
コードも先行ですがアップしておりますのでどしどしご利用ください。

一方でむぎたさんは私のドライバを既に試されており残念ながら上手く動作できな
かったとのことですがv1.5.0時代のコードでも大幅にSDMMCのクロック周波数を落と
さないと駄目とのことでSDMMCの各信号波形そのものが変になってる可能性があります。

いわゆるインピーダンスミスマッチ状態で各信号の波形に相当なリンギングが発生
している事が考えられますのでオシロで波形を確認したのちインピーダンス整合用の
直列抵抗(最大47Ω)をSDMMC_CKの出力端(MCUの端子直近に)挿入する、それでも駄目
ならさらに全信号ラインにフェライトビードを挿入する等の措置でクロック周波数を
落とさずに改善できるはずです。そこまでやっても駄目なら配線の引き回し自体に
根本的な問題があるのでmicronのeMMC使用時の設計ルールを参照して基板のレイ
アウト設計から見直す必要があります。

RTOSを絡めて使用されている場合はDMA転送用のメモリ領域がDTCMに割り当てられて
おらずキャッシュの整合性が崩れてこけている可能性もあるため切り分けのために
まずはDMA版ではなくポーリング版で動作確認してみてください。

STM32F7を使ってみる16 -USB-MSCを使ってみる応用編-

前回はSTM32F7のSDMMCインターフェースを用いてDELKINの工業用SDカードからSMARTの
情報をCMD56コマンドを駆使し読み出す事に成功しました。

その前にUSBカードリーダーに直接DELKINのカードを接続した時はDelkinDashboardなる
Windowsアプリを用いるとSMART値を読み出す事が出来るのを確認しています。
そこで今回はUSB接続のカードリーダーに化ける奴でDashboardが使えるかどうか、
いくつか試してみました☆

1．OLYMPUS STYLUS TG-4
　->SMART読み出しOK!
　
　TG-4はねむいさんが品質管理の証拠写真取る際やトレランで大活躍のでぢかめです！

２．STM32Primer2 GNSS Tracker(のUSB-MSCモード)
　
　->SMART読み出しOK!!

いわずと知れたSTM32Primer2を用いたねむいさんのぶろぐ唯一の実用品です。
2009年から今に至るまで8年間、-10度～+40度の過酷な環境を耐え抜き延べ3000km
以上の山道をねむいさんと共に駆け抜けてきたすごい奴です！

３．STM32F746G-Discovery(のUSB-MSC(HighSpeed))
　
　->SMART読み出しOK!!

とりあえずSDカードが読めるUSBカードリーダー(USBマスストレージクラス)なら
何でもいけるような気がしてきましたよぅ･･･

"１．"はともかく"２．"と"３．"についてはUSB-MSCに明示的にCMD56を発行するような
ルーチンは実装していなかったのでこれはつまりCMD56を用いなくても何か別の方法で
SMARTを読み出せられる手段があるのではないかと考えました。

そこでSTM32F746G-Discoveryを使って何が起こってるか解析してみる事にしました。
USB-MSCのSCSIコマンドを解釈するサブルーチンとSDMMCのRead/WriteにPrintfのトラップ
を仕掛けどのSCSIコマンドが発行されているか、またSDカードのどのアドレスに読み書き
を行っているのかを調べます。ファームウェアを柔軟に弄る事が出来るという市販のUSB
カードリーダーでは絶対に出来ない利点がSTM32F7にはあるのです！！

STM32F746G-DiscoveryのSTLinkV2の仮想COMを開いて待機しておいた上でDashboardの
"GO"ボタンを押すと全てが分かってしまった･･･

諸般の事情で細かい解説は省きますがある一定の順序でSDカードの特定のブロック
アドレス群に読み書きを行う事によりCMD56による取得方法と同じSMART情報を得ら
れることがわかりました･･･！

これなら特別なハードウエアを用意しなくても市販のUSBカードリーダーさえあれば
気軽にSMARTとかSDカードの寿命を確認できますね～！
それを組み込んだこいつも更なる進化を遂げてさらに最強に強まることが出来たので
ねむいさんはこれからの近畿自然歩道の攻略に向けて燃えに燃えています！
20170308追:
このような工業用SDカードの寿命診断についてですが実際は頻繁なカードの
取り外しが困難な場所や機器に特に威力を発揮します。
性悪説的に言うとケーシングや樹脂化でSDカードを完全に隠ぺいし第三者から
"SDカードを使用している機器"と分からなくして"何らかのメモリデバイス"と
して見せることにより商売上でSDAのライセンス条件を完全に逃れている場合の
リモートメンテナンスの際にも役立ちます。
正攻法でもCMD56なりUSB-MSC経由でSMART取ればいいので品質管理の面から見て
仕事が進めやすくなるのでメリットだらけですね～♥
20170308追:

でぢかめ向けには大容量品があるUtility+がよさそうですね。これも上記と同じくCMD56&
Windowsツール経由でSMART取れるので特にカードの寿命や動作環境を気にする
プロの人必須のアイテムだと思います。ねむいさんもお金に余裕が出来たら購入して
TG-4と併せて使った感想をレポートしてみたいと思います。

ちなみに民生品のSMART非対応のカードだと失敗しちゃいます。
TDKやApercer配布のSMART取得ツールだと非対応のカード使うと先頭1kb分のデータが
問答無用で破壊されてしまうのですがDelkinDashboardではそういうことはまったく
ありませんが興味本位で非対応のカードで試すのはやめておきましょう！！
とまぁこんなかんじで各メーカごとにSMARTの仕様がバラバラなのでSDAが早く統一
規格作るべきだと思いますよぅ。

さらにおまけですが･･･
解析途中でDELKINカードのパーティションの全容量と実容量が一致してなくてディスク
ユティリティーソフトが異常を検出してておかしいなと思っていたのですが･･･

STM32F7CubeのSDカードドライバ(v1.5.xまで)はSDHCにしか対応してなかったため
SDv1の初期化コマンドすらなかったのは周知のとおりですがUSB-MSCのサンプルも
その仕様を引きずっていたため正しい全容量を返していないのが分かりました。
20170329追:
SDv1どころかSDv2でも正しい全容量を返していないことが分かりました。
別な部分で一番最後の論理ブロックアドレスを示すよう-1している個所があり、
上記の部分で-1してしまうと余分に-1したことになるので実容量より1ブロック
分小さい値が返されてしまいます(ほとんどの場合は512Byte小さい値)。

具体的にはusbd_msc_scsi.cのSCSI_ReadFormatCapacity()で総ブロック数から１を
引いた数をホストPCに送っています。

一方SDHC/SDXC等の大容量のSDカードなら多少の容量の相違は無視できる
ほど小さいので問題はありませんでしたが、Delkinカードは1GBしかないため
ParagonHardDiskManagerではそれを見逃さず無効なパーティションと
見なしたようです。ちなみに値が微妙にずれた状態でもWin7からは普通に
読み書きできてました。
SDナビさん曰く、この値が容量偽装とかでズレが大幅になるとWindowsも
おかしいと検知してフォーマットを促すダイアログが出るようです。
20170329追:

そういえば今年になってv1.6.0が出てSDカード周りが刷新されたのですが待望のMMCが
追加されたのはｲｲのですがなんかいたるところが欠陥だらけで超やばいことになって
いたのですが話が長くなるので次回に続きます･･･