Kinetis KEシリーズを使う

先月に引き続き温め過ぎて腐っちゃったシリーズ第2弾いきます!



元はFreeScle社製でしたがNxPに喰われさらにQualcommに丸ごと喰われてしまう予定で
すが+5V動作可能なARMマイコン、Kinetis-Eシリーズは現在も順調に展開されております。
(ていうか今のラインナップ5Vで168MHzで動くM4コア製品まで拡張されてるのか…)

今回はその最初期にリリースされたKE02シリーズとその評価ボード(以下FRDM板)を紹介
させてもらいます。
ボードの背後でいないさんが何かを主張していますが気にしないでください★


もともとノイズの多い環境でノイズ耐量を得る目的として開発されたマイコン故に+3.3V
動作はもちろんの事+5Vでも動きますがそれ故に動作周波数は当時はM0+コアの中でも
特に低く、AVRと同じ20MHz動作が上限となっています。
内蔵Flash/SRAMも其々最大64kB/4kBとささやかものとなっています。


当時はまだFreeScale預かりだったのでサンプルコードもKLシリーズとかよりもさらに
適当な奴しかなく、Keilのu'Visionに収録されたサンプルコードやヘッダファイルを
参考にGCC向けにプロジェクトを落とし込んでみました。


基本的なMCUアーキテクチャは従来のKinetisと全く同じなので不用意な書き換えですぐにBricked
ってしまう問題も健在です☠


KEシリーズのフラッシュ書き込み機構は従来とは違い、レジスタ構成がまったく別のもの
になっているのでOpenOCDのフラッシュ書き込み用のソースは他のKinetisシリーズとは
別のものになっています。ねむいさん評価報告やっただけだけですけどなんでか知らなんのです
けどソースの作者名に名前連ねてもらっています。ありがとうございます。

> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jlink_swd.cfg -f target/kexx_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.10.0+dev-00161-g1725abc-dirty (2017-06-23-00:33)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
swd
Info : add flash_bank kinetis_ke kexx.pflash
cortex_m reset_config sysresetreq
none separate
adapter speed: 1000 kHz
Info : No device selected, using first device.
Info : J-Link OpenSDA 2 compiled Oct 13 2015 12:10:56
Info : Hardware version: 1.00
Info : VTarget = 3.300 V
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x0bc11477
Error: MDM: failed to read ID register
Error: MDM: Failed to check security status of the MCU. Cannot proceed further
in procedure 'init' called at file "C:/Devz/ARM/OCD/tcl/target/kexx_swd_flash.cfg", line 125
in procedure 'ocd_bouncer'

Info : SWD DPIDR 0x0bc11477
Info : kexx.cpu: hardware has 2 breakpoints, 2 watchpoints
Info : MDM: Chip is unsecured. Continuing.
target halted due to debug-request, current mode: Thread
xPSR: 0x21000000 pc: 0x000000cc msp: 0x20000c00
Info : Watchdog stopped
auto erase enabled
Info : KE02 sub-family
Info : Flash clock ready
Warn : flash configuration field erased, please reset the device
Info : Flash clock ready
Info : Kinetis KE: FLASH Write ...
wrote 8192 bytes from file main.elf in 0.734375s (10.894 KiB/s)
verified 7936 bytes in 0.093750s (82.667 KiB/s)
Info : MDM: Chip is unsecured. Continuing.
shutdown command invoked

> Process Exit Code: 0
> Time Taken: 00:01
OpenOCDでフラッシュ書き込みした時のログはこんな感じです。

かつて幾つかのKinetisの品種では通常のreset initで繋ぎに行くとウォッチドッグ
リセットが発動し、上手くhaltしないと言う問題があってちょっとトリッキーなcfgを
組む必要があったのですが最近のコミットでソースコードそのものとcfgとで連携して
ひとまずウォッチドッグを止めに行く措置が取られ、ほぼすべてのKinetisの品種で
安定して書き込み・デバッグができるようになりました。

ちなみにFlexRAMやFlexNVMを設定している場合でもコケないで正しく書き込みが
出来るようにも修正されています。数年前はかなり危ない実装だったんスね…

FRDM板の標準デバッガはOpenSDAですがはっきり言ってあまり使えないので速攻
J-Linkに差し替えてしまいましょう!上記ログもJ-Linkで繋ぎにいったものとなって
います!


JLinkのファームに書き換えるとmbed対応済の証であるマスストレージが見えます。
ちゃんとドライブラベルもJLinkになってて芸が細かいですね。使いませんけど。


ちなみにねむいさんのこさえたプログラムはLED点滅をしながら…


FRDM板上にある速度センサの値をprintf関数で返すという評価板の機能フルに利用
したものとなっております☆
尤も冒頭で述べたとおりこのボードで使用されているKE02ZはKEシリーズの最初期
の品種でコアクロック上限が20MHzまでとなるのでUARTのボーレートもねむいさん
標準の230400bpsではさすがに無理で115200bpsに落としています。

最初購入した当初はノイズ云々はサブ的なものでホントは8bitな+5Vマイコンの置き
換え狙いかと思っていましたが2017年現在では168MHzで動くCortex-M4の品種にも
拡大されておりノイズに厳しい環境下での使用をマジで狙ったものとなっているようです。
私も興味が出てきましたのでM4コアの奴が手に入ったらまたレポートさせて頂きます!

いろいろ試す28

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

●STM32L0シリーズを使う

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


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

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


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


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


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

フリーの開発環境から使う場合はおなじみ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年以上前
の記事になるとどうしても今では誤った概念であると判明したりその時は通じた
手法が現在では通じなかったりといったことが沢山出てきます。ですが対応にも
やはり限界はあります。
こちらの方は私の5年前のぶろぐ記事を参照して知りたい情報が消滅し到達できなかった
ことに言及されておられますが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系コアのSTM32F7x27x3シリーズのレジスタ定義が追加された
事と、SDMMCドライバの大変更、さらに悲願のマルチメディアカード&eMMCサポート
の追加です。

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

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

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

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

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

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

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

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


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

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

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

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

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


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

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


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

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

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

Go to top of page