ねむいさんのぶろぐ

S.M.A.R.T.が採れて安価なTranscendの民生向けSDカードを試す！

あけましておめでとうございます(もう1月末ですが)

今年は節目となるイベントがたくさんありますのでよろしくお願い
いたします…！！

さて、新年一発目はTranscend製でS.M.A.R.T.(以下SMART)が取れる
SDカード、それもいつもの産業用じゃなくて民生用で安価なものを
紹介させていただきます…！！

TranscendのHPに記載があってびっくりしたのですが民生品で
SMARTに対応しているのを明記してるのが出てきておりました。
Ultra Performanceと呼ばれるUSD340S/SDC340Sシリーズです！

このシリーズはSD SMART Toolboxなるもので上記カードから
SMARTの情報を読み取り使用量を把握できるものとなっているそうです。

ねむいさんもさっそく購入して試してみました！
大阪日本橋のPCOne'sで購入したのは128GB容量のTS128GUSD340Sです。

しかし…

ﾁｰﾝ

使用USBカードリーダーがTranscendのTS-RDF5でしかも2019年以降
製造のロットじゃないとダメだったようです…

てわけでRDF5の2020年以降製造と思われるカードリーダーを
購入してまいりました…！！！

ﾁｰﾝ

…

なんでだYO！！１！！

念のためねむいさんのFatFs実装例(STM32H5版)でCMD56放ってみましたが
全部0が返ってくる状態でSMART情報は得られませんでしたorz

もしかしてカードの方もほんとに最新のやつじゃないとSMARTに対応して
いないのでは…2022年製造の奴は古いってことですか…

念のためSDカードの情報を引っ張っておきました。

FatFs module test terminal for STM32H563ZIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Jan 17 2025

>fg piano



rc=0 FR_OK

>fo 1 ftbt.mp3



rc=0 FR_OK

>fr 132949600



132949600 bytes read at 17869 kB/sec.

>fs



FAT type = exFAT

Bytes/Cluster = 131072

Number of FATs = 1

Root DIR entries = 32717

Sectors/FAT = 16384

Number of clusters = 923424

Volume start (lba) = 32768

FAT start (lba) = 49152

DIR start (lba,clustor) = 4

Data start (lba) = 65536



Volume name is 128GUSD340S

Volume S/N is 0977-190A

...

1 files, 132949600 bytes.

0 folders.

118198272 KiB total disk space.

118067456 KiB available.

>ds 0



rc=0

Drive size: 236462080 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 DB 79 00 03 86 07 7F 80 0A 40 00 BD  @..2.y.......@..

CID:

00000000  74 4A 60 55 53 44 55 31 20 28 0A 09 9B A1 69 7B  tJ`USDU1 (....i{



Parsing SD CID Register

Manufacturer ID    :0x74

OEM/Application ID :J`

Product Name       :USDU1

Product HwRev      :2

Product SwRev      :0

Serial Number      :0x280A099B

DateCode.Month     :9

DateCode.Year      :2022



OCR:

00000000  C1 FF 80 00  ....

SD Status:

00000000  80 00 00 00 08 00 00 00 04 00 90 00 08 11 39 1E  ..............9.

00000010  00 08 00 00 00 02 FC 00 00 00 00 00 00 00 00 00  ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

SCR:

00000000  02 05 84 87 00 00 00 00  ........



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Spec Version X  :2

SD Security        :0

SD Bus Width       :5



SD_Spec V6.xx!

Detected as Not SD Card!

Available UHS-I Mode.

Available UHS Speed Class U3.

Available SD Speed Class 10.

Available Video Speed Class 30.

Available Application Performance Class2, A2 Card.

A2 CommandQueue Depth 32 Supported

A2 Cache Supported.

なんかすごい気になったのはSD Securityの値が"0"になってて
CPRMサポートしていないようなんですよね…。
SD Securityビットの値でSDSC/SDHC/SDXCの判別してたのでちょっと
困ったことになりました…
ちなみにSDUCではCPRMサポートは完全除外されSD Securityビットも
0となるでしょうから別の方法でカード種別の判別するしかないですね。

気を取り直して店変えて買いなおしました…
今度はAMAZONでTranscend直売のTS64GUSD340S買ってみました…
これならたぶん古くとも2023年くらいでしょー…(願望)

そして…

！！
やったぁ！SMARTが取れた！
2024年10月製造のモデルでした！

ちなみに5年前、TranscendEmbedded様より超ご厚意でいただいた
"SD SMART Tool"でも無事にSMART情報を得ることができました。
やっぱこっちのほうが詳細が分かってよいですね～
そしてこちらは2019年以前のRDF5でも普通に使えます。
なんで製造年数縛りでソフト作ったのでしょうか…???

ていうわけでこっちのカードもSDの情報抜き出しときます。

FatFs module test terminal for STM32H563ZIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Jan 31 2025

>fg piano



rc=0 FR_OK

>fo 1 ftbt.mp3



rc=0 FR_OK

>fr 132949600



132949600 bytes read at 20381 kB/sec.

>fs



FAT type = exFAT

Bytes/Cluster = 131072

Number of FATs = 1

Root DIR entries = 28621

Sectors/FAT = 16384

Number of clusters = 471032

Volume start (lba) = 32768

FAT start (lba) = 49152

DIR start (lba,clustor) = 4

Data start (lba) = 65536



Volume name is 64GUSD340S

Volume S/N is FBDE-D5FB

...

1 files, 132949600 bytes.

0 folders.

60292096 KiB total disk space.

60161664 KiB available.

>ds 0



rc=0

Drive size: 120649728 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 DB 79 00 01 CC 3D 7F 80 0A 40 00 47  @..2.y...=...@.G

CID:

00000000  74 4A 60 55 53 44 55 31 20 76 0B 46 98 A1 8A 27  tJ`USDU1 v.F...'



Parsing SD CID Register

Manufacturer ID    :0x74

OEM/Application ID :J`

Product Name       :USDU1

Product HwRev      :2

Product SwRev      :0

Serial Number      :0x760B4698

DateCode.Month     :10

DateCode.Year      :2024



OCR:

00000000  C1 FF 80 00  ....

SD Status:

00000000  80 00 00 00 08 00 00 00 04 00 90 00 08 11 39 1E  ..............9.

00000010  00 08 00 00 00 02 FC 00 00 00 00 00 00 00 00 00  ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

SCR:

00000000  02 45 84 87 00 00 00 00  .E......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Spec Version X  :2

SD Security        :4

SD Bus Width       :5



SD_Spec V6.xx!

Detected as SDXC Card!

Available UHS-I Mode.

Available UHS Speed Class U3.

Available SD Speed Class 10.

Available Video Speed Class 30.

Available Application Performance Class2, A2 Card.

A2 CommandQueue Depth 32 Supported

A2 Cache Supported.

ん？こっちはちゃんとSD Securityのところが4(SDXC)になってる…?
う～～むSDカードは水物でほんとによくわからん

そんでもってCMD56で抜き出したSMARTのデータも置いておきますので
ご参考に…512バイトのSMARTのデータのフォーマットはかつての
産業用SD/microSDと同じでした。だから同じツールが使えたのですね。

そんなわけで2025年になってようやく民生品レベルにもSMARTを搭載した
SD/microSDカードが浸透し始めた段階です。
まさに民生向けSDカードのSMART元年とでも言いましょうか…
願わくばSDの規格にSMARTが正式に搭載されることを祈り続け今後の
発展を見守ることにしましょう…

今回のまとめ
・Transcendの340Sシリーズは安価な民生品だがSMARTを搭載している。
・SMARTを見るためには以下の条件が必要。
　①2024年以降製造のカード必須。それ以前のものはSMARTが無いかも。
　②TS-RDF5が必要。しかも2019年以降製造のモデル必須。
　　※マイコンとかで直接CMD56を放つ場合はTS-RDF5不要。
・CMD56の引数やSMARTのデータフォーマットはTransendの
　2021年以降新規発表・販売モデルの産業用SD/microSDと同一。

・SMARTの詳細は過去記事も参照のこと。

いろいろ試す64　- 2024年反省会 -

あっという間に2024年もおしまいです…。

副業(本業は虹裏メイド)が多忙になってしまい出来ることが少なく
なってしまいましたができる限り拾ってまいりました…！

●arm-gcc更新
arm-gccが12月10日付で更新しておりました。

今回のリリースからWindows向け64bit版のツールチェインも追加と
なっております。x86_64ってやつですね。i686が32bit版です。

なお、前回詰まってしまったGDBの挙動がおかしかった件ですが、上記の
64bit版ツールチェイン付属のARM-GDBでは修正されていました。

"tbreak main"がしっかり効いてデバッグ開始時にmain関数の先頭で
ちゃんと停止してくれます。一方で32bit版は相変わらずダメでした。
これからは64bit版を使っていきましょう。

昨今のOSは64bitが主流なので特に強い理由がない限りは64bit版の
ツールチェインを選択していくことになりますね。

…これでやっとARMマイコンデバッグ手順の更新ができる…かな？

●FatFsが0.15aに更新
ChaN'師のFatFsも先月末に更新しておりました。
小規模な変更だったので移植もスムーズにすることができました。

私のFatFs移植例にも反映しておりますのでどしどしご利用ください！
*STM32H7
*STM32H5
*STM32F7
*STM32F4

●OpenOCDのSTM32U0正式対応
ついにやってきましたね…半年以上待ちましたがー！

書き込み時のログはこんな感じです↓

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

openocd  -s C:/Devz/ARM/OCD/tcl -f interface/stlink-dap.cfg -c "transport select dapdirect_swd" -f target/stm32u0x_swd_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.12.0+dev-00823-g4f2744d0f (2024-12-31-14:06)

Licensed under GNU GPL v2

For bug reports, read

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

WARNING: interface/stlink-dap.cfg is deprecated, please switch to interface/stlink.cfg

Info : STLINK V2J45M31 (API v2) VID:PID 0483:3752

Info : Target voltage: 3.234510

Info : Unable to match requested speed 500 kHz, using 480 kHz

Info : Unable to match requested speed 500 kHz, using 480 kHz

Info : clock speed 480 kHz

Info : stlink_dap_op_connect(connect)

Info : SWD DPIDR 0x6ba02477

Info : [stm32u0x.cpu] Cortex-M0+ r0p1 processor detected

Info : [stm32u0x.cpu] target has 4 breakpoints, 2 watchpoints

Info : [stm32u0x.cpu] Examination succeed

Info : [stm32u0x.cpu] starting gdb server on 3333

Info : Listening on port 3333 for gdb connections

[stm32u0x.cpu] halted due to breakpoint, current mode: Thread 

xPSR: 0xf1000000 pc: 0x08002b28 msp: 0x2000a000

Info : device idcode = 0x10006489 (STM32U073/U083xx - Rev A : 0x1000)

Info : RDP level 0 (0xAA)

Info : flash size = 256 KiB

Info : flash mode : single-bank

Warn : Adding extra erase range, 0x08004d20 .. 0x08004fff

Info : wrote 19744 bytes from file main.elf in 0.969477s (19.888 KiB/s)

Info : verified 19744 bytes in 0.512074s (37.653 KiB/s)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:02

以前と変わりはほぼありませんね。

もちろんデバッグも自由自在です。

これでSTM32U0も(正式に)バリバリ開発ができるようになります！
わたしのおきぱにもOpenOCDバイナリを置いていますのでこちらも
大いにご利用ください！
…あとは昨年から放置状態のSTM32H5のフラッシュ対応待ちですね…！

また、夏にコミットされたgdbコマンド体系の再編への対応について、
ねむいさん特製フラシュ書き込み用cfgファイルは対応しておらず
書き込みとかデバッグするたびにwarning出まくりで放置状態でした。

今回のブログ記事を書くにあたりようやっと対応させてみました。
もうwarningは出ませんので安心してご使用ください。

●avrdudeがいつの間にかV8.0に
かつての停滞が嘘のようにまさに日進月歩の進化を遂げるようになった
AVRマイコン書き込みプログラムavrdudeですがV8.0まで上がっております。

ちなみに上がったの8月だったんですが更新したの紹介して
ませんでした。かなりの修正と機能追加がされております。
AVR-EBシリーズ使うならV8.0以降が必須となります。

こちらも私がビルドした最新のバイナリを挙げていますので
ご利用ください～！

●2024年反省会
…ぇっと…今年はやりたいこと全くできなかったのですが来年は…

①2025年度版のarmマイコンビルド・デバッグ手順の作成
②STM32H5を使ったmp3プレーヤーの作成

の達成を目標にがむばっていきたいとおもいます…！！

それでは皆様良いお年を～

いろいろ試す63

ああもうこんな季節だ…忙しいのに頭が空回りで何もできていない…
とりあえずできることをできるだけ頑張っていく…!!

●ねむいさんのぶろぐhttps化
タイトルの通りでござます。私のぶろぐの母体"びぃブログ"の仕様が
常時https化したことにより私のぶろぐもhttpsに強制的に変わったの
ですが…

10年来使用してきたソースコードハイライト機能syntax highliterが
今回のhttps化で機能しなくなったのが判明し別のハイライト機能に
切り替えることにしました。それで見つかったのがhighlight.jsです。

かつてのsyntax highliterとほぼ同じ表示感覚で使用でき、表示方法も
ほぼ同じ感覚でした。9月末からhighlight.jsを導入しております。

こんな感じにソースコードの

//ハイライト表示ができます

しかしながらhtmlタグがsyntax highliterのころとは微妙に違うので
過去にさかのぼってブログの記事をせっせと修正しました…
くそ…もっと早くやっておけばよかった…
いちおうすべての記事でhighlight.jsに対応しましたが疲れた…

●OneDriveが仕様変更で古い共有リンク全滅
あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”あ”！！！！
9月末くらいの仕様変更でおきぱにおいてあるSTM32のプロジェクトとか
OpenOCDバイナリとかのリンク全部不通になってたぁああああ！！！

というわけでこちらにも対応して全部共有リンクを再生成してソース
コード置き場のリンクはちゃんとダウンロードできるよう修正いたし
ました…あとは過去のぶろぐ中に張った直リンクたちですが数が膨大に
あるのですがこちらもできる範囲で適宜修正していこうと思います…

また、記事を見直して10年以上前の古いものはリンク仕舞いする個所も
あるのでご注意願います…なるべく残せるようにがむばります…

●最新のarm-gccのgdbの挙動がおかしい？
う～～ん私のやり方が悪いのかどっちが悪いのか断定はできませんが
現時点で最新のArm GNU Toolchain　Version 13.3.Rel1のgdbなんですが、
なんでか"tbreak main"が効かずデバッグ開始時にmain関数の先頭で
止まってくれません。

*問題の13.3.Rel1(GDB14.2)の場合

ソースコードはスタートアップの最初のところを示していますが
breakがかからずそのままプログラムが走ってしまいます。
↓ログはこんな感じ。Continuing...の後音沙汰がありません。

Using gdbinit file: C:¥Users¥nemuisan¥.codelite-gdbinit

Current working dir: R:¥STM32H563xxx_NUCLEO_20241101¥lib¥codelite_dbg¥codelite_dbg

Launching gdb from : ../../../

Starting debugger  : C:¥Devz¥arm¥launchpad¥bin¥arm-none-eabi-gdb.exe --command="C:¥Users¥nemuisan¥.codelite-gdbinit" --interpreter=mi "main.elf"

Debug session started successfully!

GNU gdb (Arm GNU Toolchain 13.3.Rel1 (Build arm-13.24)) 14.2.90.20240526-git

Copyright (C) 2023 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later ¥nThis is free software: you are free to change and redistribute it.¥nThere is NO WARRANTY, to the extent permitted by law.

¥nType "show copying" and "show warranty" for details.

This GDB was configured as "--host=i686-w64-mingw32 --target=arm-none-eabi".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

.

Find the GDB manual and other documentation resources online at:¥n    <

http://www.gnu.org/software/gdb/documentation/>.¥n

For help, type "help".

Type "apropos word" to search for commands related to "word"...

Reading symbols from main.elf...

Output radix now set to decimal 16, hex 10, octal 20.

`R:¥STM32H563xxx_NUCLEO_20241101¥main.elf' has changed; re-reading symbols.

Remote debugging using localhost:3333

Reset_Handler () at lib/CMSIS/Device/ST/STM32H5xx/Source/Templates/gcc/startup_stm32h563xx.s:59

59¥t  ldr   r0, =_estack

Successfully connected to debugger server

Applying breakpoints...

Applying breakpoints... done

Unable to match requested speed 480 kHz, using 200 kHz

Unable to match requested speed 480 kHz, using 200 kHz

[stm32h5x.cpu] halted due to breakpoint, current mode: Thread

xPSR: 0xf9000000 pc: 0x08053624 msp: 0x20050000, semihosting

Note: breakpoint 1 also set at pc 0x8000252.

Temporary breakpoint 2 at 0x8000252: file src/main.c, line 41.

Continuing...

*ひとつ前の13.2.Rel1(GDB13.2)の場合

ちゃんとmain関数の先頭で停止します。
↓ログはこんな感じ

Current working dir: R:¥STM32H563xxx_NUCLEO_20241101¥lib¥codelite_dbg¥codelite_dbg

Launching gdb from : ../../../

Starting debugger  : C:¥Devz¥arm¥launchpad¥bin¥arm-none-eabi-gdb.exe --command="C:¥Users¥nemuisan¥.codelite-gdbinit" --interpreter=mi "main.elf"

Debug session started successfully!

GNU gdb (Arm GNU Toolchain 13.2.rel1 (Build arm-13.7)) 13.2.90.20231008-git

Copyright (C) 2023 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later ¥nThis is free software: you are free to change and redistribute it.¥nThere is NO WARRANTY, to the extent permitted by law.

¥nType "show copying" and "show warranty" for details.

This GDB was configured as "--host=i686-w64-mingw32 --target=arm-none-eabi".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

.

Find the GDB manual and other documentation resources online at:¥n    <

http://www.gnu.org/software/gdb/documentation/>.¥n

For help, type "help".

Type "apropos word" to search for commands related to "word"...

Reading symbols from main.elf...

Output radix now set to decimal 16, hex 10, octal 20.

Remote debugging using localhost:3333

Note: automatically using hardware breakpoints for read-only addresses.

Reset_Handler () at lib/CMSIS/Device/ST/STM32H5xx/Source/Templates/gcc/startup_stm32h563xx.s:59

59¥t  ldr   r0, =_estack

Successfully connected to debugger server

Applying breakpoints...

Applying breakpoints... done

Unable to match requested speed 480 kHz, using 200 kHz

Unable to match requested speed 480 kHz, using 200 kHz

[stm32h5x.cpu] halted due to breakpoint, current mode: Thread

xPSR: 0xf9000000 pc: 0x08053624 msp: 0x20050000, semihosting

Note: breakpoint 1 also set at pc 0x8000252.

Temporary breakpoint 2 at 0x8000252: file src/main.c, line 41.

Continuing...

Temporary breakpoint 1, main () at src/main.c:41

41¥t¥tSet_System();

古いほうは古いほうでちょっと問題があってなんでかバイナリサイズが
256MBもあるデバッグビルドになっており、elfファイルの読み込み時間も
時間がかかります(私の環境ではそこまで気にならなかった)。

切り分けのためにFreddieChopin氏のarm-gcc野良ビルド"Bleeding-Edge"
を使ってみます…(32bit版が動作しなかったので64bit版を使います)

GDBが14.2になったのが原因なら同じ14.2なら再現性があるはずですが…

ちゃんとmain関数の先頭で停止しますね…。

Using gdbinit file: C:¥Users¥nemuisan¥.codelite-gdbinit

Current working dir: R:¥STM32H563xxx_NUCLEO_20241101¥lib¥codelite_dbg¥codelite_dbg

Launching gdb from : ../../../

Starting debugger  : C:¥Devz¥arm¥launchpad¥bin¥arm-none-eabi-gdb.exe --command="C:¥Users¥nemuisan¥.codelite-gdbinit" --interpreter=mi "main.elf"

Debug session started successfully!

GNU gdb (bleeding-edge-toolchain) 14.2

Copyright (C) 2023 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later ¥nThis is free software: you are free to change and redistribute it.¥nThere is NO WARRANTY, to the extent permitted by law.

¥nType "show copying" and "show warranty" for details.

This GDB was configured as "--host=x86_64-w64-mingw32 --target=arm-none-eabi".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

.

Find the GDB manual and other documentation resources online at:¥n    <

http://www.gnu.org/software/gdb/documentation/>.¥n

For help, type "help".

Type "apropos word" to search for commands related to "word"...

Reading symbols from main.elf...

Output radix now set to decimal 16, hex 10, octal 20.

Remote debugging using localhost:3333

Note: automatically using hardware breakpoints for read-only addresses.

Reset_Handler () at lib/CMSIS/Device/ST/STM32H5xx/Source/Templates/gcc/startup_stm32h563xx.s:59

59¥t  ldr   r0, =_estack

Successfully connected to debugger server

Applying breakpoints...

Applying breakpoints... done

Unable to match requested speed 480 kHz, using 200 kHz

Unable to match requested speed 480 kHz, using 200 kHz

[stm32h5x.cpu] halted due to breakpoint, current mode: Thread

xPSR: 0xf9000000 pc: 0x08053624 msp: 0x20050000, semihosting

Note: breakpoint 1 also set at pc 0x8000252.

Temporary breakpoint 2 at 0x8000252: file src/main.c, line 41.

Continuing...

Temporary breakpoint 1, main () at src/main.c:41

41¥t¥tSet_System();

FreddieChopin氏一番新しい版はGDB15.2まであがっておりましたので
こちらでも念のため確認してみます。

こちらもちゃんとmain関数の先頭で停止します。

Using gdbinit file: C:¥Users¥nemuisan¥.codelite-gdbinit

Current working dir: R:¥STM32H563xxx_NUCLEO_20241101¥lib¥codelite_dbg¥codelite_dbg

Launching gdb from : ../../../

Starting debugger  : C:¥Devz¥arm¥launchpad¥bin¥arm-none-eabi-gdb.exe --command="C:¥Users¥nemuisan¥.codelite-gdbinit" --interpreter=mi "main.elf"

Debug session started successfully!

GNU gdb (bleeding-edge-toolchain) 15.2

Copyright (C) 2024 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later ¥nThis is free software: you are free to change and redistribute it.¥nThere is NO WARRANTY, to the extent permitted by law.

¥nType "show copying" and "show warranty" for details.

This GDB was configured as "--host=x86_64-w64-mingw32 --target=arm-none-eabi".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

.

Find the GDB manual and other documentation resources online at:¥n    <

http://www.gnu.org/software/gdb/documentation/>.¥n

For help, type "help".

Type "apropos word" to search for commands related to "word"...

Reading symbols from main.elf...

Output radix now set to decimal 16, hex 10, octal 20.

Remote debugging using localhost:3333

Note: automatically using hardware breakpoints for read-only addresses.

Reset_Handler () at lib/CMSIS/Device/ST/STM32H5xx/Source/Templates/gcc/startup_stm32h563xx.s:59

59¥t  ldr   r0, =_estack

Successfully connected to debugger server

Applying breakpoints...

Applying breakpoints... done

Unable to match requested speed 480 kHz, using 200 kHz

Unable to match requested speed 480 kHz, using 200 kHz

[stm32h5x.cpu] halted due to breakpoint, current mode: Thread

xPSR: 0xf9000000 pc: 0x08053624 msp: 0x20050000, semihosting

Note: breakpoint 1 also set at pc 0x8000252.

Temporary breakpoint 2 at 0x8000252: file src/main.c, line 41.

Continuing...

Temporary breakpoint 1, main () at src/main.c:41

41¥t¥tSet_System();

ううむ…バージョンの違いで起こった現象でもなさそうですしビルド環境の
差なのでしょうか…あとARM公式のはx86版なのが気にかかりますが…
ひとまずはFreddieChopin氏の物を使ってその場をしのぎつつARM公式の
次回リリース版のGDBの挙動を待つとしましょうか…
CodeLiteを使ったデバッグ方法を何とか安定させ正式に公開したいのですが
なかなか手ごわいです…

STM32U0はぢめました

買ってから3か月以上たってしまいましたがまだ私が国内一番乗りかな！？
STM32L0の省電力性をさらに高めてなおかつパフォーマンスも妥協しない
新シリーズとしてSTM32U0が登場しました。

MCUの拡大写真です。
パッケージに二次元バーコードがついていて時代の流れを感じさせますね。

STM32U0シリーズは現在STM32U031x,STM32U73x,STM32U83xの3種がライン
ナップされておりますがねむいさんはフラッシュ容量最大のSTM32U083RCT6を
搭載したNUCLEO-U083RCを購入しました。

STLink部分はSTLinkV2-1相当ですがコネクタがUSB-TypeCとなってますね。

また、STLinkを電気的に切り離し外部からデバッガ接続できる構造になって
いますが2mmピッチの独自14ピンコネクタなのはちょっと扱いづらいです…
これは完全にSTLinkV3-MINIEを接続することを意識したものでしょうか？

まぁNUCLEO基板搭載のSTLinkV2で十分事足りるので外部デバッガの登場は
ないと思います。

●ところで肝心のOpenOCDの対応状況は？
御多忙にもれず未だ誰も触れてない理由としてはOpenOCDがまだSTM32U0
のフラッシュ書き込みに正式対応してないことにあると思います。

ちなみにgerritにパッチは上がっておりますが現在パッチ自身に不備が
あって普通にあてただけだとビルドエラーになります…F**K!!!!
そしてそのままずっと放置されております…おいおい

というわけでねむいさんサイドでちょっと手直ししてU0シリーズにも
対応させてみました。ドライバの分類としてはSTM32G0,STM32C0と同じく
STM32L4のグループに属するようですね。
STM32U0対応のOpenOCDダウンロードはこちらからどうぞ！

上記OpenOCDのバイナリには収録しておりますが、フラッシュ書き込みや
デバッグの基底となるstm32u0.cfgも存在してなかったので今回作って
収録しております。

# SPDX-License-Identifier: GPL-2.0-or-later



# script for stm32u0x family

#

# stm32u0 devices support SWD transports only.

#



source [find target/swj-dp.tcl]

source [find mem_helper.tcl]



if { [info exists CHIPNAME] } {

	set _CHIPNAME $CHIPNAME

} else {

	set _CHIPNAME stm32u0x

}



set _ENDIAN little



# Work-area is a space in RAM used for flash programming

# By default use 6kB

if { [info exists WORKAREASIZE] } {

   set _WORKAREASIZE $WORKAREASIZE

} else {

   set _WORKAREASIZE 0x1800

}



#jtag scan chain

if { [info exists CPUTAPID] } {

   set _CPUTAPID $CPUTAPID

} else {

   # SWD IDCODE (single drop, arm)

   set _CPUTAPID 0x0bc11477

}



swj_newdap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID

dap create $_CHIPNAME.dap -chain-position $_CHIPNAME.cpu



set _TARGETNAME $_CHIPNAME.cpu

target create $_TARGETNAME cortex_m -endian $_ENDIAN -dap $_CHIPNAME.dap



$_TARGETNAME configure -work-area-phys 0x20000000 -work-area-size $_WORKAREASIZE -work-area-backup 0



flash bank $_CHIPNAME.flash stm32l4x 0x08000000 0 0 0 $_TARGETNAME

flash bank $_CHIPNAME.otp   stm32l4x 0x1fff6800 0 0 0 $_TARGETNAME



# reasonable default

adapter speed 2000



adapter srst delay 100

if {[using_jtag]} {

	jtag_ntrst_delay 100

}



reset_config srst_nogate



if {![using_hla]} {

	# if srst is not fitted use SYSRESETREQ to

	# perform a soft reset

	cortex_m reset_config sysresetreq

}



$_TARGETNAME configure -event examine-end {

	# Enable DBGMCU clock

	# RCC_DBGCFGR |= DBGEN

	mmw 0x40021050 0x00000001 0



	# Enable debug during low power modes (uses more power)

	# DBGMCU_CR |= DBG_STANDBY | DBG_STOP

	mmw 0x40015804 0x0000000C 0



	# Stop watchdog counters during halt

	# DBGMCU_APB1_FZR |= DBG_IWDG_STOP | DBG_WWDG_STOP

	mmw 0x40015808 0x00001800 0

}

へルパーcfgのstm32u0_swd_flash.cfgはこんな感じです。

# script for stm32u0x with flash programming

# Nemuisan's Special





source [find target/stm32u0x.cfg]

$_TARGETNAME configure -work-area-phys 0x20000000 -work-area-size $_WORKAREASIZE -work-area-backup 0 



proc mt_flash {IMGFILE} {

	flash write_image erase $IMGFILE

	verify_image $IMGFILE

	reset run

	shutdown

}



proc mt_flash_bin {IMGFILE OFFSET}  {

	flash write_image erase $IMGFILE $OFFSET bin

	verify_image $IMGFILE $OFFSET

	reset run

	shutdown

}



proc mt_flash_hex {IMGFILE}  {

	flash write_image erase $IMGFILE 0 ihex

	verify_image $IMGFILE 0

	reset run

	shutdown

}



proc eraser {}  {

	stm32g0x mass_erase 0

	flash erase_check 0

	shutdown

}



#debug_level 3

#reset_config srst_only srst_nogate connect_assert_srst

reset_config none

adapter speed 500

gdb_target_description enable

init

reset init

それらを使って書き込んでみたところのログはこんな感じです。

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

openocd  -s C:/Devz/ARM/OCD/tcl -f interface/stlink-dap.cfg -c "transport select dapdirect_swd" -f target/stm32u0x_swd_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.12.0+dev-00658-g6554d176e (2024-07-21-10:18)

Licensed under GNU GPL v2

For bug reports, read

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

dapdirect_swd

DEPRECATED! use 'gdb target_description', not 'gdb_target_description'

Info : STLINK V2J45M30 (API v2) VID:PID 0483:3752

Info : Target voltage: 3.236554

Info : Unable to match requested speed 500 kHz, using 480 kHz

Info : Unable to match requested speed 500 kHz, using 480 kHz

Info : clock speed 480 kHz

Info : stlink_dap_op_connect(connect)

Info : SWD DPIDR 0x6ba02477

Info : [stm32u0x.cpu] Cortex-M0+ r0p1 processor detected

Info : [stm32u0x.cpu] target has 4 breakpoints, 2 watchpoints

Info : [stm32u0x.cpu] Examination succeed

Info : [stm32u0x.cpu] starting gdb server on 3333

Info : Listening on port 3333 for gdb connections

[stm32u0x.cpu] halted due to breakpoint, current mode: Thread 

xPSR: 0xf1000000 pc: 0x08002b30 msp: 0x2000a000

Info : device idcode = 0x10006489 (STM32U07/U08xx - Rev A : 0x1000)

Info : RDP level 0 (0xAA)

Info : flash size = 256 KiB

Info : flash mode : single-bank

Info : Padding image section 1 at 0x08008004 with 4 bytes (bank write end alignment)

Warn : Adding extra erase range, 0x08008008 .. 0x080087ff

Info : wrote 32776 bytes from file main.elf in 1.595168s (20.065 KiB/s)

Info : verified 32772 bytes in 0.780823s (40.987 KiB/s)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:03

もちろんデバッグも自由自在です。U0シリーズの要であるスリープ時
等からの接続デバッグにも対応したつもりですが人柱お願いします…

●実際に動くものを作ってみよう
使い勝手としましてはSTM32G0,STM32C0とほぼ同じなので移植もあっさり
できちゃいました。

NUCLEO基板で定番となったI2Cを使用したセンサとOLEDの表示ルーチンを
サクッとこしらえてみました。なお、STM32U0は最大動作周波数56MHzで
動作しますが48MHz動作のほうが潰しがきくのでお勧めです。
私の作例では48MHz動作としております。

●ちょっとした注意
STM32U0は徹底した低電力性を唱えておりますので初期状態でほとんどの
モジュールにクロックが供給されておりません。

ねむいさんもうっかり嵌ってしまいましたがU0ではDBGMCUのクロックが
初期状態で供給されておりませんのでMCUのリビジョンをやIDを取りたい
場合は下記の要領でクロックを有効にしてやりましょう。

#if defined(USE_STM32U083RC_NUCLEO)

	/* STM32U0 DeviceID & Revision Detection */

	char mcurev;

	__HAL_RCC_DBGMCU_CLK_ENABLE(); // <- これ

	uint16_t revid = HAL_GetREVID();

	uint16_t devid = 0x0FFF & HAL_GetDEVID();

    if     (revid == 0x1001) mcurev = 'Z';

	else		/* 0x1000 */ mcurev = 'A';

	printf("STM32U0xx DevID 0x%04x Rev.%c¥n",devid,mcurev);

	printf("STM32U0xx UID 0x%08lx%08lx%08lx¥n",HAL_GetUIDw2(),HAL_GetUIDw1(),HAL_GetUIDw0());

	printf("¥n");

#endif

OpenOCDでは上でも述べましたがcfgファイル内で接続した瞬間にDBGMCUの
クロックを有効にするように仕込んでますので安心です(人柱求む)。

というわけでSTM32U0という新しいラインナップが加わったわけですが、
U0はL0シリーズの後継という位置づけのようなので市場もL0からU0へと
次第に置き換わっていくこととなるでしょう。
STM32も世代を重ねて着実に進化していくので楽しみです。

AVR小ネタたち

今回はAVRマイコンにまつわることをいろいろ試していきます。

●avr-gccが14になっていた
月日の流れは速いものでGCC14が少し前にリリースされていましたが
avr-gccにも適用されております。

Windows向けのものはzakkemble氏の私家ビルド版が利用可能なもの
となっております。正確なバージョンはGCC14.1.0とのこと。

zakkemble氏のビルドはAVR-LibCも2.2.0にアップしており最新の
AVRにも対応しております。もうmicrochipのサイトからDFP拾ってきて
あれやこれややらなくてよくなったのでめっちゃ楽です！

今回のGCC14の目玉はAVR64DD28とかのAVR-Dx,AVR-Ex系でフラッシュ
メモリ領域が64kBを超える品種においてPROGMEMなしで32kByteまで
constデータを配置できるようになったことです。

以前ねむいさんはリンカスクリプトを弄って32kByte分のrodataを
データ領域にマッピングする技をやっていましたがGCC14はデフォルトで
そうするように変更されております。

これでAVR64DD28やAVR128DB28とかでも32kByteまでならPROGMEM
無しでもconstデータを置きまくれることになります…！やった！

しかし…

ねむいさんが過去に公開しているAVR-Dx向けのプロジェクトは無理くそ
リンカスクリプトをいじってマッピングしている奴とぶつかってしまい
GCC14でまともにビルドできなくなってしまいました。
そこで今回後方互換性を保ちつつGCC14でもビルドできるようにmakefile
に仕込みを行いました。

#============================================================================

# Define programs and commands.

SHELL 		= sh

CC 			= avr-gcc

OBJCOPY 	= avr-objcopy

OBJDUMP 	= avr-objdump

SIZE 		= avr-size

NM 			= avr-nm

AVRDUDE 	= avrdude

REMOVE 		= rm -f

REMOVEDIR 	= rm -rf

COPY 		= cp

WINSHELL 	= cmd

# Detect GCC version

GCCVERSION:= $(shell $(CC) -dumpversion)

dot:=.

empty:=

space:= $(empty) $(empty)

GCCVERSION:= $(subst $(dot),$(space), $(GCCVERSION))

GCCMAJOR:= $(word 1, $(GCCVERSION))

GCCMINOR:= $(word 2, $(GCCVERSION))

こういやってGCCのメジャーバージョンをmakefile内で取得して…

# If GCC 14+ Add -mrodata-in-ram to get backward compatibility on AVR uC

ifeq (1,$(shell expr $(GCCMAJOR) ¥>= 14))

 ifneq ($(MCU),avr32da28)

  ifeq ($(USE_SECTOR_MIRROR),SECTOR_MIRRORED)

   CFLAGS += -mrodata-in-ram

  endif

 endif

endif

GCC14でビルドする場合はCFLAGSにrodataのマッピングを無効化する
"-mrodata-in-ram"を付与してGCC13以前と同じようにビルドするように
しております…
せっかく便利な機能ができたのにわざわざ以前の状態に戻すような愚行
をしちゃってますがまぁ時代の変遷の仇花ということで…

ちなみにmakefile中のGCCバージョン取得はこちらの方の記事を参考に
させていただきました！

まぁ新規にプロジェクト作る際は"-mrodata-in-ram"の仕込みは不要な
ようにしたいと思います。
そんなわけでAVR-Dx向けのプロジェクトもGCC14に対応してみましたので
興味ある方は覗いてみてください。

またGCC14では"-fanalyzer"なるオプションも追加されています。
これを有効にすると以下のように問題のある部分を解説してくれます。

Compiling: src/xprintf_avr.c

avr-gcc -c -mmcu=avr128da48 -std=gnu99 -g -gdwarf-2 -Os  -mrelax -mcall-prologues -fno-strict-aliasing -funsigned-char -funsigned-bitfields -ffunction-sections -fdata-sections -fno-common -fanalyzer -fno-split-wide-types -fno-tree-scev-cprop -fpack-struct -fshort-enums -Wall -Wstrict-prototypes --param=min-pagesize=0 -Wa,-adhlns=src/xprintf_avr.lst -DCURIOSITY_NANO -DMPU_SUBMODEL=¥"avr128da48¥" -DAPP_VERSION=¥"W.I.P.¥" -DF_CPU=24000000UL -DSECTOR_SEL=UL -I. -I ./inc -I ./lib/ff -MD src/xprintf_avr.c -o src/xprintf_avr.o

src/xprintf_avr.c: In function 'xvprintf':

src/xprintf_avr.c:131:27: warning: 'va_arg' expected 'char *' but received 'long unsigned int' for variadic argument 1 of 'arp' [CWE-686] [-Wanalyzer-va-arg-type-mismatch]

  131 |                         p = va_arg(arp, char*);

      |                           ^

  'put_dump': events 1-2

    |

    |  247 | void put_dump (

    |      |      ^~~~~~~~

    |      |      |

    |      |      (1) entry to 'put_dump'

    |......

    |  260 |         xprintf(PFSTR("%08lX "), addr);         /* address */

    |      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    |      |         |

    |      |         (2) calling 'xprintf' from 'put_dump' with 1 variadic argument

    |

    +--> 'xprintf': events 3-4

           |

           |  187 | void xprintf (                  /* Put a formatted string to the default device */

           |      |      ^~~~~~~

           |      |      |

           |      |      (3) entry to 'xprintf'

           |......

           |  196 |         xvprintf(fmt, arp);

           |      |         ~~~~~~~~~~~~~~~~~~

           |      |         |

           |      |         (4) calling 'xvprintf' from 'xprintf'

           |

           +--> 'xvprintf': events 5-8

                  |

                  |   96 | void xvprintf (

                  |      |      ^~~~~~~~

                  |      |      |

                  |      |      (5) entry to 'xvprintf'

                  |......

                  |  108 |                 if (!c) break;                                  /* End of format? */

                  |      |                    ~

                  |      |                    |

                  |      |                    (6) following 'false' branch (when '__result != 0')...

                  |  109 |                 if (c != '%') {                                 /* Pass through it if not a % sequense */

                  |      |                    ~

                  |      |                    |

                  |      |                    (7) ...to here

                  |      |                    (8) following 'false' branch (when '__result == 37')...

                  |

                'xvprintf': event 9

                  |

                  |  113 |                 c = PGM_READ_BYTE(fmt++);       /* Get first char of the sequense */

src/xprintf_avr.c:113:21: note: in expansion of macro 'PGM_READ_BYTE'

                  |  113 |                 c = PGM_READ_BYTE(fmt++);       /* Get first char of the sequense */

                  |      |                     ^~~~~~~~~~~~~

                  |

                'xvprintf': event 10

                  |

                  |  114 |                 if (c == '0') {                                 /* Flag: '0' padded */

                  |      |                    ^

                  |      |                    |

                  |      |                    (10) following 'true' branch (when '__result == 48')...

                  |

                'xvprintf': event 11

                  |

                  |  115 |                         f = 1; c = PGM_READ_BYTE(fmt++);

src/xprintf_avr.c:115:36: note: in expansion of macro 'PGM_READ_BYTE'

                  |  115 |                         f = 1; c = PGM_READ_BYTE(fmt++);

                  |      |                                    ^~~~~~~~~~~~~

                  |

                'xvprintf': events 12-15

                  |

                  |  121 |                 for (w = 0; c >= '0' && c <= '9'; c = PGM_READ_BYTE(fmt++))     /* Minimum width */

                  |      |                             ~~~~~~~~~^~~~~~~~~~~

                  |      |                                      |

                  |      |                                      (12) following 'false' branch...

                  |  122 |                         w = w * 10 + c - '0';

                  |  123 |                 if (c == 'l' || c == 'L') {             /* Prefix: Size is long int */

                  |      |                    ~                  

                  |      |                    |

                  |      |                    (13) ...to here

                  |......

                  |  126 |                 if (!c) break;                          /* End of format? */

                  |      |                    ~                  

                  |      |                    |

                  |      |                    (14) following 'false' branch (when 'c != 0')...

                  |......

                  |  129 |                 switch (d) {                            /* Type is... */

                  |      |                 ~~~~~~                

                  |      |                 |

                  |      |                 (15) ...to here

                  |

                'xvprintf': event 16

                  |

                  |  131 |                         p = va_arg(arp, char*);

                  |      |                           ^

                  |      |                           |

                  |      |                           (16) 'va_arg' expected 'char *' but received 'long unsigned int' for variadic argument 1 of 'arp'

                  |

とこんな感じに問題の個所を詳細に解説してくれます。

●AVR-EAシリーズを使ってみる

STM32U0マイコン買ったついでに買ったのですがAVR64EA28も買ってみました。
AVR-Dxシリーズとの最大の違いは内部レギュレータが無いので電圧により動作
可能なクロック上限(MAX20MHz)があることです。
どちらかというとAVRTiny-0/1/2シリーズに近いかもしれませんね。

そんなわけでAVR64EA28を使用したプロジェクトもサクっと作ってみましたので
紹介します。1秒ごとにLEDを点滅させつつ内部温度計の現在温度をUARTで送出
するいたってシンプルな構成です。まぁ基本の基本ですね。

ところでAVR-EAとAVR-DDはヒューズ設定でUPDIやRESETピンをGPIOとして使用
できますがGPIO化した状態でUPDIを活性化させるためにはRESETに高電圧(HV)を
印加する必要があります。なおRESETピンの絶対最大定格は9Vのため、ATTINY202
の時みたいに気軽に12Vを印可してしまうと気軽に死にます･･･(AVR-DDも同じ)。

じゃぁ何V加えたらいいのかという話ですがデータシートのどこを見ても私の
脳みそでは適切な電圧はわからず(もちろん9Vもあかんと思います)、UPDIと
RESETピンは無理にGPIOとして使用するのはやめようと思いまし、た！

AVR-EA/EBシリーズに詳しいaskn氏はHVを9Vよりちょっと低い8.2Vと
されているようですね。

20240624追:
AVR64DD28のデータシートが2024年2月付で更新されているのに今更
気づいたのですがRESET高電圧の定義がようやく明確に記されておりました…。

Typ値7.5Vですって…！！
何故こんな重要な情報を何年も公表せず放置していやがったのでしょうか(ﾋﾟｷﾋﾟｷ
AVR-Exシリーズも多分同じ感じでしょうからRESET高電圧は7.5Vくらいを
印加すればうまくいくと思いますがやっぱりUPDIとRESETピンは無理に
GPIOとして使用するのはやめようと思いまし、た！

20240624追:
AVR-EBシリーズもRESET高電圧のTyp値が7.5Vでした…(2023年秋更新)
AVR-EAのデータシートもさっさと更新してほしいんですけぉ！！

●avrdude v7.3リリース！！
☝で書いたAVR-EAシリーズのプログラムができます！！！(HV除く)
最新のパッチを当てたWindows用バイナリを公開しておりますので
どしどしご利用ください！！！！！

●avr-gccのdelay関数の変遷
avr-gccではmSec,uSec単位を待つのに便利な_delay_ms(),_delay_us()
という非常に便利な関数があります。おそらくもっともポピュラーな
関数ですがこの関数もいろんな変遷をたどっています。

①2005年くらい
_delay_ms()は262.14mSec/F_CPU(MHz)まで設定可能。
引数はdoubleなので実数も可能。
F_CPU=8000000(8MHz)の場合、32.7675mSecまでは保証される。

_delay_us()は768uSec/F_CPU(MHz)まで設定可能。
引数はdoubleなので実数も可能。

②2007年くらい
_delay_ms()は262.14mSec/F_CPU(MHz)まで設定可能
それを超えると1/10mSecに精度が落ちるがF_CPUの設定にかかわらず
6.5535Secまで設定可能。

_delay_us()は768uSec/F_CPU(MHz)まで設定可能。
それを超えると_delay_ms()が呼び出される。

③2010年前半くらい
__builtin_avr_delay_cycles()が追加された。
__HAS_DELAY_CYCLEを1にして最適化オプションを-O1以上にすると
__builtin_avr_delay_cycles()が呼び出される。
この場合_delay_ms()は4294967.295mSec/F_CPU(MHz)まで設定が可能になる。
F_CPU=8000000(8MHz)の場合、536870.911875mSecまでは保証される。
それ以上の値を設定した場合0mSecになる。
_delay_us()も4294967.295uSec/F_CPU(MHz)まで設定が可能になる。
それ以上の値を設定した場合0uSecになる。

また、__HAS_DELAY_CYCLEを0にするもしくは最適化オプションを-O0に
した場合は②と同じになる。

13年位前にXMEGA触ったときにこれに引っかかってしまってましたね。
※今では不要な対処法ですが

④2010年後半くらい
コンパイル時に__DELAY_ROUND_DOWN__,__DELAY_ROUND_CLOSEST__の
スイッチ追加。また③の機能は__DELAY_BACKWARD_COMPATIBLE__を
コンパイラに渡すと②と同じになるように変更。

⑤2011年くらい
④に加えて"-fno-hosted"と"-ffreestanding"がコンパイルオプションに
あった場合②と同じになるように変更。

⑥2013年くらい
②の_delay_us()の_delay_ms()を呼び出す仕組みにエンバグされてしまう！

⑦2020年くらい
⑥のバグようやく修正される(が、GCC13まで取り込まれていなかった)

なんと今回のAVR-GCC14くらいまで10年くらいバグが放置されていたの
ですが特殊な使い方をしない限りは誰も踏まなかったと思いますので
たぶん大丈夫だと思いました！
ねむいさんはおもいくそ踏んでしまいました！！１！！！

ちなみに具体的なコードの変遷はこちらで見ることができます。

というわけでごちゃごちゃと書きましたが2024年現在GCC14を使用する
__builtin_avr_delay_cycles()呼び出す方式でdelayしたい場合は…

・"-fno-hosted"と"-ffreestanding"をコンパイルオプションに加えない
・最適化オプションは-O1以上にする

でおっけーです。簡単に見える関数もしっかり中身理解してないと
思わぬところでハマってしまうというお話でした。

今回の修正を加えたねむいさんのAVR系のプロジェクトを更新しましたので
興味がある方はご参考に…
*ATTINY202
*AVR-Dx
*AVR-EA
*ATXMEGA128A1/A1U

秋月発売記念！AVR64DD28を使ってみる！

あけましておめでとうございます。

今年は最初から災難続きでございますが、できることを精一杯頑張って
まいりましょう！！

今回は昨年末に秋月電子通商から販売されたAVR-DDシリーズの
最大容量品であるAVR64DD28の紹介をしていこうと思います。

AVR-DDシリーズはAVR-DBシリーズの小規模化したデバイスとなります。
DxCoreの品種比較表がわかりやすいです。またDBシリーズで存在した
エラッタがいくつか修正されているのも特徴です。

基本的な機能はAVR-DBを引き継いでいますのでAVR64DD28は現時点で
非常に使い勝手がよいAVRとなり、将来的にはATMega328Pを置き換えて
いくことでしょう。

●AVR64DD28のプログラムメモリ構成とrodataの取り扱いについて
AVR-Dxシリーズはデータ領域にプログラム領域の一部がマッピング
されており、LPM命令を使用しないでも通常のLD命令が使用可能な
領域が存在しております。

AVR64DD28においては64kByteあるプログラムメモリの後半32kByte分が
データ領域にデフォルトでマッピングされております。残念ながら
64KByte品では全領域とはならず半分の32kByte分となります。
32kByte以下の容量品では全領域がマッピングされております。

ちなみにNVMモジュールのCTRLBレジスタはデフォルトで後半32kByte分
のマッピング設定になっているため通常使いの場合は特に設定は
不要で後半32kByte分はデータ領域としてアクセスできるわけです。

が！

AVR128DA48とかAVR128DB28を使ったときにも同じ解説をしておりますが、
AVR64DD28というかAVR-Dxシリーズの64kByte以上のフラッシュ容量の
品種では何も考えないでビルドするとavr-gcc内にビルドインされた
デフォルトのリンカスクリプト(AVR64DD28ではavrxmega2.xn)を選択して
しまうため、上記のようなデータ領域のマッピングを意識しないメモリの
取り扱いをしてしまいます。
これでは旧AVR製品のように面倒なPROGMEMが必要となってしまいます。

ねむいさんは64KByte中後半32kByteをrodataとするような特別なリンカ
スクリプトを作成してPROGMEM使わなくてもSTM32みたいに普通にconstを
取り扱えるようにしてみました。
まぁAVRとしてはプログラム領域32kByteとrodata領域32kByteは十分すぎる
広さとなるでしょう～
プロジェクト中にもありますが一応私が作ったリンカスクリプト貼っておきます。

/* Script for -n */

/* Copyright (C) 2014-2023 Free Software Foundation, Inc.

   Copying and distribution of this script, with or without modification,

   are permitted in any medium without royalty provided the copyright

   notice and this notice are preserved.  */

OUTPUT_FORMAT("elf32-avr","elf32-avr","elf32-avr")

OUTPUT_ARCH(avr:102)

__TEXT_REGION_ORIGIN__ = DEFINED(__TEXT_REGION_ORIGIN__) ? __TEXT_REGION_ORIGIN__ : 0;

__DATA_REGION_ORIGIN__ = DEFINED(__DATA_REGION_ORIGIN__) ? __DATA_REGION_ORIGIN__ : 0x802000;

__TEXT_REGION_LENGTH__ = DEFINED(__TEXT_REGION_LENGTH__) ? __TEXT_REGION_LENGTH__ : 1024K;

__DATA_REGION_LENGTH__ = DEFINED(__DATA_REGION_LENGTH__) ? __DATA_REGION_LENGTH__ : 0xffa0;

__EEPROM_REGION_LENGTH__ = DEFINED(__EEPROM_REGION_LENGTH__) ? __EEPROM_REGION_LENGTH__ : 64K;

__FUSE_REGION_LENGTH__ = DEFINED(__FUSE_REGION_LENGTH__) ? __FUSE_REGION_LENGTH__ : 1K;

__LOCK_REGION_LENGTH__ = DEFINED(__LOCK_REGION_LENGTH__) ? __LOCK_REGION_LENGTH__ : 1K;

__SIGNATURE_REGION_LENGTH__ = DEFINED(__SIGNATURE_REGION_LENGTH__) ? __SIGNATURE_REGION_LENGTH__ : 1K;

__USER_SIGNATURE_REGION_LENGTH__ = DEFINED(__USER_SIGNATURE_REGION_LENGTH__) ? __USER_SIGNATURE_REGION_LENGTH__ : 1K;

__RODATA_PM_OFFSET__ = DEFINED(__RODATA_PM_OFFSET__) ? __RODATA_PM_OFFSET__ : 0x8000;

MEMORY

{

  text   (rx)   : ORIGIN = __TEXT_REGION_ORIGIN__, LENGTH = __TEXT_REGION_LENGTH__-32K

  rodata (rx)   : ORIGIN = __TEXT_REGION_LENGTH__-32K, LENGTH = 32K

  data   (rw!x) : ORIGIN = __DATA_REGION_ORIGIN__, LENGTH = __DATA_REGION_LENGTH__

  eeprom (rw!x) : ORIGIN = 0x810000, LENGTH = __EEPROM_REGION_LENGTH__

  fuse      (rw!x) : ORIGIN = 0x820000, LENGTH = __FUSE_REGION_LENGTH__

  lock      (rw!x) : ORIGIN = 0x830000, LENGTH = __LOCK_REGION_LENGTH__

  signature (rw!x) : ORIGIN = 0x840000, LENGTH = __SIGNATURE_REGION_LENGTH__

  user_signatures (rw!x) : ORIGIN = 0x850000, LENGTH = __USER_SIGNATURE_REGION_LENGTH__

}

SECTIONS

{

  /* Read-only sections, merged into text segment: */

  .hash          : { *(.hash)		}

  .dynsym        : { *(.dynsym)		}

  .dynstr        : { *(.dynstr)		}

  .gnu.version   : { *(.gnu.version)	}

  .gnu.version_d   : { *(.gnu.version_d)	}

  .gnu.version_r   : { *(.gnu.version_r)	}

  .rel.init      : { *(.rel.init)		}

  .rela.init     : { *(.rela.init)	}

  .rel.text      :

    {

      *(.rel.text)

      *(.rel.text.*)

      *(.rel.gnu.linkonce.t*)

    }

  .rela.text     :

    {

      *(.rela.text)

      *(.rela.text.*)

      *(.rela.gnu.linkonce.t*)

    }

  .rel.fini      : { *(.rel.fini)		}

  .rela.fini     : { *(.rela.fini)	}

  .rel.rodata    :

    {

      *(.rel.rodata)

      *(.rel.rodata.*)

      *(.rel.gnu.linkonce.r*)

    }

  .rela.rodata   :

    {

      *(.rela.rodata)

      *(.rela.rodata.*)

      *(.rela.gnu.linkonce.r*)

    }

  .rel.data      :

    {

      *(.rel.data)

      *(.rel.data.*)

      *(.rel.gnu.linkonce.d*)

    }

  .rela.data     :

    {

      *(.rela.data)

      *(.rela.data.*)

      *(.rela.gnu.linkonce.d*)

    }

  .rel.ctors     : { *(.rel.ctors)	}

  .rela.ctors    : { *(.rela.ctors)	}

  .rel.dtors     : { *(.rel.dtors)	}

  .rela.dtors    : { *(.rela.dtors)	}

  .rel.got       : { *(.rel.got)		}

  .rela.got      : { *(.rela.got)		}

  .rel.bss       : { *(.rel.bss)		}

  .rela.bss      : { *(.rela.bss)		}

  .rel.plt       : { *(.rel.plt)		}

  .rela.plt      : { *(.rela.plt)		}

  /* Internal text space or external memory.  */

  .text   :

  {

    *(.vectors)

    KEEP(*(.vectors))

    /* For data that needs to reside in the lower 64k of progmem.  */

    *(.progmem.gcc*)

    /* PR 13812: Placing the trampolines here gives a better chance

       that they will be in range of the code that uses them.  */

    . = ALIGN(2);

    __trampolines_start = . ;

    /* The jump trampolines for the 16-bit limited relocs will reside here.  */

    *(.trampolines)

    *(.trampolines*)

    __trampolines_end = . ;

    /* avr-libc expects these data to reside in lower 64K. */

    *libprintf_flt.a:*(.progmem.data)

    *libc.a:*(.progmem.data)

    *(.progmem.*)

    . = ALIGN(2);

    /* For code that needs to reside in the lower 128k progmem.  */

    *(.lowtext)

    *(.lowtext*)

     __ctors_start = . ;

     *(.ctors)

     __ctors_end = . ;

     __dtors_start = . ;

     *(.dtors)

     __dtors_end = . ;

    KEEP(SORT(*)(.ctors))

    KEEP(SORT(*)(.dtors))

    /* From this point on, we do not bother about whether the insns are

       below or above the 16 bits boundary.  */

    *(.init0)  /* Start here after reset.  */

    KEEP (*(.init0))

    *(.init1)

    KEEP (*(.init1))

    *(.init2)  /* Clear __zero_reg__, set up stack pointer.  */

    KEEP (*(.init2))

    *(.init3)

    KEEP (*(.init3))

    *(.init4)  /* Initialize data and BSS.  */

    KEEP (*(.init4))

    *(.init5)

    KEEP (*(.init5))

    *(.init6)  /* C++ constructors.  */

    KEEP (*(.init6))

    *(.init7)

    KEEP (*(.init7))

    *(.init8)

    KEEP (*(.init8))

    *(.init9)  /* Call main().  */

    KEEP (*(.init9))

    *(.text)

    . = ALIGN(2);

    *(.text.*)

    . = ALIGN(2);

    *(.fini9)  /* _exit() starts here.  */

    KEEP (*(.fini9))

    *(.fini8)

    KEEP (*(.fini8))

    *(.fini7)

    KEEP (*(.fini7))

    *(.fini6)  /* C++ destructors.  */

    KEEP (*(.fini6))

    *(.fini5)

    KEEP (*(.fini5))

    *(.fini4)

    KEEP (*(.fini4))

    *(.fini3)

    KEEP (*(.fini3))

    *(.fini2)

    KEEP (*(.fini2))

    *(.fini1)

    KEEP (*(.fini1))

    *(.fini0)  /* Infinite loop after program termination.  */

    KEEP (*(.fini0))

    /* For code that needs not to reside in the lower progmem.  */

    *(.hightext)

    *(.hightext*)

    *(.progmemx.*)

    . = ALIGN(2);

    /* For tablejump instruction arrays.  We do not relax

       JMP / CALL instructions within these sections.  */

    *(.jumptables)

    *(.jumptables*)

    _etext = . ;

  }  > text

  .data          :

  {

     PROVIDE (__data_start = .) ;

    *(.data)

     *(.data*)

    *(.gnu.linkonce.d*)

    . = ALIGN(2);

     _edata = . ;

     PROVIDE (__data_end = .) ;

  }  > data AT> text

  .bss  ADDR(.data) + SIZEOF (.data)   : AT (ADDR (.bss))

  {

     PROVIDE (__bss_start = .) ;

    *(.bss)

     *(.bss*)

     *(COMMON)

     PROVIDE (__bss_end = .) ;

  }  > data

   __data_load_start = LOADADDR(.data);

   __data_load_end = __data_load_start + SIZEOF(.data);

  /* Global data not cleared after reset.  */

  .noinit  ADDR(.bss) + SIZEOF (.bss)  :  AT (ADDR (.noinit))

  {

     PROVIDE (__noinit_start = .) ;

    *(.noinit .noinit.* .gnu.linkonce.n.*)

     PROVIDE (__noinit_end = .) ;

     _end = . ;

     PROVIDE (__heap_start = .) ;

  }  > data

  .rodata   :

  {

    *(.rodata)

     *(.rodata*)

    *(.gnu.linkonce.r*)

  }  > rodata

  .eeprom  :

  {

    /* See .data above...  */

    KEEP(*(.eeprom*))

     __eeprom_end = . ;

  }  > eeprom

  .fuse  :

  {

    KEEP(*(.fuse))

    KEEP(*(.lfuse))

    KEEP(*(.hfuse))

    KEEP(*(.efuse))

  }  > fuse

  .lock  :

  {

    KEEP(*(.lock*))

  }  > lock

  .signature  :

  {

    KEEP(*(.signature*))

  }  > signature

  .user_signatures  :

  {

    KEEP(*(.user_signatures*))

  }  > user_signatures

  /* Stabs debugging sections.  */

  .stab          0 : { *(.stab) }

  .stabstr       0 : { *(.stabstr) }

  .stab.excl     0 : { *(.stab.excl) }

  .stab.exclstr  0 : { *(.stab.exclstr) }

  .stab.index    0 : { *(.stab.index) }

  .stab.indexstr 0 : { *(.stab.indexstr) }

  .comment 0 : { *(.comment) }

  .gnu.build.attributes : { *(.gnu.build.attributes .gnu.build.attributes.*) }

  .note.gnu.build-id   : { *(.note.gnu.build-id) }

  /* DWARF debug sections.

     Symbols in the DWARF debugging sections are relative to the beginning

     of the section so we begin them at 0.  */

  /* DWARF 1.  */

  .debug          0 : { *(.debug) }

  .line           0 : { *(.line) }

  /* GNU DWARF 1 extensions.  */

  .debug_srcinfo  0 : { *(.debug_srcinfo) }

  .debug_sfnames  0 : { *(.debug_sfnames) }

  /* DWARF 1.1 and DWARF 2.  */

  .debug_aranges  0 : { *(.debug_aranges) }

  .debug_pubnames 0 : { *(.debug_pubnames) }

  /* DWARF 2.  */

  .debug_info     0 : { *(.debug_info .gnu.linkonce.wi.*) }

  .debug_abbrev   0 : { *(.debug_abbrev) }

  .debug_line     0 : { *(.debug_line .debug_line.* .debug_line_end) }

  .debug_frame    0 : { *(.debug_frame) }

  .debug_str      0 : { *(.debug_str) }

  .debug_loc      0 : { *(.debug_loc) }

  .debug_macinfo  0 : { *(.debug_macinfo) }

  /* SGI/MIPS DWARF 2 extensions.  */

  .debug_weaknames 0 : { *(.debug_weaknames) }

  .debug_funcnames 0 : { *(.debug_funcnames) }

  .debug_typenames 0 : { *(.debug_typenames) }

  .debug_varnames  0 : { *(.debug_varnames) }

  /* DWARF 3.  */

  .debug_pubtypes 0 : { *(.debug_pubtypes) }

  .debug_ranges   0 : { *(.debug_ranges) }

  /* DWARF 5.  */

  .debug_addr     0 : { *(.debug_addr) }

  .debug_line_str 0 : { *(.debug_line_str) }

  .debug_loclists 0 : { *(.debug_loclists) }

  .debug_macro    0 : { *(.debug_macro) }

  .debug_names    0 : { *(.debug_names) }

  .debug_rnglists 0 : { *(.debug_rnglists) }

  .debug_str_offsets 0 : { *(.debug_str_offsets) }

  .debug_sup      0 : { *(.debug_sup) }

}

これをLDFLAGSに食わせてやればこちらが優先されて上記のようにメモリが
配置される仕組みになっています。詳細は私のプロジェクト内makefileの
274行目あたりを参照してください。

ねむいさん式リンカスクリプト
dataセクションの使用領域が減りました。さらにrodata領域に
読み取り専用のデータが割り当てられています。

Memory region         Used Size  Region Size  %age Used

            text:        2796 B        32 KB      8.53%

          rodata:         144 B        32 KB      0.44%

            data:         144 B         8 KB      1.76%

          eeprom:          0 GB        256 B      0.00%

            fuse:          0 GB         16 B      0.00%

            lock:          0 GB         1 KB      0.00%

       signature:          0 GB         1 KB      0.00%

 user_signatures:          0 GB         1 KB      0.00%

一方デフォルトリンカスクリプトのメモリ使用領域は…
dataセクションに取られてしまい無駄にメモリ領域を圧迫してます。

Memory region         Used Size  Region Size  %age Used

            text:        2940 B        64 KB      4.49%

            data:         288 B         8 KB      3.52%

          eeprom:          0 GB        256 B      0.00%

            fuse:          0 GB         16 B      0.00%

            lock:          0 GB         1 KB      0.00%

       signature:          0 GB         1 KB      0.00%

 user_signatures:          0 GB         1 KB      0.00%

20240123追:
GCC14ではコンパイル時のスイッチでリマップに対応するようです！！！
こうご期待！！！
20240123追:

●AVR64DD28向けのバイナリをAVR-GCCでビルドする方法
数年前からお伝えしている通り、avr-gccでAVR64DD28とかの最新の品種を
ビルドするためには自分でオブジェクトとかデバイス定義ファイルを
追加してやる必要があります。今回はavr-gccの導入から改めて解説して
いこうと思います。64bit版Windows10環境下を想定しております。

1.Windows向けavr-gccを取得する
Zak's Electronics Blogの"AVR-GCC 13.2.0 for Windows"をダウンロード
します。GCCが最新の13.2.0となっておりますが特筆すべきはビルドイン
されたリンカスクリプトに"__DATA_REGION_ORIGIN__"が追加されるように
なったのですがこれめっちゃ重要な修正なので必ず13.2.0のバイナリを
使用するようにしてください！！

ねむいさんの環境ではARM開発環境に倣って下記ディレクトリに展開します。

C:¥Devz¥AVR¥avr-gcc

avr-gccディレクトリ内はこうなります。
またmakeの呼び出し方はARMとまったく共通なのでARMマイコンのビルド
環境構築法のCoreutilsの設定を参考にしてください。

2.MicrochipのサイトからDeviceFamilyPacks(DFP)を取得する
こっからがだいぶ面倒です。"Microchip Packs Repository"から
"Microchip AVR-Dx Series Device Support"をダウンロードします。
拡張子がatpackとなっていますが実態はzip圧縮ファイルです。
以下7zの使用を想定して進めていきます。

3.DFPからヘッダファイルとかデバイス定義ファイル抽出して追加
a.ヘッダファイルの追加
圧縮ファイル内の"¥include"に進みます。

"C:¥Devz¥AVR¥avr-gcc¥avr¥include"内にavrフォルダをコピーします。

b.device-specsの追加
圧縮ファイル内の"¥gcc¥dev¥avr64dd28"と進みます。

"C:¥Devz¥AVR¥avr-gcc¥lib¥gcc¥avr¥13.2.0"内にdevice-specsフォルダを
コピーします。

c.スタートアップファイルの追加

"C:¥Devz¥AVR¥avr-gcc¥avr¥lib"内にavrxmega2フォルダをコピーします。

あああめんどくさい…
とにかくこれで前準備が終わりました…

ほかの品種でもこの操作を行うことによって最新のAVRがビルドできます。

それでは改めてねむいさんのプロジェクトの上記の部分をavr64dd28にして
ビルドします。

ちゃんと設定ができていたらビルドが始まり…

すぐ終わった…

書き込みはavrdudeを使用します。
書き込み方法はこちらのserialUPDIの記事を参考に…

プログラムはAVR128DA/DBと共通でデバイスの固有シリアル番号を表示
した後1秒ごとにチップ温度をUARTで送出するものです。
ADCとUART(ノンブロッキング)を使用しております。
チップ単体でできる基本的なことを網羅しております。

今回もぐだぐだとした内容になってしまいましたが、ねむいさんの
ぶろぐを見てる人はねむいさんより技術力が高い方ばっかりなので
多分理解してくれて大丈夫だと思います…

そんなわけでこんな感じで精いっぱいがむばっていこうと思います…!

STM32H5を使ってみる2 -フラッシュ書き込み＆デバッグ環境作るだけで疲労困憊-

20240516追:
秋月さんよりNUCLEO-H563ZI販売開始です！！
20240516追:

秋の登山ラッシュに入ってしまったのでせっかく買ったのに全く
STM32H5触れてない毎日ですがわずかな時間を見つけてすこしでも
進ませていただきます！！！

さて今回からSTM32L5で行ったように基本となる機能と開発環境の
確認を紹介していきます。

●OpenOCDがSTM32H5に対応してない！？大丈夫だ問題ない
はい、ﾋ改めﾒのタイムライン見てもSTM32H5の話題が全く上がらず盛り上がって
ないのはこれが原因かと思われます。

OpenOCDのメーリングリストではH5試したけどL5みたいに動かないよー
というアーリーアダプタの方のコメントがありますがその後の進展は
全くなし…。

幸いにもSTマイクロ公式でForkしているOpenOCDのgitではひっそりと
STM32H5に対応しておりますがこちらも今年春から進展はなく、OpenOCD
本家の主流から大きく引き離されております。

とりあえずですがSTマイクロのソースコードを分析して最新のOpenOCD
でもビルド・動作できるようにしたものをねむいさんのおきぱに配置
しておりますのでご利用ください…

ところでL5とH5は同じCortex-M33コアなのになぜここまで違うのか？
という疑問ですがコアのrevid,devidを取得する関数が大幅に違います。
・STM32H5

static int stm32h5x_read_idcode(struct flash_bank *bank, uint32_t *id)

{

	struct target *target = bank->target;

	struct cortex_m_common *cortex_m = target_to_cm(bank->target);

	struct adiv5_ap *ap = cortex_m->armv7m.debug_ap;



	/* DBGMCU_IDCODE cannot be read from AP1, read it from ROM Table */

	target_addr_t dbgbase;

	uint32_t apid;

	int retval = dap_get_debugbase(ap, &dbgbase, &apid);

	if (retval != ERROR_OK)

		return retval;



	target_addr_t base_addr = dbgbase & 0xFFFFFFFFFFFFF000ull;



	/* PID Registers 0 to 3 are sufficient to identify the device */

	uint32_t pid_regs[4];



	retval = target_read_memory(target, base_addr + ARM_CS_PIDR0, 4, 4, (uint8_t *)pid_regs);

	if (retval != ERROR_OK)

		return retval;



	uint64_t pid = (pid_regs[3] & 0xff) << 24

					| (pid_regs[2] & 0xff) << 16

					| (pid_regs[1] & 0xff) << 8

					| (pid_regs[0] & 0xff);



	uint16_t dev_id = pid & 0x0FFF;

	uint8_t rev_id_major = pid >> 20 & 0xF;

	uint8_t rev_id_minor = pid >> 28 & 0xF;

	uint16_t rev_id = rev_id_major << 12 | rev_id_minor;



	*id = rev_id << 16 | dev_id;



	return retval;

}

・STM32L5たち

static int stm32l4_read_idcode(struct flash_bank *bank, uint32_t *id)

{

	int retval = ERROR_OK;

	struct target *target = bank->target;



	/* try reading possible IDCODE registers, in the following order */

	uint32_t dbgmcu_idcode[] = {DBGMCU_IDCODE_L4_G4, DBGMCU_IDCODE_L5, DBGMCU_IDCODE_G0};



	for (unsigned int i = 0; i < ARRAY_SIZE(dbgmcu_idcode); i++) {

		retval = target_read_u32(target, dbgmcu_idcode[i], id);

		if ((retval == ERROR_OK) && ((*id & 0xfff) != 0) && ((*id & 0xfff) != 0xfff))

			return ERROR_OK;

	}



	/* Workaround for STM32WL5x devices:

	 * DBGMCU_IDCODE cannot be read using CPU1 (Cortex-M0+) at AP1,

	 * to solve this read the UID64 (IEEE 64-bit unique device ID register) */



	struct armv7m_common *armv7m = target_to_armv7m_safe(target);

	if (!armv7m) {

		LOG_ERROR("Flash requires Cortex-M target");

		return ERROR_TARGET_INVALID;

	}



	/* CPU2 (Cortex-M0+) is supported only with non-hla adapters because it is on AP1.

	 * Using HLA adapters armv7m.debug_ap is null, and checking ap_num triggers a segfault */

	if (cortex_m_get_partno_safe(target) == CORTEX_M0P_PARTNO &&

			armv7m->debug_ap && armv7m->debug_ap->ap_num == 1) {

		uint32_t uid64_ids;



		/* UID64 is contains

		 *  - Bits 63:32 : DEVNUM (unique device number, different for each individual device)

		 *  - Bits 31:08 : STID (company ID) = 0x0080E1

		 *  - Bits 07:00 : DEVID (device ID) = 0x15

		 *

		 *  read only the fixed values {STID,DEVID} from UID64_IDS to identify the device as STM32WLx

		 */

		retval = target_read_u32(target, UID64_IDS, &uid64_ids);

		if (retval == ERROR_OK && uid64_ids == UID64_IDS_STM32WL) {

			/* force the DEV_ID to DEVID_STM32WLE_WL5XX and the REV_ID to unknown */

			*id = DEVID_STM32WLE_WL5XX;

			return ERROR_OK;

		}

	}



	LOG_ERROR("can't get the device id");

	return (retval == ERROR_OK) ? ERROR_FAIL : retval;

}

注:STM32L5のフラッシュ書き込みのコードはstm32l4x.cに取り込まれてます。

本来ならSTM32L5と同じくDBGMCU_IDCODEレジスタ(0xE0044000)から
読んでくれば終わる話なのですがSTM32H5ではそれができません。

DBGMCU_IDCODEがあるAHB-AP(AP1)から読もうとすると0しか返ってきません。
仕方ないのでAP0にあるROMTABLEからPID0~3を読みだしてdevid,revidを
読みだす必要があるわけです。んなことわかるか！！！

さて、何とかSTM32H5対応なおかつ最新のコミットにOpenOCDを対応させ
書き込みしてみたログは以下のようになりました。
書き込みスクリプトはねむいさん謹製のstm32h5x_flash.cfgを使用します。

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

openocd  -s C:/Devz/ARM/OCD/tcl -f interface/stlink-dap.cfg -c "transport select dapdirect_swd" -f target/stm32h5x_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.12.0+dev-00415-gacde409ba (2023-11-23-16:02)

Licensed under GNU GPL v2

For bug reports, read

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

dapdirect_swd

Info : STLINK V3J13M4 (API v3) VID:PID 0483:3754

Info : Target voltage: 3.278828

Info : Unable to match requested speed 480 kHz, using 200 kHz

Info : Unable to match requested speed 480 kHz, using 200 kHz

Info : clock speed 200 kHz

Info : stlink_dap_op_connect(connect)

Info : SWD DPIDR 0x6ba02477

Info : [stm32h5x.cpu] Cortex-M33 r0p4 processor detected

Info : [stm32h5x.cpu] target has 8 breakpoints, 4 watchpoints

Info : starting gdb server for stm32h5x.cpu on 3333

Info : Listening on port 3333 for gdb connections

Info : Unable to match requested speed 480 kHz, using 200 kHz

Info : Unable to match requested speed 480 kHz, using 200 kHz

CPU in Non-Secure state

[stm32h5x.cpu] halted due to debug-request, current mode: Thread 

xPSR: 0xf9000000 pc: 0x08030dac msp: 0x20050000

Info : Unable to match requested speed 4000 kHz, using 3300 kHz

Info : Unable to match requested speed 4000 kHz, using 3300 kHz

Info : device idcode = 0x10000484 (STM32H56/H57xx - Rev A : 0x1000)

Info : TZEN = 0xC3 : TrustZone disabled by option bytes

Info : Product State = 0xED : 'Open'

Info : flash size = 2048kbytes

Info : flash mode : dual-bank

Info : Padding image section 1 at 0x0805aa8c with 4 bytes (bank write end alignment)

Warn : Adding extra erase range, 0x0805aa90 .. 0x0805bfff

Info : wrote 371344 bytes from file main.elf in 1.537886s (235.805 KiB/s)

Info : verified 371340 bytes in 0.903676s (401.291 KiB/s)

Info : Unable to match requested speed 480 kHz, using 200 kHz

Info : Unable to match requested speed 480 kHz, using 200 kHz

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:04

ねむいさんが持ってるH5のはrev.Z(0x1001)のはずですが…なんでか
Rev.A(0x1000)になってるんですけぉ…まぁいいかそんあ詳細なこと。
書き込みスピードがメタクソ早くなっているのが救いですね～

なお、STM32H743のようにバグだらけのRev.Yと修正版のRev.V以降では
まったくの別物になっていたりしたケースがあるのでSTM32H5もこれから
先、Revが上がっていったらとんでもない地雷が待ち受けているかもしれ
ませんがまぁその時はその時で…

それとTrastZone無し限定ですがデバッグのほうももちろんすいすいと
できちゃいます。H5NucleoならSTLink-V3相当がビルドインされており
キビキビ反応してストレスレスでデバッグが可能です☆

そんなわけで再度紹介になりますが、STM32H5対応OpenOCDバイナリは
私のぶろぐのおきぱで公開しておりますのでH5の基板を持っている方は
どしどしご利用ください！！！

本当はソースコードの基礎部分と、とんでもない罠があるところを解説
したかったのですがOpenOCDだけで力尽きたので次回以降のエントリに
委ねたいと思います…登山ラッシュに入ってますが今年中には足掛かり
くらいは何とか気力振り絞って記事書きたいな～と思ってます。

H5のプロジェクト自体はすでに公開しておりますので
それまでに皆様予習をお願いいたします…ｚｚｚ

いろいろ試す56

ぁーGWですね～…
出張疲れでなんもやることないので今まで貯めてきたUSBシリアル
変換で嵌ったチョイネタを公開します。

●USB-シリアル変換のRTSとかの制御タイミングは結構適当？
　いいえ、ねむいさんの脳みそが適当(仕様)
ねむいさん副業(本業は二次裏メイド)でHalf-DuplexなRS485の
ちょっとした基板を製作しておりました。

MAX485データシートから抜粋と追加。
_REとDEを一つにまとめ、HIで送信、LOで受信に切り替えます。
そのような仕組みなので何らかの方法で入力と出力を切り換えないと
いけないのでRS232-Cの規格に存在するRTS信号出力を手動で切り
変えて送受信を制御してやろうと思ったのですが…

…うまく動かない…
なんか送信がぶつかってるような…
最初FTDIのやつ使ってたのですが通信できたりできなかったり
そんでProlificのやつ使ったら全く通信できにゃい！！！
ぬがああああああ！１１１！！！１！！

というところでようやくオシロスコープを引っ張り出して波形を
確認することにしました。ねむいさんいつも他人にはオシロで
ちゃんと波形確認しろと言っておきながら自分もめんどくさくて
やってない。

まぁそれは置いといて実際測定してみるとなんでか分かった。
まず検証に使ったソースコードですがVC++で適当にプロジェクト
作ってCreatefileでCOMポート開いてその際にDCB構造体のfRtsControl
に"RTS_CONTROL_TOGGLE"を設定しておきます。
これでWrite関数を実行、具体的には送信したい文字列を…
今回はDAAAAAAAAA¥r¥nというゼEROみたいな文字列を1秒ごとに
吐き続けるやつで検証してみました。

イケてるとき。
信号レベルはTTLレベルなので反転前なので注意してください。
ここで見るべきは文字列送信終了後にRTSが変化していることです。
でも1.5mSecもかかって信号レベルが遷移している・・？

イケてないとき。
なんと試行して数回目で発生した！！
送信し終わってないのにRTSが戻ってる！！！！
こりゃだめだ…。

RTSの信号をEscapeCommFunction関数で手動で変えてみたりしましたが
文字列送信中にRTSが受信方向に変化しやがったり逆に何mSecも戻
らなかったりもうぜんっぜんだめ…

もう疲れたのでFTDIの奴は置いといて今度はProlificのチップ
使ったUGREEN製のUSBシリアル変換ケーブルで試してみました。

注:信号レベルはRS232なので注意。それと時間レンジに注目！
おいいいいいいいいいいいいいいいいい！！１！！１！！！！
Open関数を実行したとたんRTSが立ちっぱなしになってもとに
戻らなくなってしまいました(COMポート閉じるまでこのまま)
お前なんなんだYO!

これはいけない。

ということでネットの海にダイブしていろいろ調査していると
ねむいさんと全く同じ状況に陥っている方がいました。
西村備山様の"滴了庵日録"の下記ブログ記事にはねむいさんと同じように
文字列を送り終わる前にRTSが変化しているのがわかります。
・FTDIのUSBシリアルの不具合？

また、さらに調査されていてHalf-DuplexでRS485をやりたい人は
TXDEN信号を使えばいいとのことです。
・PCのCOMポートをRS485に接続する

なぜRTSが適切なタイミングで変化してくれないのか、USBの規格や
仕様を考えたらすぐ分かる話なのですが物理COMポートはuSec単位で
反応できる一方、USBでは最速でも1mSec(USBフルスピードで)の
"フレーム単位"ごとにしか状態を変えられないことにあります。

20240829追:
HuMANDATA様がFTDIのRTSの制御線の遅延を検証されております！
必見です！！！！
20240829追:

また、西村様の上記記事の最後にFTDIのドライバでRTSがうまく
変化してくれないと言及されておりますが我らがProlificに
至ってはおそらくOpenFile(COMポート開いた)のタイミングで
RTSがいきなりビンッビンにおっ立ってしまい、もう治まり
そうにありません！！1！！もう許ちて！！！！

…すみません下ネタに近いこと言ってしまいましたが西村様のブログ記事に
倣い、FTDI系では方向制御にTXDENを使用することにしました。

うーむ完璧！USBシリアル変換でRS485でHalf-Duplexな通信
したい人はFTDIならTXDENを使えば良いですね。なんだかんだ
言ってFTDIが一番安定して使いやすいですし。

ちなみに秋月で販売しているCH340Eシリアル変換もTXDENに相当する
制御用ポートがあります。

秋月電子のデータシートより抜粋。
CH340EにはTNOWという端子がありこれがTXDENに相当します。
こいつを引っ張り出してあげましょう。モジュール上にはちょうどR4が
TNOWに付いてて半田もしやすいですね。

うーむこれも完璧☆

今を時めくUSBType-Cコネクタで何より安いのでこれは使い勝手良いかも！？

え、肝心のProlificはどこ行ったって？
ありゃだめですよぅ…(もはや測定する気力がない)。

20231103追：
HumanData様のサイトにRTCをトグルした際の遅延を測定した
データがあります。非常に参考になりました。
やはり2~3mSecの遅延があるようですね…
https://www.hdl.co.jp/USB/jkn016/
https://www.hdl.co.jp/USB-001/usb001-t4.html

●CP2102のぱちもん
前々回DS18B20のぱちもんを紹介しましたが中華製ぱちもん半導体の
勢いはとどまることを知らない。過去にFTDIの偽物が出回ってそれ
つぶすドライバが配布されて大混乱になりましたが、駆け込み寺で
使用されたSiliconLabs製のCP2102にもぱちもんが蔓延していた
ようです。

2017年にアメリカのMAKER系イベントで配布された名札代わりの
ボードの中に使用されていたUSBシリアル変換IC(CP2102)に偽物が
混ざっており動作せず人海戦術で対応に当たったという事象が
ありました。

なおこのぱちもんCP2102はUSB-TTL(3.3V出力付き)Breakoutボード
としてAmazonやebay,Aliexpressでも蔓延しており、見分け方が
提示されておりました。

さらに調べるとロットNo.と思われる部分に"DCL00X"と刻印されてる
奴はぱちもんのようですね。
さらにその基板はReset端子がVbus(+5V)直結になっているため、
Reset端子から電流が流れ込み+3.3Vラインが+4Vとかになってると
思われます。一応全端子5Vトレラントのようですがデータシートの
説明にはVDD(内部3.3Vレギュレータ)に4.7kohmでプルアップせよ
と明記されてますね。
抵抗じゃなくてヒューズがついてるのはOKとかそうではなくこの
パチモンCP2102使ったぱちもんモジュールを使うのを避けたほうが
いいですね…

ところで私の持ってるCP2102は大丈夫なのか！？調べてみました。

DOIT-AM製のESP32-DevKit-Cです。
DCL00Xじゃなくてとりあえず安心…

ESPRESSIF製のESP32-DevKit-C-VE
CP2102Nでした。多分大丈夫でしょう。
ESP32-DevKit-C-VE

ESP32-S3-DevkitC-1
こちらもCP2102Nでした。

今現在CP2102が実装された基板はESP32系だけでした。DOIT-AM製の
2016年末くらいの奴は怪しいかなと思ってたのですが回路図見たら
ちゃんとデータシートの言いつけを守っておりました…ｻｽｶﾞﾀﾞｧ…

因みにDOIT-AM製初期のDEVKIT-Cと秋月で購入したESP32-WROVER-E
を使用したESP32-DevKit-C-VEにはADP3338に交換済みです…！！
一方最新のESP32-S3-DevkitC-1に使用されているLDO、SGM2212は
ADP3338には及びませんがVdrop最悪値が0.6Vなのでまぁ使える
レベルにあると思います。

●UGREEN製のUSBシリアル変換を改造してみた
最初のRTSの件で使用したUGREEN製のですがRS485変換には使い物に
ならなかったのでとりあえず分解してみました

結構な化粧箱に入っておりました。921600bps対応とか抜かして
ますがもちろんそんなボーレートで通信できませんでした。

とりあえず殻むきして中身を出してみます。
よくあるDsub9Pinのコネクタを利用した基板直付けタイプですが…
なんかずれてて隣のパタンとショートしそうになってました！！

Dsub9pinコネクタを外してみました。金メッキとか抜かしてました
が外から見える部分だけ金メッキでした…びんぼっちゃまくんかな？

Prorific製ICはPL2303TAが使用されていますがこのチップ、すでに
ぱちもん対策で廃版になっておりPL2303Gが最新です。
ねむいさんPL2303Gが使用されてると抜かしてたので買ったのですが
まぁチャイナリスクってやつです(12年ぶり2回目)

信号レベル変換ICはZT213LEEAなるものが使用されています。
MAX212系のRS232Cレベル信号変換のICの中華版でしょうか。

データシートを見るとMAX250kbps...
ねむいさん921600bps対応って抜かしてたので買っ(ry

とりあえず先ずは使い勝手を良くしちゃいましょう。
これからシリアル番号をつけて同じPCのどこのUSBポートに
挿してもCOMポートが固定されるように改造します。

PL2303TAのデータシートは外付けEEPROMは24C02を要求してますので
これをつけてやります。

ついでに空いていたD1に青色LEDつけちゃいます。

さらにどっかから拾ってきたEEPROMWriterでシリアル番号の書き換えに
成功です！やったぜ。

基板を覆っていたモールドは取り出し時に破壊しちゃいましたので
コネクタを追加して元のケーブルも活用することにしました。
ていうかケーブルだけは作りが無駄にしっかりしてますね…

まぁ仕事で使うのって9600bpsが関の山だから921600bps出なくても
良いっていえば良いんですけどね…ぶつぶつぶつ・・・・

そんなわけでUSBシリアル変換のことばかりだらだら紹介してしまい
ましたがUSBシリアルについてはこれだけは言わせてもらいたいです！

１．FTDI製はやっぱり鉄板
　　->何だかんだで一番安定してます。
　　　迷ったら真っ先にこれを使いましょう!もちろん本物をですよ！
　　
２．中華製ぱちもんには気をつけろ！
　　->AmazonやAliexpress,ebayでは偽物に気を付けてください。
　　　安物買いの銭失いとならないようにしましょう。

３．あえて中華製使いたいのならお覚悟を
　　->Prolificとかはぱちもん対策でばんばんモデルチェンジ
　　　してますが正規品でもちょっと道から外れた使い方したら
　　　思ったように動かないとかざらだったりCH340系もかなり
　　　癖があるので心してかかるように、また他の方の使用記を
　　　しっかり読み込んだ上で挑みましょう！

STM32C0はぢめました

20240430追:
秋月さんでNUCLEO-STM32C031C6が販売されました！！！
20240430追:

個人ぶろぐでは一番のりかな！？

てわけでリリースしたばかりのSTM32C0シリーズに手を出しました。
立ち位置的にはSTM32G0から機能をシュリンクし、コストを下げて
8/16bitの価格帯に32bitを持ち込む戦略のようです。

評価基板もDiscovery/Nucleo系がすでにリリースされており、
ねむいさんはSTM32C031C6-NUCLEO基板を入手しました。

ところで2021年以降のNucleoはコネクタがUSB-MicroBに変わっているので
ご注意ください…！

そんでもってAVCCが3.3Vに接続されてませんのでご注意ください…
これで30分はまった…orz

基本的な使い方はSTM32G0と全く変わりません。つまりG0からC0への
移植も全く苦ではありませんでした。

ちなみにSTM32CubeC0ライブラリもGithubに登場しております。
STMicro公式からもダウンロードできますが更新が遅く落とすために
登録があって面倒なのでGithubから落としたほうが楽です。

ちなみにuSecディレイに使っている一般タイマですが、HALが微妙に
バージョンアップしていて構造体変数が１個追加されてやがりました。
実はSTM32G0から追加されていたようですが普通に動作してたのでずっと
気づかず、STM32C0では最初うまく動作しなかったところで初めて
気づき30分ほど足止めを喰らいましたorzマニュアルはちゃんと読もう。

というわけでいつものI2Cデバイスをぶら下げて動作させてみます。

こんな感じで何事もなく動作しました☆
AVCCがジャンパされてなかったり変数設定の漏れがあったり
何事もあった気がしたけど気のせいです。

おっとその前に、順番が入れ違いましたがOpenOCDはまだ公式には
STM32C0シリーズのフラッシュ書き込みに対応していませんがgerritに
パッチが上がっています。こいつを適用したOpenOCDをビルドして
さらにSTM32C0用書き込みスクリプトも準備して書き込んでみます。

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

openocd  -s C:/Devz/ARM/OCD/tcl -f interface/stlink-dap.cfg -c "transport select dapdirect_swd" -f target/stm32c0x_swd_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.12.0+dev-00075-g79caea874 (2023-02-23-23:36)

Licensed under GNU GPL v2

For bug reports, read

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

dapdirect_swd

Info : STLINK V2J38M27 (API v2) VID:PID 0483:374B

Info : Target voltage: 3.227154

Info : Unable to match requested speed 500 kHz, using 480 kHz

Info : Unable to match requested speed 500 kHz, using 480 kHz

Info : clock speed 480 kHz

Info : stlink_dap_op_connect(connect)

Info : SWD DPIDR 0x0bc11477

Info : [stm32c0x.cpu] Cortex-M0+ r0p1 processor detected

Info : [stm32c0x.cpu] target has 4 breakpoints, 2 watchpoints

Info : starting gdb server for stm32c0x.cpu on 3333

Info : Listening on port 3333 for gdb connections

[stm32c0x.cpu] halted due to debug-request, current mode: Thread 

xPSR: 0xf1000000 pc: 0x08001918 msp: 0x20003000

Info : device idcode = 0x10006453 (STM32C03xx - Rev A : 0x1000)

Info : RDP level 0 (0xAA)

Info : flash size = 32 KiB

Info : flash mode : single-bank

Warn : Adding extra erase range, 0x08006070 .. 0x080067ff

Info : wrote 24688 bytes from file main.elf in 1.217141s (19.808 KiB/s)

Info : verified 24688 bytes in 0.269830s (89.350 KiB/s)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:02

なおOpenOCDでは内部的にはG0と同じくフラッシュ書き込みルーチンが
L4シリーズと同じ扱いになっています。

そんなわけでSTM32C0にも対応したOpenOCDのWindowsバイナリは
すでにおきぱにて公開しております！STM32C0を手に入れた人は
バンバン使っていただけるとありがたいです！

ついでにNUCLEO向けのテストプログラムも公開しております。
新規プロジェクトの取っ掛かりにご利用ください！！

いろいろ試す54 -2022年反省会-

すみませんやっと時間取れましたが今年残りあと0.2時間くらい…

●OpenOCD-0.12.0-RC3更新
OpenOCDももうすぐ0.13.0になろうとしておりますがRC2->RC3の私的に
注目する更新は、RTOSの自動検知でRTOSがサポートしてないもしくはRTOS
未使用の際にステップ実行したとたんに落ちていたのが修正された…
…のはよいのですが今度はねむいさん特製cfgファイルのほうと衝突
しちゃってTARGETNAME設定の際にとりあえず出つけていた"rtos auto"の
オプションはcfgファイルから削除するようにしました。

ねむいさんRTOSほとんど使ってませんし唯一(仕事で)使ってるMbedOSは
OpenOCDのスレッド検知非対応でrtos autoの設定は実質無意味になっちゃい
ましたからはずしてしまいました。

またつぶしが効くような修正や逆に私がRTOSサポートに本腰入れるように
なったらこの辺りもう一度見直そうと思います…

というわけで今年最後の更新かつ2022年末最新のOpenOCDバイナリはこちらと
なりますのでどしどしつかいたおしてくださいっ！

さりげなくSTM32G4とSTM32L4のフラッシュ書き込みに対応しております！

●AVRDUDEが相わからず更新しまくり
なんでこんな恐ろしいスピードで更新しまくっているのか…！？
息を吹き返していま最もホットなavrdudeもビシバシ充てられるコミット
にしがみついて追従しております。

ところでいつまでバージョン表記はv7.0-20220508のままなんですかね…
中身めちゃくちゃ変わってるんですけぉ…

まぁそれは置いといてこちらは31日付でビルドしなおしております。
こちらもびしばしつかいたおしてくださいっ！

●Android狂騒曲
20230123追：内容が酷過ぎたので少しまともに修正
もう作業進める時間が欲しくてこのブログ書いてる暇が全くないのですが
仕事で必要になりAndroidのタブレットを自分でも購入したことからすべては
はぢまってしまいました。Android上でPythonを走らせてさらにGUIを動かす
という作戦を現在敢行しております。

ガチドザのねむいさんにははぢめてのこと過ぎてあまりにもハードルが
高すぎましたが下記の手順でPythonでGUIを動かすところまで行けてます。

1.Termuxインストール
2.Termuxのエミュレータ端末からPython3インストール
3.同じくpython-tkinterインストール
4.pipでPyserialインストール
5.pipでPySimpleGUIインストール
6.PySimpleGUIのためのx-window導入
7.VNCViewerインストール

上記の長い手順を踏んだうえでser2net化したラズパイZeroとUSB-OTGで
STM32G431K-Nucleoを接続し(STLinkはUSBシリアル変換として動作する)、
さらにwifi経由でラズパイZeroとAndroid間であたかも通常のシリアル
通信のようにデータをやり取りできるところまでできました！！！

今回の例はDHT系の温湿度モジュールAM2322Bの温湿度データを取得して
Termux上のPythonGUI上に温湿度データを取得表示しているところです。
XFCEのデスクトップ画面は殺風景すぎるのでﾃﾞb東條希さんが横たわってる
壁紙で多少の癒し効果を与えております。

ところでこんな回りくどいことやらずに素直にkotlinで直接TCPで通信する
Androidアプリ作れやだって！？
あのね！ねむいさんがそんな正攻法するわけないでしょ！

この狂騒曲はまだ続いておりますが落ち着いたら改めてやったことの
整理ついでに詳細を紹介する予定です。

●Transcend製の3D-TLCの産業用microSDカードTS256GUSD460Tを買った

というわけでTranscendの産業用microsd460Tが市場に出回ってしまったので
年末のくそ忙しい今買って試しました！

まずはWin10でベンチ。直線もチマチマも十分の実力ですね～

例のあれでSMARTを取得してみました。しっかり読み取れますね！
お次はいつもので読んで見ます。

FatFs module test terminal for STM32H747XIH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Dec  5 2022

>fg piano



rc=0 FR_OK

>fo 1 ftbt.mp3



rc=0 FR_OK

>fr 132949600



132949600 bytes read at 21495 kB/sec.

>fs



FAT type = exFAT

Bytes/Cluster = 262144

Number of FATs = 1

Root DIR entries = 0

Sectors/FAT = 32768

Number of clusters = 954112

Volume start (lba) = 65536

FAT start (lba) = 98304

DIR start (lba,clustor) = 4

Data start (lba) = 131072



Volume name is TS256G460T

Volume S/N is 9C33-6BBD

...

1 files, 132949600 bytes.

244252672 folders.

244120832 KiB total disk space.

4 KiB available.

>ds 0



rc=0

Drive size: 488636416 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 DB 79 00 07 47 FF 7F 80 0A 40 00 73  @..2.y..G....@.s

CID:

00000000  74 4A 60 55 53 44 55 31 20 80 36 D4 80 01 6A 73  tJ`USDU1 .6...js



Parsing SD CID Register

Manufacturer ID    :0x74

OEM/Application ID :J`

Product Name       :USDU1

Product HwRev      :2

Product SwRev      :0

Serial Number      :0x8036D480

DateCode.Month     :10

DateCode.Year      :2022



OCR:

00000000  C1 FF 80 00  ....

SD Status:

00000000  80 00 00 00 08 00 00 00 04 00 90 00 08 11 39 1E  ..............9.

00000010  00 08 00 00 00 02 FC 00 00 00 00 00 00 00 00 00  ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

SCR:

00000000  02 45 84 87 00 00 00 00  .E......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Spec Version X  :2

SD Security        :4

SD Bus Width       :5



SD_Spec V6.xx!

Detected as SDXC Card!

Available UHS-I Mode.

Available UHS Speed Class U3.

Available SD Speed Class 10.

Available Video Speed Class 30.

Available Application Performance Class2, A2 Card.

A2 CommandQueue Depth 32 Supported

A2 Cache Supported.

>

A2クラスはもはや当たり前となりましたね～
最もA2に対応したSDホストでないと真価は出ませんが…

そして産業用microSDもだいぶそろってきましたのでここらでラズパイ
向けの価格性能比が最も優れたもの比較でもやりましょう…！
と言いたいところですがもう時間がないので来年に…

●毎年恒例ねむいさんQ&A
Q:ねむいさん…Codelite使ったARMデバッグ手順のﾎｳﾊ…
A:あああああああああああああああああ１！１！！１１！
　

　今最新のGCC12でもLPC2388(ARM7TDMI)のデバッグできまくるの確かめた
　ところまできやがってます！！！！！もうちょっとまって！１！！！
　

　☝GCC12でひりだしたelfはinsightで読めないので苦しみ紛れに屁こいた
　みたいな釈明でその場をしのがせていただきます…
　
Q:時間ない割には山にはいくんだ？
A:それは別腹です

Q:それとDropBOXの過去の消えた画像は？毎年言ってますが…
A:…
　…
　来年から本気出す！！
　それではよいお年を～

いろいろ試す53

副業(本業は二次裏メイド)が激務になったのと秋の登山ラリーが始まったので
まったく時間が取れてませんが何とか進めていきたいと思います…

●ようやくSWDマルチドロップも使い物に･･･！
-OpenOCD-0.12.0-RC2更新-
長かった…ラズパイピコが登場してから長い戦いだったがようやく本家にも
安定した状態で取り込まれたようですね…感無量です。

↓以下RaspiPicoに書き込んだところのログ

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

openocd  -s C:/Devz/ARM/OCD/tcl -f interface/jtagkey2_swd.cfg -f target/rp2040_swd_flash.cfg -c "mt_flash_bin main.bin 0x10000000"

Open On-Chip Debugger 0.12.0-rc2+dev-00001-g12ce17094 (2022-10-30-22:35)

Licensed under GNU GPL v2

For bug reports, read

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

Info : FTDI SWD mode enabled

Warn : Transport "swd" was already selected

Info : clock speed 1000 kHz

Info : SWD DPIDR 0x0bc12477, DLPIDR 0x00000001

Info : SWD DPIDR 0x0bc12477, DLPIDR 0x10000001

Info : [rp2040.core0] Cortex-M0+ r0p1 processor detected

Info : [rp2040.core0] target has 4 breakpoints, 2 watchpoints

Info : [rp2040.core1] Cortex-M0+ r0p1 processor detected

Info : [rp2040.core1] target has 4 breakpoints, 2 watchpoints

Info : starting gdb server for rp2040.core0 on 3333

Info : Listening on port 3333 for gdb connections

Info : starting gdb server for rp2040.core1 on 3334

Info : Listening on port 3334 for gdb connections

[rp2040.core0] halted due to debug-request, current mode: Thread 

xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00

[rp2040.core1] halted due to debug-request, current mode: Thread 

xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00

Info : Found flash device 'win w25q16jv' (ID 0x001540ef)

Info : RP2040 B0 Flash Probe: 2097152 bytes @0x10000000, in 32 sectors



Info : Padding image section 0 at 0x1001fe80 with 128 bytes (bank write end alignment)

Warn : Adding extra erase range, 0x1001ff00 .. 0x1001ffff

Info : wrote 130816 bytes from file main.bin in 4.495757s (28.416 KiB/s)

Info : verified 130688 bytes in 0.206712s (617.405 KiB/s)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:05

コアがちゃんと2つ見えているのがわかりますね～
また、注目すべき点はコアの数だけgdbサーバのポートも増加している点です
デバッグ時はgdbも一個ずつ起動してつなげていきます

openocdも0.12.0になってARM以外のかなりのCPUコアもサポートしています。
STM8はすでに書き込みデバッグに成功していますが新規にサポートされた
RISCVのGD32V系、また本家にサポートが取り込まれたESP32などはまだ全くの
手付かずなのでこれから挑戦していきたいと思います！

というところでねむいさん特製ビルドのOpenOCDはこちらになりますので
どしどしお使いください…！

●で、CodeLiteとGDBを使ったデバッグはどうなったの？

…正直まだ検証が進んでません…
10年同じ事やってたのでtarget extended-remoteってなんだよってとこから
再開ですしSTM32の検証がやっと終わってほかのcortex-M、あとARM7TDMIも
見ていこうと思ってますがすべてのCPUで安定して動かせられるパタンが中々
見つからず苦戦しています。
・今できてること
　→ステップ実行(ステップイン/ステップアウト)
　→ブレークポイント
　→変数読み取り
・InsightではできたがCodeLiteでできなくなったこと
　→IOViewでペリフェラルを直感的にたたけなくなった
　　　(gdbのprintコマンドでせこせこ変えるしかない)
　→main関数内の最上位でステップアウトをうっかりやらかすと死ぬ
　→ブレークポイントを設定しないでrunさせたら死ぬ
　→調子おかしくなったと感じてstopしてもgdbにコマンドがなぜか通らず死ぬ
　→とにかく機嫌損ねたら死ぬ
　

死んだらこちらも能動的に殺しにかかってtaskkillコマンドでOpenOCDごと
強制終了してつなぎなおしてます。Insight時代からやってましたがよく
わからなくなったら全部終了で再開するのが最適だと感じてます。
画像はNuvotonのnano130のデバッグ終了時の画面です…いささか強引ですが
これが一番楽…とこんな感じでLPC系のマイコンとかも確認を進めていきます。

●avrdudeがものすごく中身変わっていた
avrdudeがすさまじい勢いで修正がかかりまくりどんどん進化してます
当然途中で大変更が発生することもあり、これで深刻な影響を受けるのは
たいていビルドする人間です…orzビルドが通らなくなったorz

今回readline周りが大幅変更でまともにビルド通らず動かずで難儀しましたが
何とか安定して動かすことができました…細かいことは省きますがreadlineが
dllとして追加になりました。もちろん自前ビルドです。
以下avr128da48に書き込んだ時のログ

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

C:/Devz/AVR/avrdude/avrdude -v -p avr128da48 -P usb -c pkobn_updi    -U flash:w:main.bin 



avrdude: Version 7.0-20220508

         Copyright (c) Brian Dean, http://www.bdmicro.com/

         Copyright (c) Joerg Wunsch



         System wide configuration file is C:¥Devz¥AVR¥avrdude¥avrdude.conf



avrdude: input file main.bin auto detected as raw binary

         Using Port                    : usb

         Using Programmer              : pkobn_updi

avrdude: found CMSIS-DAP compliant device, using EDBG protocol

         AVR Part                      : AVR128DA48

         RESET disposition             : dedicated

         RETRY pulse                   : SCK

         Serial program mode           : yes

         Parallel program mode         : yes

         Memory Detail                 :



                                           Block Poll               Page                       Polled

           Memory Type Alias    Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack

           ----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------

           fuse0       wdtcfg      0     0     0    0 no          1    1      0     0     0 0x00 0x00

           fuse1       bodcfg      0     0     0    0 no          1    1      0     0     0 0x00 0x00

           fuse2       osccfg      0     0     0    0 no          1    1      0     0     0 0x00 0x00

           fuse4       tcd0cfg     0     0     0    0 no          1    1      0     0     0 0x00 0x00

           fuse5       syscfg0     0     0     0    0 no          1    1      0     0     0 0x00 0x00

           fuse6       syscfg1     0     0     0    0 no          1    1      0     0     0 0x00 0x00

           fuse7       codesize    0     0     0    0 no          1    1      0     0     0 0x00 0x00

           fuse8       bootsize    0     0     0    0 no          1    1      0     0     0 0x00 0x00

           fuses                   0     0     0    0 no          9   16      0     0     0 0x00 0x00

           lock                    0     0     0    0 no          4    1      0     0     0 0x00 0x00

           tempsense               0     0     0    0 no          2    1      0     0     0 0x00 0x00

           signature               0     0     0    0 no          3    1      0     0     0 0x00 0x00

           prodsig                 0     0     0    0 no        125  125      0     0     0 0x00 0x00

           sernum                  0     0     0    0 no         16    1      0     0     0 0x00 0x00

           userrow     usersig     0     0     0    0 no         32   32      0     0     0 0x00 0x00

           data                    0     0     0    0 no          0    1      0     0     0 0x00 0x00

           eeprom                  0     0     0    0 no        512    1      0     0     0 0x00 0x00

           flash                   0     0     0    0 no     131072  512      0     0     0 0x00 0x00



         Programmer Type : JTAGICE3_UPDI

         Description     : Curiosity nano (nEDBG) in UPDI mode

         ICE HW version  : 0

         ICE FW version  : 1.21 (rel. 37)

         Serial number   : MCHP3280031800001375

         Vtarget         : 3.31 V

         PDI/UPDI clock Xmega/megaAVR : 100 kHz

avrdude: partial Family_ID returned: "    "

avrdude: AVR device initialized and ready to accept instructions

avrdude: device signature = 0x1e9708 (probably avr128da48)

avrdude: Note: flash memory has been specified, an erase cycle will be performed.

         To disable this feature, specify the -D option.

erasing chip

avrdude: reading input file main.bin for flash

         with 3392 bytes in 1 section within [0, 0xd3f]

         using 7 pages and 192 pad bytes

avrdude: writing 3392 bytes flash ...



Writing | ################################################## | 100% 1.09s



avrdude: 3392 bytes of flash written

avrdude: verifying flash memory against main.bin



Reading | ################################################## | 100% 0.60s



avrdude: 3392 bytes of flash verified



avrdude done.  Thank you.





> Process Exit Code: 0

> Time Taken: 00:02

正直大変更前と見た目は全く変わらないので見栄えがしませんがいろんな人の努力で
どんどん機能がパワーアップしていくわけですね…

avrdudeの10月末最新のバイナリもアップロードしました。
こちらもどんどん使ってくださいませ～！

いろいろ試す52

●CodeLite+GDBを使ったARMデバッグ環境移行加速す！

oh...myｺﾝﾌﾞ･･･とうとうこの日がやってきた…
InsightだとGCC12からサポートされたdwarf5フォーマットのelfが読めない…
ARM-GCCのバグのせいかdwarf4形式のリンカオプションつけてもdwarf5･･･

orz

というわけでねむいさんのぶろぐ旗揚げから13年間続けてきたInsightによる
デバッグ法に別れを告げ、かねてより評価中のCodeLiteによるGDBデバッグ
環境移行と同手順書作成に本腰を入れております！

移行で一番の障壁はworkspaceの概念でしたが…幸いにもディレクトリを遡る
相対アクセスが問題なくできたのでmain.elfを相対参照するようにしたら
デバッグするたびいちいち設定しなおす必要もなく同一のworkspaceファイル
の使いまわしができそうです！

CodeLite.exeはなんでかgnumake3.81から直接召喚できなかったのでwindowsの
CMDでの機能で代用しました。ちゃんと引数付きで呼び出しもできたので
ここで上で説明したworkspaceファイルを相対アクセスで開きます。

実際のデバッグ画面です。
ソースレベルでステップ実行とかの基本は当たり前の余裕ですね。

InsightではWin10では即堕ちして使いものにならなかったCPUレジスタ参照は
バリバリできています。

F7,H7の浮動小数点レジスタも楽勝です♨

…なのですがなんでかこれらレジスタ表記は10進数(一部は16進数)固定で、
進数の切り替えができません。Insightでは柔軟にできてたのでここに
ついては要改善ポインツですね。

また、周辺I/Oのレジスタ値を直接参照するIOView機能とかも一応使えます。
IOViewは周辺レジスタをconst宣言しているせいか、変数参照ウインドウから
直接値を変えられませんでした。
constでも値を自由に変えられちゃうInsightのほうが逆にダメだったのかも。

回避策としてOutputウインドウからコマンド直接入力で値を変えられます。
Outputウインドウと銘打ってますがGDBのコマンド入力も受け付けています。

そして特筆すべきはInsightとは違いGDBから完全に独立したGUIとして働くので
ARMだけではなく他のCPUコアでもそれ用のGDBさえあてがえば普通に使えます！
先月紹介したSTM8Lもご覧の通りばりばりデバッグ可能です！
ていうかSTM8Lの記事ぶん投げっぱなしですが来月がんばります！！！！

となるとESP32とAVRのデバッグ環境もCodeLiteで一括化できそうなので、特に
5年くらい放置してるESP32とかはやる気出てまた活動再開できそうな感じです☆
ARMマイコンビルド/デバッグ環境構築手順もCodeLite+GDBデバッグを主眼にした
2022年版に書き替えている最中ですのでこうご期待！

また、待ちきれない方に先んじてWin10環境下でCodeLite+GDBのデバッグ環境
対応のプロジェクトに更新しております。現在以下のものが対象です!
・STM32H7-Disco
・STM32F7-Disco
・STM32F4-Discovery
・STM32G0ベアメタル

●ARM-GCCがまたアップデートしていた。
まず、前回のいろいろ試すでアップデートされたGCCでビルドすると…

前回記事にしていたにかかわらずこれ気づかんかった…
ちゃんと検証してなかったのバレバレの私orz
これかなり致命的なバグでしたね…私のおきぱのプロジェクトがほぼビルド
不可能状態でした…すみません。
これ前回のいろいろ試すにも警告書いときます。

現行のGCC11.3ものは緊急修正が加わってちゃんとビルドできるようになってます。
が、冒頭のdwarf5の問題でInsightデバッグができなくなってますので要注意！

●AVRDUDEにパッチを投げたお話
これも9年越しの話なのですがねむいさんはJTAGKEY等のFT2232系のISP/JTAG
書き込みで、1セクタサイズ以下のサイズのバイナリを書こうとしたら正常に
書き込めないバグを見つけておりました。しかし、そんな超限定された条件、
例えば128kByteの容量を持つatmega1284p(フラッシュセクタサイズ256Byte)に
たった202バイトの容量のLチカプログラムを書き込むやつがいるだろうか？
という原因からか9年放置されていました。

が、オワコン化したかと思われたavrdudeがgithubに移行したとたんバリバリ
更新がかかりまくるようになり、9年前の問題が再び目に留まったのでわたしも
この問題に決着をつけるべく参戦を果たしました！！！
(☝お前AVR辞めたんちゃうんかいという突っ込みは一切なしで)

その後、管理者の人のコードレビューと別の修正が合体して正式にコミット
されています。

リンク先の議論にもありますがねむいさん的には符号付整数で比較を
行うと符号拡張で符号なし整数では思わぬでかい数字が入ってしまって
思ったような評価ができないのを危惧したのですが最終的に符号なし
整数同士の評価で終わるようにしてくれて実際に問題なく書き込みが
できるようになったのでよしとしましょう。

在庫復活記念！！ATTINY202を限界まで使い倒す！

●ATTINY202復ｯ活ｯ！
プーチンが突然けぉって顔真っ赤にしてウクライナに侵攻してから
半導体の納期がさらに悪化する兆しを見せやがっておりますが、その中で
ATTINY202の在庫が秋月電子通商さんに復活しました！！

なんか20円値上がりしてる気がしますがたぶん気のせいでしょう…
そんなこと気にするより在庫が復活するのが超重要事項なのです！！！！

扱いが非常に簡単かつ非常に安価に使いまわせるので様々な
シーンで活躍していくことでしょう！！

●ていうわけでねむいさんも本腰入れて使ってみました
昨年になってATTINY202のポテンシャルに気付いた方々が爆買いに走り
気づいた時にはすっからかんとなっておりました。ねむいさんもちょっと
動かして満足してほっぽっていましたが他の方の使用例に刺激されて
ATTINY202のROM容量限界まで使ってみました！！！

なお,ATTINY202はメモリリソースが非常に少ないです…。
ROM:2048Byte
RAM:128Byte

ねむいさんいつもSTM32H7等の大容量メモリを扱ってたのでパワーゲームに
慣れきってしまったせいか逆に少ないリソースのマイコンは新鮮に感じます。

私のモットーとしては
１．スタックを考慮してRAMはなるべく使用しない。
２．ROMもメモリ容量圧縮しつつギッチギチに使う

で攻めてみます！

●作例1：1-Wire温湿度計
過去にSTM32G0を使用したときのAosong製AM2322Bを今回も採用して
出力をUARTから吐くようなプログラムを作ってみました！

ROM容量は2037Byte....2048バイトまで10バイト弱…これはｷﾞﾘｷﾞﾘ

-fno-split-wide-typesをコメントアウトしてみました…
2バイト削減…もはや数バイトの戦い！

関数突入時のプロローグ/エピローグルーチンをあらかじめ作ってROM容量を
削減する効果がある-mcall-prologuesをあえてコメントアウト！
使用する関数がごく少ない場合は逆にコメントアウトしたほうがROM容量が
減ってお得です☆これで2027バイト…まぁこれでよいでしょう…！

なお、XMEGAとかでこのオプションちゃんと付けてないと確実に容量が
膨れ上がって爆死します☠

動いたところはこんな感じです。
内蔵クロックが20MHzもあるので230400bpsでも余裕です☆

●作例2:2-Wireで定番LCD(IC:HD44780)を動かす
すでにI2Cでキャラクタ液晶動かすネタはほかの人がやってしまっているので
ひねくれ者のねむいさんは11年前の無理やりすぎるやつをやってみました！
SUNLIKE製の安く購入できるものに代表される2行16文字で内臓コントローラ
ICがHD44780互換なキャラクタ液晶モジュールを受動部品を追加してたったの
2線で動かしちゃう実用性皆無の超力技です！~~中国だもんなア…~~
↑のリンク先で牛という単語が散見しますが中国では牛を肯定的な意味で使用
　されることがあるとのことです。この力業は文字通り強い牛を見るようだ。

ソースコードは上リンクの中国の人のATMega16のものをベースに汎用で幅広く
使えるように一般公開向けに現在整備中です！
間に合わなかったわけじゃないよ！

しかし…

そこに立ちふさがるROM容量の壁！orz
ああっつ!｢作例1：1-Wire温湿度計の計測｣結果をUART出力の代わりに
かっこよく表示して今回の記事を〆たかったのに容量ぜんぜん足らない…！
あと500Byteあれば…

･･･

15分ほど頑張りましたが挫けてしまい文字列表示ルーチンだけ走らせて
敗戦の弁を述べさせていただきます…orz

というわけでSTM32に慣れ切った私の体には負担が強すぎたのはわかりましたが
ATTINY202の(ROM容量の)イッパイ使用できて非常に満足しております…！
今回の記事で紹介した作例のソースコードはまだ公開用に整備中なので
もうしばらくお待ちいただければ幸いです。
20231201追:
ATTINY202の無理やりすぎるプロジェクトを上げました。
ついてこれる人だけついてきてください…！！！
20231201追:

ところでねむいさん今回はUPDIプログラマ使ってなくてなんかUSBシリアル
変換だけで開発してない？ですって！？
それの詳細は次回以降でみっっっちりと解説させていただきますよぅ♥
ATTIY202売り切れしたのってこれ絡みが原因だったかもれませんがこうご期待！

いろいろ試す50(+2021年反省会)

今年もいろいろありましたね…
月一更新は何とか続いてますがネタはあるのですが試す時間がない状態で
どんどん積みあがってる状態です…！

●Transcend製産業用MicroSD TS256GUSD430Tを試す！

ちょっと臨時収入が入りましたのでAMAZONのTranscend公式から産業用MicroSD
TS256GUSD430Tを購入しました！！

こちらは以前購入したSLCModeの品種と同じくS.M.A.R.T.を取得せしめることが
可能となっており、寿命の把握が簡単にできます！

また、SLCModeは無く通常の3D-NANDの構成のため以前のものと比べてちまちま
書き込みはそこまで早くはないのですが、これも実用には十分すぎるレベルと思います。

次にSTM32H7DiscoveryのFatFsサンプルでカード情報を読みだしてみます。

FatFs module test terminal for STM32H747XIH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Dec 30 2021

>fg piano



rc=0 FR_OK

>fo 1 ftbt.mp3



rc=0 FR_OK

>fr 132949600



132949600 bytes read at 22051 kB/sec.

>fs



FAT type = exFAT

Bytes/Cluster = 262144

Number of FATs = 1

Root DIR entries = 0

Sectors/FAT = 32768

Number of clusters = 943744

Volume start (lba) = 65536

FAT start (lba) = 98304

DIR start (lba,clustor) = 4

Data start (lba) = 131072



Volume name is TS256GUSD

Volume S/N is 9C33-6BBD

...

1 files, 132949600 bytes.

241598464 folders.

241466624 KiB total disk space.

4 KiB available.

>ds 0



rc=0

Drive size: 483328000 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 DB 79 00 07 33 BF 7F 80 0A 40 00 85  @..2.y..3....@..

CID:

00000000  74 4A 60 55 53 44 55 31 20 31 07 84 ED 01 57 09  tJ`USDU1 1....W.



Parsing SD CID Register

Manufacturer ID    :0x74

OEM/Application ID :J`

Product Name       :USDU1

Product HwRev      :2

Product SwRev      :0

Serial Number      :0x310784ED

DateCode.Month     :7

DateCode.Year      :2021



OCR:

00000000  C1 FF 80 00  ....

SD Status:

00000000  80 00 00 00 08 00 00 00 04 00 90 00 08 11 39 1E  ..............9.

00000010  00 08 00 00 00 02 FC 00 00 00 00 00 00 00 00 00  ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

SCR:

00000000  02 05 84 87 00 00 00 00  ........



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Spec Version X  :2

SD Security        :0

SD Bus Width       :5



SD_Spec V6.xx!

Detected as Not SD Card!

Available UHS-I Mode.

Available UHS Speed Class U3.

Available SD Speed Class 10.

Available Video Speed Class 30.

Available Application Performance Class2, A2 Card.

A2 CommandQueue Depth 32 Supported

A2 Cache Supported.

>

もう当たり前のようにA2(対応ホストじゃないと恩恵ないですが)でU3速度ですね。
純粋な読み出しスピードも22MB/Secと理論上の速度に近い値が出てますね。

お次はCMD56コマンドでSMART情報を読みだしてみました。
ぇっ？どうやって見るのって？
./lib/ff/sdmmc_stm32h7.hとか見たら幸せになれるかも！？

"Transcend"のヘッダが読みだされ、ちゃんとSMART情報が得られていることが
わかります。生データはこちらになります。

そしてRDF5を使ってあれを使うとWindowsからSMARTを読み出せちゃいます！！
ねむいさんがあまりにダイナミックにやってしまったせいか"ソフトは法人専用"って
念押しの文章が付け加えられてしまいましたが仕事でTranscendのCF使ってるから
セーフ！セーフ！！
それはさておき"Current SD Card Sped Mode"のD0ってなにやねんという
ところですがここに相当する番地(0x47)の値が0となっているため12MB/Sec
(DefaultSpeed)扱いになってるようです。
でもちゃんとUHS-Iの速度は出てるのは上のベンチにあるとおりです。
まぁ動作に影響はないので問題はないでしょう～

というわけでTaranscendの産業用カードを紹介しました。こちらもRaspi用
ストレージにお勧めだそうで、230Iでは容量が足らない場合はこちらを使って
みたらよいと思います。

●プローブを短くて使いやすいやつに買い替えた話

今日びのオシロプローブは細かい回路に対応するためプローブ本体もコンパクトに
なっておりますがTektroとかの正規品はべらぼうに高くなかなか買う気が起きません。
そんな折安価なプローブでおなじみのHONGKONG TEXAS社から新型プローブが
販売されていることを知り早速購入しました！！！

まだ秋月には出回っておらず、だいぶ前にktekさんという業者さんより購入しました。
先っちょにつける高速信号用アダプターがおまけです。

TX6550A/Bはアナログ帯域は500MHzあり、実力は十分です。
なおTX6550Aが先端シャフト系2.5mm品でTX6550Bが従来の5mm品です。

秋月で販売されている同社の同スペックのプローブと大きさ比較です。
もう図体が全然違うことがわかりますね～細かい回路でプローブ引っ掛ける際に
特に4CHぜんぶつかうような場面で非常に使いやすいです。
あと願わくばケーブルも細く引き回しやすくなってくれるとありがたいですね。
きわめて高価なTektroのケーブルはすごい細くて柔らかく、そのあたりに値段差が
出てきているのかなと感じました…が普通に使う分にはTX6550でも十分恩恵は
得られるとおもいます！

ちなみにTEXAS製のプローブはKeySight等のれっきとした測定器メーカで使用されて
いる純正プローブのOEMとなってます。、N2890AはTX6250に、N2873Aは
TX6550Aに形状が酷似していることからわかりますね。

ねむいさん的には5.0mm版限定のおまけでつけてくれたPA001という高速信号用
アダプタがちょっとうれしかったです。ピンヘッダから出てる信号を確実に
計測するのにすごく役立ちます！！

てわけでますます使いやすくなった測定器環境ですが持ち腐れさせずに
バンバン使い倒していきたいと思います！！そうだね宣伝だね。

●arm-gcc定期更新
ARM預かりになって以来すっかり更新頻度が減ったarm-gccですがいつのまにか
更新していたので比較してみました。
主な変更点ですがGCC10.2.1->GCC10.3.1に代わりました

新

arm-none-eabi-gcc (GNU Arm Embedded Toolchain 10.3-2021.10) 10.3.1 20210824 (release)

Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 766928	      0	 766928	  bb3d0	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

 764276	   2652	2383304	3150232	 301198	main.elf

main.elf  :

section               size         addr

.text              0xba7f0    0x8000000

.ctors                 0x0    0x80ba7f0

.dtors                 0x0    0x80ba7f0

.ARM.exidx             0x8    0x80ba7f0

.itcm                0x17c          0x0

.data                0xa5c   0x24000000

.bss               0x11c40   0x24000a60

.heap                  0x0   0x240126a0

.dtcm                0x20c   0x20000000

.stack                 0x4   0x2000020c

.ram1_d2               0x0   0x30000000

.ram2_d2               0x0   0x30020000

.ram3_d2               0x0   0x30040000

.ram4_d3               0x0   0x38000000

.batram                0x0   0x38800000

.extram           0x233f78   0xd0000000

.qspirom               0x0   0x90000000

.comment              0x49          0x0

.debug_aranges      0x4d18          0x0

.debug_info       0x1185fe          0x0

.debug_abbrev      0x18d28          0x0

.debug_line        0xb861e          0x0

.debug_frame       0x13690          0x0

.debug_str         0x1bc6b          0x0

.debug_loc        0x147070          0x0

.ARM.attributes       0x32          0x0

.debug_ranges      0x1cd48          0x0

Total             0x682922

旧

arm-none-eabi-gcc (GNU Arm Embedded Toolchain 10-2020-q4-major) 10.2.1 20201103 (release)

Built Informations:

USING_SYSTEM = BARE_METAL

USING_DISPLAY = USE_OTM8009A_DSI_TFT

USING_DEVBOARD = USE_STM32H747I_DISCO



Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 767104	      0	 767104	  bb480	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

 764452	   2652	2383304	3150408	 301248	main.elf

main.elf  :

section               size         addr

.text              0xba8a0    0x8000000

.ctors                 0x0    0x80ba8a0

.dtors                 0x0    0x80ba8a0

.ARM.exidx             0x8    0x80ba8a0

.itcm                0x17c          0x0

.data                0xa5c   0x24000000

.bss               0x11c40   0x24000a60

.heap                  0x0   0x240126a0

.dtcm                0x20c   0x20000000

.stack                 0x4   0x2000020c

.ram1_d2               0x0   0x30000000

.ram2_d2               0x0   0x30020000

.ram3_d2               0x0   0x30040000

.ram4_d3               0x0   0x38000000

.batram                0x0   0x38800000

.extram           0x233f78   0xd0000000

.qspirom               0x0   0x90000000

.comment              0x4d          0x0

.debug_aranges      0x4d18          0x0

.debug_info       0x118608          0x0

.debug_abbrev      0x18d28          0x0

.debug_line        0xb86c1          0x0

.debug_frame       0x1367c          0x0

.debug_str         0x1bc6b          0x0

.debug_loc        0x14786a          0x0

.ARM.attributes       0x32          0x0

.debug_ranges      0x1cdd8          0x0

Total             0x6832f9

同条件ではバイナリサイズが767104->766928とスリムになってますね
速度のほうもおいおい試してみます。

●avr-gccも上がった
avr-gccは有志の方が常に最新ビルドしてくださっており非常にありがたい存在
となっております。サポートデバイスに関してはこちらのエントリで紹介している
方法で新デバイスでも対応可能です。

新

avr-gcc (GCC) 11.1.0

Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 125546	      0	 125546	  1ea6a	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

 125406	    140	   5903	 131449	  20179	main.elf

main.elf  :

section                       size       addr

.text                      0x1e9de        0x0

.data                         0x8c   0x802000

.bss                        0x170f   0x80208c

.comment                      0x12        0x0

.note.gnu.avr.deviceinfo      0x40        0x0

.debug_aranges               0xa60        0x0

.debug_info                0x285c5        0x0

.debug_abbrev               0x68ff        0x0

.debug_line                0x31c89        0x0

.debug_frame                0x1ea8        0x0

.debug_str                  0x66d1        0x0

.debug_loc                 0x1f9f9        0x0

.debug_ranges               0x1ab0        0x0

.debug_line_str               0x2a        0x0

Total                      0xab1c4

旧

avr-gcc (GCC) 10.1.0

Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 125628	      0	 125628	  1eabc	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

 125488	    140	   5903	 131531	  201cb	main.elf

main.elf  :

section                       size       addr

.text                      0x1ea30        0x0

.data                         0x8c   0x802000

.bss                        0x170f   0x80208c

.comment                      0x12        0x0

.note.gnu.avr.deviceinfo      0x40        0x0

.debug_aranges               0xa60        0x0

.debug_info                0x27c29        0x0

.debug_abbrev               0x6758        0x0

.debug_line                0x3295d        0x0

.debug_frame                0x1ef0        0x0

.debug_str                  0x66e6        0x0

.debug_loc                 0x1f5e0        0x0

.debug_ranges               0x1aa0        0x0

Total                      0xaafb1

バイナリサイズが125628->125546に減ってる！やったー！

一時期は黒歴史にまで落ちたAVRですが私の中で再び復活してきたのでこれからも
STM32の弟分の位置付けて使っていこうと思います！！

というところで2021年最後の記事となります。
来年もこんな感じでぼちぼちと続けていきますのでよろしくお願いいたします！

>ところでねむいさん昔のブログ記事の画像
->そ、それでは皆様よいお年を！！１１！！！！

STM32G0使ってみる4 -1wireデバイスをいろいろ使ってみる-

さて、珍しく飽きずに続いているSTM32G0シリーズですが今回は1wireデバイスを
使っていこうと思います。前々回の回路図より1wire用にGPIOポートを一つ開けており、
こいつをフルに活用します。

●DS18B20

金属ケースに入って見えませんが1wireデバイスの代名詞というべきデジタル
温度センサDS18B20です。いろんなマイコンで数多くの作例があり大人気のICです。

基本はVcc,Data,Gndの3線式ですが、ストロングプルアップを行いData線の電力
だけで動かす2線式の動作方式もあります。今回はお手軽に3線式で動かします。

私のSTM32G0のプロジェクトではすでに動作するようになっております。
DS18X20の#defineを有効にしてください。

動かし方はネット上に大量に作例がありますのでそちらに任せるとしてとりあえず
動作させたところです。今回は一つしかつけていませんがDS18B20はROM内に
固有IDがあり、同一のバス上に複数のDS18B20を接続することができます。

さて動作時のデータの波形を記録してみました。
固有IDを指定して温度を取得しているところです(CRC計算は実装してない頃のです)。
Picoscope5444DはDS18x20用のプロトコルアナライザ機能があり、どのような
状態かが一目でわかるので大変便利です！そうだね宣伝だね。

●Aosong製のDHT系の温湿度センサたち

DHT11から始まり今ではAHT20(これはI2C)まで進化しているAosung系の温湿度
センサモジュールが今回はその中でAM2303とAM2322を紹介します。

AM2303はDHT11よりも値段は高いですが性能が良い1-wireのモジュールです。
DS18B20とは互換性はなく独自のプロトコルでデータのやり取りを行います。

AM2322BはAM2303が一まわり小さくなったAM2322にプラスティックのケースで
覆われ、機器に取り付けてすぐに使用可能なモジュールとなっています。
こちらはI2CとDHT系の1wireと2通りのインターフェースを選ぶことができます。
SCLをGNDに落とした状態で電源を投入すると1wireモードになります。
動かし方についてはAM2303と同一になりますがI2cモードで動かすと逆に煩雑に
なってしまうので1wireモードのほうがめっぽう使いやすいです。

てわけでサクッと動かしてみました。ちゃんと検証はしていませんが温度や
湿度の精度もそこそこありそうで実用に足りると思います。

…が…

●AM2322の通信間隔の注意

↑SamplingPeriodが最小2Secだから2秒ごとにアクセスできる！と思い込み2秒ごとに
AM2322と通信して温湿度表示とかやると突然得られるデータがめちゃくちゃになり
しまいには何やってもデータを返さずへそを曲げで黙り込んでしまいます！！！！

AM2303ではこの変な現象にならないのでAM2322(さらにAM2322Bも)
固有の特性だと思います。
RockSolidHead Oyaji様の"AM2322を使ってみた　その3 "の記事にて私が
遭遇したものと酷似した現象に遭遇しております。
I2Cで動作させても同じ感じですね。

先のブログの方はI2Cで動作させており、AM2322がへそ曲げたらAM2322の
電源を一旦落とす荒業で対応しております。ねむいさんは何秒間隔開けたら
へそ曲げないか検証してみました。

条件
　・電源は+3.3V
　・2秒から0.5秒刻みで間隔を広げていきへそ曲げないところを見つけます。
　
結果
　2.0Sec :即死
　2.5Sec :即死
　3.0Sec :即死
　3.5Sec :3分ほどおいてたら死んだ。1時間以上大丈夫なこともあり不安定。
　4.0Sec :1週間連続通電動作させても問題なし。
　4.5Sec :1週間連続通電動作させても問題なし。
　5.0Sec :1週間連続通電動作させても問題なし。

う～～んたぶん個体差のばらつきがあるから5Sec以上間隔開けるようにしましょ

ちなみにAM2322のセンサ素子そのものの反応時間は結構遅いです。

湿度は8Secあります。

温度に至っては最大30Secですって！
5Sec間隔どころか1分でもいいんじゃないかしら…

ちなみにt63%というのは1-exp(-t/τ)で示される一次遅れのシステムにおいて
tのタイミングで0->1のステップ入力を加えたときにtがτの時 1-exp(-1)≒0.6321...
話を戻すとこのセンサでは時定数τは温湿度変化が起こった時変化量の63.2%に
達する時間という意味となります。

すみませんこういう重要なこと今までちゃんと見ないまま動作させていましたが、
このt63%が小さいほど反応性がよいセンサということになりますね。これからは
新手のセンサが現れたら精度や確度だけでなく反応性にも焦点を向けてみます！

いろいろ試す48

●最近のOpenOCD更新事情
今年の2月に即効飽きて罪基板になってしまったRaspiPico。
こちらは複数コアを持つCortex-M0+のMCUを搭載しているわけですが、OpenOCDで
使う為にはSWDマルチドロップに対応しないといけません。

現状ではまだRaspiPico専用のOpenOCDを使用することになりますが、OpenOCDの
gerritにはマルチドロップのパッチが上がっており検証が繰り返されております。
なんかもうそろそろmergedになりそうな雰囲気ですので首を長くして待つことに
しましょう。それとねむいさんとこのOpenOCDバイナリは本家とESP32とRaspiPico
の3つに分裂してしまっているのですべて統合してすっきりさせたいものです。

●モノがない…
・半導体製品がない
皆様ご存じの通り、コロナショック以来半導体需要が異常に増加しており半導体
特にマイコンの納期がやたらと延びています。
ねむいさんのところも打撃を受けていて旧三菱系ルネサスマイコンの納期が来年とか
言われてしまい必死になって流通在庫をかき集め何とか糊口をしのいでいる次第です。
STM32とかのCortex-M系ARMマイコンももちろん波及しており品切れになったり納期
延長とかになっていると商社の方に話を聞きました。
電脳おじ様のブログにおいてSTM32の枯渇問題について深く言及されており非常に
参考になりました。

来年になったら状況変わるかも？って楽観的に構えてましたが…

・マテリアルがない
ないわけじゃないんですけどなんかすごい値段が跳ね上がっているのです。
特に銅。先物チャート見ていただければわかりますがこちらもコロナショックを
皮切りに2021年7月末現在も超爆上げしており実物も糞みたいに上がっています。
で、銅の値段が上がると影響するのが電線です！特に太い電線の価格がころっころ
変わっている！もう勘弁してくだち！１１１！！！
そして電線の値段が上がるということは…

・ナイロンもないろん
す　み　ま　せ　ん
ワイヤハーネスとか基板接続用コネクタでよく使用される66ナイロンとかが
ないろんとのことです…
こちらについてはころすけさまのコネクタ納期遅れについてのブログ記事解説に
詳しいです…ちなみにコネクタだけじゃなくってリレーやスイッチとかの機構
がある電子部品やはたまたプラスティックのカバーがあるメカパーツすら納期
が遅れているそうでしかも上にあげた通り金属系も値段上がっているのでプライス
ツインターボ上げ状態で最終製品はマルチプルターボ上げになり我々の給与に
マイナスに作用するといたるがしんじゃうルナ先生理論となっております。
なお最終製品の納期はマルチプルターボにならなくてそのぶんだけねむいさんの
休日が減ります。

そんなわけでワイヤハーネスの制作費用も値段が上がってしまったので自分で
ハーネス打つ機会がなんか増えた気がします…
ころすけ様は2022年まで半導体不足が落ち着かないと予想されておりますが
各企業がパニックになって過剰に抱えた在庫が何年かたって秋月とかに大量に放出
されるんじゃないかなと私も思ってます。特にルネサス。

●FatFsのディレクトリ破壊問題を追う
ねむいさんじつは数年越しでだらだら調査している問題があります。
内容は"FatFsでファイルコピーしたらディレクトリが破壊される"という内容で
下記の条件で起こります。
・128MByteのMMCv3カード
・FAT16でフォーマット(FatFs・Windowsでフォーマットしても同じ結果)
・512Byte以上のファイルをコピーすると発生。それ以下では壊れない。
・SPI互換モード/ネイティブモードの両方で発生する。
・気づいたのは2019年の夏。R0.13から最新のR0.14bまで発生確認済み。

CQ誌のMB618T付録基板のSPIで試したときはこんな感じにです
コピーしたらぐっちゃぐちゃ。

2014年ごろのMB618T向けのプログラム引っ張り出してきても同じ。

STM32H7のSDMMC使ったいつものでも同じ結果に…

FatFs module test terminal for STM32H747XIH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Jul 30 2021

>fs



FAT type = FAT16

Bytes/Cluster = 16384

Number of FATs = 1

Root DIR entries = 512

Sectors/FAT = 32

Number of clusters = 7836

Volume start (lba) = 63

FAT start (lba) = 64

DIR start (lba,clustor) = 96

Data start (lba) = 128



Volume name is 128MB

Volume S/N is 4F45-2E91

...

1 files, 558702 bytes.

125376 folders.

124816 KiB total disk space.

96 KiB available.

>fl



----A2020/09/13 22:02    558702  2613.jpg

   1 File(s),    558702 bytes total

   0 Dir(s),  127811584 bytes free

>fx 2613.jpg 1713.jpg



Opening "2613.jpg"

Creating "1713.jpg"

Copying file...

524288 bytes copied at 772 kB/sec.



>fl



DR-SA2019/10/01 11:22    524288  ｳｷｺﾃｱ,;ﾕ.eｿｩ

D-H-A2056/06/21 03:38 140824249  ﾏﾉｴ鹵}.､zE

-RHS-2041/09/15 12:51 3292342498  ｲyｬｫ.ﾓ｡

-R-SA2046/06/09 14:32 4013330094  Eｯ・.ﾈｿ

--HS-2026/08/05 29:30 2671303503  g6ｩﾆ=jﾟ.3

--HSA1991/04/24 14:63 1051517575  yﾞj赧ﾔ｡・

DR---2062/02/16 30:21 2454358133  ・xv!ｳﾘﾝ.｣O･

-R-SA2032/15/27 22:61 1018623284  @・・ｾ・.ﾇW

DR--A2029/04/07 13:40 2681369147  ｦn・ﾆq;ｷ.ｰm

D---A2026/14/27 19:29 2945400368  ｷkﾋ[n>xk.・

-RH-A2068/15/21 07:47 1796965267  }ｲｮｿc_ｲｺ.

DRH-A2015/11/05 09:00 3404787036  &Kvﾋﾝ・.	

-R-SA1993/03/19 20:14 1157293741  ﾀｶ8ﾕ・.ﾄﾓm

D-HS-1980/00/00 00:00         0  :u鈎4_ro.z盧

   7 File(s),2116474074 bytes total

   7 Dir(s),  127287296 bytes free

>fm 0 1 16384



The volume will be formatted. Are you sure? (Y/n)=Y



rc=0 FR_OK

>

ううむよくわからない。
フォーマットとかはちゃんとできるしSTM32F7とかのマスストレージのサンプル
つかってWindows上でコピーは全く問題なしだからローレベルの書き込み操作は
問題ないみたいです。

ていうか今日び128GBのSDの時代なのに128MBの1bitモードしかないMMCとかに
こだわるなよって言われそうですがやっぱ気になっちゃいます。

↑とは関係ないですがGCCバージョンアップにともなうビルド時のワーニング
　発生の問題はR0.14aで修正されておりました。ありがとうございます。

2021.07.30 Friday
23:12
ネムイ・トリノミアス
MISC
-
-

AVR128DA/DBシリーズとかATMega4809とか使ってみる

●買ったはいいものの肥やしになりそうなのでやるなら今しかねぇ…

昨年末に正統進化系のAVR128DAシリーズを入手しましたがようやくいじる
機会が出来たので紹介します。

AVR128DA48 Curiosity Nanoというキットで購入しました。
値段は2000円ちょっとです。

AVR DA/DBファミリーに位置付けられるこの品種はなんと動作電圧1.8V~5.5Vの
範囲で24MHz駆動を保証しておりUARTとかも待望のボーレート生成用分数割り算器
なんかも装備しておりなにより過去の品種と比べてもはるかに安価であるという
超進化を遂げております。

が、フラッシュメモリアクセス(後述します)とI/Oのトレラントは従来のまま
なのでもうちょっとがむばってほしいですね。

なお今回のブログ記事作成に当たり下記先達のサイトを参考にさせていただきました。
みなぎ様
 なんでも独り言様
 KemushiComputer様

●最初に立ちはだかるUPDI難民問題
そしてフラッシュの書き込み方式はAVR-0/1系と同じくUPDIというプロトコルに
従って書き込みを行います。これ実態は半二重のUARTなのですがLUFAとか
簡単に対応ができるんじゃないのと思っていたのですがXMEGAのPDIとも勝手が
違うらしく、従来の自作系ライタとは相性が悪くて実装例はあまりなくて
普及が進まない状態となっていると感じております。

でその中でとれる方法は大きく分けて4つ
①観念してATMELICE/PICKITを買ってMicrochipの開発環境から読み書きする
②安価な評価ボード(XPlained/Curiosity)のファームを書き換えてUPDI専用にする
③jtag2updiで専用のavrdudeで書き込む
④実態は半二重UARTなので仮想COMでせこせこ自作する(pyUPDIとかも一例)

ねむいさんは値段対費用効果が高いと思われる②の方法をとりました。ATTINY202の
時にATTINY104XplainedをUPDIプログラマ化してAvrdudeで書き込んでいます。
④の仮想COM使う方法でavrdudeが対応するのが最良なのですが
　首を長くして待ってます。
みなぎ氏のサイトではそれに近いことにちゃれんぢされているようで
　すごく期待してます☆
ぁ、なんかいつの間にか~~薄い本~~同人のネタにしますって書き換わってる・・・・
20230927追:
avrdudeがserialUPDIに対応しました！！

avrdudeは現状はAVR128DA/DBなどの128kbフラッシュを持つ品種に対応して
おらず、パッチを充てる必要があります。ちなみにCuriosityNanoにも
対応してくれてすごく助かります♥

avrdudeを使って書いてみたところはこんな感じになります

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

C:/Devz/AVR/avrdude/avrdude -v -p avr128da48 -P usb -c pkobn_updi    -U flash:w:main.hex 



avrdude: Version 6.3-20171130

         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

         Copyright (c) 2007-2014 Joerg Wunsch



         System wide configuration file is "C:¥Devz¥AVR¥avrdude¥avrdude.conf"



         Using Port                    : usb

         Using Programmer              : pkobn_updi

avrdude: Found CMSIS-DAP compliant device, using EDBG protocol

         AVR Part                      : AVR128DA48

         Chip Erase delay              : 0 us

         PAGEL                         : P00

         BS2                           : P00

         RESET disposition             : dedicated

         RETRY pulse                   : SCK

         serial program mode           : yes

         parallel program mode         : yes

         Timeout                       : 0

         StabDelay                     : 0

         CmdexeDelay                   : 0

         SyncLoops                     : 0

         ByteDelay                     : 0

         PollIndex                     : 0

         PollValue                     : 0x00

         Memory Detail                 :



                                  Block Poll               Page                       Polled

           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack

           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------

           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

           prodsig        0     0     0    0 no        125  125      0     0     0 0x00 0x00

           fuses          0     0     0    0 no          9   16      0     0     0 0x00 0x00

           fuse0          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           fuse1          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           fuse2          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           fuse4          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           fuse5          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           fuse6          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           fuse7          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           fuse8          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           lock           0     0     0    0 no          4    1      0     0     0 0x00 0x00

           data           0     0     0    0 no          0    0      0     0     0 0x00 0x00

           flash          0     0     0    0 no     131072  512      0     0     0 0x00 0x00

           eeprom         0     0     0    0 no        512    1      0     0     0 0x00 0x00



         Programmer Type : JTAGICE3_UPDI

         Description     : PKOB nano (nEDBG) in UPDI mode

         ICE hardware version: 0

         ICE firmware version: 1.17 (rel. 514)

         Serial number   : MCHP3280031800001375

         Vtarget         : 3.31 V

         JTAG clock megaAVR/program: 0 kHz

         JTAG clock megaAVR/debug:   0 kHz

         JTAG clock Xmega: 0 kHz

         PDI clock Xmega : 100 kHz



avrdude: Partial Family_ID returned: "    "

avrdude: AVR device initialized and ready to accept instructions



Reading | ################################################## | 100% 0.00s



avrdude: Device signature = 0x1e9708 (probably avr128da48)

avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed

         To disable this feature, specify the -D option.

avrdude: erasing chip

avrdude: reading input file "main.hex"

avrdude: input file main.hex auto detected as Intel Hex

avrdude: writing flash (2462 bytes):



Writing | ################################################## | 100% 0.79s



avrdude: 2462 bytes of flash written

avrdude: verifying flash memory against main.hex:

avrdude: load data flash data from input file main.hex:

avrdude: input file main.hex auto detected as Intel Hex

avrdude: input file main.hex contains 2462 bytes

avrdude: reading on-chip flash data:



Reading | ################################################## | 100% 0.44s



avrdude: verifying ...

avrdude: 2462 bytes of flash verified



avrdude done.  Thank you.





> Process Exit Code: 0

> Time Taken: 00:02

CuriosityNanoに搭載されているnEDBGはpkobn_updiと指定するようですね。
また、Xplainedの時みたいに無理やりファーム書き換えなくてもupdiがそのまま
使用可能なのもうれしいです。これで2000円ちょっとならよい買い物かも！？

●今度はAVR128DB28だ！

さて今度はキット上ではなく別の品種にも書けるか確かめてみました。
AVR128DB28です！！これもかつてのmega8系の上位互換となっていくでしょう。

と思いきやはじめはXplainedから改造したupdiプログラマから書き込み失敗して
焦りました。どうやらCuriosityNanoのファームではないとAVR128DA/DB
シリーズのフラッシュ書き込みに対応していないと考えられます。

CuriosityNanoで書いたところです。

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

C:/Devz/AVR/avrdude/avrdude -v -p avr128db28 -P usb -c pkobn_updi    -U flash:w:main.hex 



avrdude: Version 6.3-20171130

         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

         Copyright (c) 2007-2014 Joerg Wunsch



         System wide configuration file is "C:¥Devz¥AVR¥avrdude¥avrdude.conf"



         Using Port                    : usb

         Using Programmer              : pkobn_updi

avrdude: Found CMSIS-DAP compliant device, using EDBG protocol

         AVR Part                      : AVR128DB28

         Chip Erase delay              : 0 us

         PAGEL                         : P00

         BS2                           : P00

         RESET disposition             : dedicated

         RETRY pulse                   : SCK

         serial program mode           : yes

         parallel program mode         : yes

         Timeout                       : 0

         StabDelay                     : 0

         CmdexeDelay                   : 0

         SyncLoops                     : 0

         ByteDelay                     : 0

         PollIndex                     : 0

         PollValue                     : 0x00

         Memory Detail                 :



                                  Block Poll               Page                       Polled

           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack

           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------

           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

           prodsig        0     0     0    0 no        125  125      0     0     0 0x00 0x00

           fuses          0     0     0    0 no          9   16      0     0     0 0x00 0x00

           fuse0          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           fuse1          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           fuse2          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           fuse4          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           fuse5          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           fuse6          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           fuse7          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           fuse8          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           lock           0     0     0    0 no          4    1      0     0     0 0x00 0x00

           data           0     0     0    0 no          0    0      0     0     0 0x00 0x00

           flash          0     0     0    0 no     131072  512      0     0     0 0x00 0x00

           eeprom         0     0     0    0 no        512    1      0     0     0 0x00 0x00



         Programmer Type : JTAGICE3_UPDI

         Description     : PKOB nano (nEDBG) in UPDI mode

         ICE hardware version: 0

         ICE firmware version: 1.17 (rel. 514)

         Serial number   : MCHP3280031800001375

         Vtarget         : 3.31 V

         JTAG clock megaAVR/program: 0 kHz

         JTAG clock megaAVR/debug:   0 kHz

         JTAG clock Xmega: 0 kHz

         PDI clock Xmega : 100 kHz



avrdude: Partial Family_ID returned: "AVR "

avrdude: AVR device initialized and ready to accept instructions



Reading | ################################################## | 100% 0.00s



avrdude: Device signature = 0x1e970e (probably avr128db28)

avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed

         To disable this feature, specify the -D option.

avrdude: erasing chip

avrdude: reading input file "main.hex"

avrdude: input file main.hex auto detected as Intel Hex

avrdude: writing flash (2398 bytes):



Writing | ################################################## | 100% 0.79s



avrdude: 2398 bytes of flash written

avrdude: verifying flash memory against main.hex:

avrdude: load data flash data from input file main.hex:

avrdude: input file main.hex auto detected as Intel Hex

avrdude: input file main.hex contains 2398 bytes

avrdude: reading on-chip flash data:



Reading | ################################################## | 100% 0.43s



avrdude: verifying ...

avrdude: 2398 bytes of flash verified



avrdude done.  Thank you.





> Process Exit Code: 0

> Time Taken: 00:02

●最後にATMega4809を試す

こちらは3月くらいに秋月さんから販売されだしたmegaAVR-0シリーズの
品種になります。AVRDA/DBと比べると1世代前の品種になります。
こちらもフラッシュ書き込みはUPDIとなっています。

とりあえずCuriosityNanoで書いてみる

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

C:/Devz/AVR/avrdude/avrdude -v -p atmega4809 -P usb -c pkobn_updi    -U flash:w:main.hex 



avrdude: Version 6.3-20171130

         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

         Copyright (c) 2007-2014 Joerg Wunsch



         System wide configuration file is "C:¥Devz¥AVR¥avrdude¥avrdude.conf"



         Using Port                    : usb

         Using Programmer              : pkobn_updi

avrdude: Found CMSIS-DAP compliant device, using EDBG protocol

         AVR Part                      : ATmega4809

         Chip Erase delay              : 0 us

         PAGEL                         : P00

         BS2                           : P00

         RESET disposition             : dedicated

         RETRY pulse                   : SCK

         serial program mode           : yes

         parallel program mode         : yes

         Timeout                       : 0

         StabDelay                     : 0

         CmdexeDelay                   : 0

         SyncLoops                     : 0

         ByteDelay                     : 0

         PollIndex                     : 0

         PollValue                     : 0x00

         Memory Detail                 :



                                  Block Poll               Page                       Polled

           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack

           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------

           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

           prodsig        0     0     0    0 no         61   61      0     0     0 0x00 0x00

           fuses          0     0     0    0 no          9   10      0     0     0 0x00 0x00

           fuse0          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           fuse1          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           fuse2          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           fuse4          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           fuse5          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           fuse6          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           fuse7          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           fuse8          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           lock           0     0     0    0 no          1    0      0     0     0 0x00 0x00

           data           0     0     0    0 no          0    0      0     0     0 0x00 0x00

           usersig        0     0     0    0 no         64   64      0     0     0 0x00 0x00

           flash          0     0     0    0 no      49152  128      0     0     0 0x00 0x00

           eeprom         0     0     0    0 no        256   64      0     0     0 0x00 0x00



         Programmer Type : JTAGICE3_UPDI

         Description     : PKOB nano (nEDBG) in UPDI mode

         ICE hardware version: 0

         ICE firmware version: 1.17 (rel. 514)

         Serial number   : MCHP3280031800001375

         Vtarget         : 3.31 V

         JTAG clock megaAVR/program: 0 kHz

         JTAG clock megaAVR/debug:   0 kHz

         JTAG clock Xmega: 0 kHz

         PDI clock Xmega : 100 kHz



avrdude: Partial Family_ID returned: "mega"

avrdude: AVR device initialized and ready to accept instructions



Reading | ################################################## | 100% 0.07s



avrdude: Device signature = 0x1e9651 (probably m4809)

avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed

         To disable this feature, specify the -D option.

avrdude: erasing chip

avrdude: reading input file "main.hex"

avrdude: input file main.hex auto detected as Intel Hex

avrdude: writing flash (5344 bytes):



Writing | ################################################## | 100% 2.07s



avrdude: 5344 bytes of flash written

avrdude: verifying flash memory against main.hex:

avrdude: load data flash data from input file main.hex:

avrdude: input file main.hex auto detected as Intel Hex

avrdude: input file main.hex contains 5344 bytes

avrdude: reading on-chip flash data:



Reading | ################################################## | 100% 1.02s



avrdude: verifying ...

avrdude: 5344 bytes of flash verified



avrdude done.  Thank you.





> Process Exit Code: 0

> Time Taken: 00:03

最後にファーム入れ替えたXplainedから。えらいにぎやかになりました。
ATmga4809はXplainedでも書けます。

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

C:/Devz/AVR/avrdude/avrdude -v -p atmega4809 -P usb -c xplainedmini_updi    -U flash:w:main.hex 



avrdude: Version 6.3-20171130

         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

         Copyright (c) 2007-2014 Joerg Wunsch



         System wide configuration file is "C:¥Devz¥AVR¥avrdude¥avrdude.conf"



         Using Port                    : usb

         Using Programmer              : xplainedmini_updi

avrdude: Found CMSIS-DAP compliant device, using EDBG protocol

         AVR Part                      : ATmega4809

         Chip Erase delay              : 0 us

         PAGEL                         : P00

         BS2                           : P00

         RESET disposition             : dedicated

         RETRY pulse                   : SCK

         serial program mode           : yes

         parallel program mode         : yes

         Timeout                       : 0

         StabDelay                     : 0

         CmdexeDelay                   : 0

         SyncLoops                     : 0

         ByteDelay                     : 0

         PollIndex                     : 0

         PollValue                     : 0x00

         Memory Detail                 :



                                  Block Poll               Page                       Polled

           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack

           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------

           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

           prodsig        0     0     0    0 no         61   61      0     0     0 0x00 0x00

           fuses          0     0     0    0 no          9   10      0     0     0 0x00 0x00

           fuse0          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           fuse1          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           fuse2          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           fuse4          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           fuse5          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           fuse6          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           fuse7          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           fuse8          0     0     0    0 no          1    0      0     0     0 0x00 0x00

           lock           0     0     0    0 no          1    0      0     0     0 0x00 0x00

           data           0     0     0    0 no          0    0      0     0     0 0x00 0x00

           usersig        0     0     0    0 no         64   64      0     0     0 0x00 0x00

           flash          0     0     0    0 no      49152  128      0     0     0 0x00 0x00

           eeprom         0     0     0    0 no        256   64      0     0     0 0x00 0x00



         Programmer Type : JTAGICE3_UPDI

         Description     : Atmel AVR XplainedMini in UPDI mode

         ICE hardware version: 0

         ICE firmware version: 1.13 (rel. 43)

         Serial number   : ATML2678020200007560

         Vtarget         : 5.00 V

         JTAG clock megaAVR/program: 0 kHz

         JTAG clock megaAVR/debug:   0 kHz

         JTAG clock Xmega: 0 kHz

         PDI clock Xmega : 0 kHz



avrdude: Partial Family_ID returned: "mega"

avrdude: AVR device initialized and ready to accept instructions



Reading | ################################################## | 100% 0.09s



avrdude: Device signature = 0x1e9651 (probably m4809)

avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed

         To disable this feature, specify the -D option.

avrdude: erasing chip

avrdude: reading input file "main.hex"

avrdude: input file main.hex auto detected as Intel Hex

avrdude: writing flash (5344 bytes):



Writing | ################################################## | 100% 1.72s



avrdude: 5344 bytes of flash written

avrdude: verifying flash memory against main.hex:

avrdude: load data flash data from input file main.hex:

avrdude: input file main.hex auto detected as Intel Hex

avrdude: input file main.hex contains 5344 bytes

avrdude: reading on-chip flash data:



Reading | ################################################## | 100% 1.38s



avrdude: verifying ...

avrdude: 5344 bytes of flash verified



avrdude done.  Thank you.





> Process Exit Code: 0

> Time Taken: 00:04

こんな感じで市販のライタをそのまま流用もしくはファームだけ入れ替え
というアマチュアリズムに反する行為になってしまいましたが2000円
ちょっと出して電圧変換機能付きのUPDIプログラマ買えるのならもうこれで
いいかなと思いまし、た！

●残る問題、フラッシュ領域のアクセスはどうなった？
そういえばMicrochip体制のtinyAVRからフラッシュ領域のアドレスが
データ領域のアドレスに変換され割り振られ、PROGMEMを使わなくても
一般的なC言語のconstのように定義したら自動的にコンパイラが割り当てて
くれるようになってくれるはずですが実際にアセンブルリストと照らし
合わせてみてみましょう。

まずATMega1284p
main.cのグローバルにconst charの文字列リテラルをPROGMEMとか使わず
定義した場合、フラッシュではなくデータ領域のアドレス(0x800000以降)
として配置されます。この状態だとコンパイラがmain関数開始前に
フラッシュメモリからデータ領域のSRAMの該当アドレスに配置するルーチンを
実行しSRAMを大幅に浪費してしまいます。

続いてATMega4809の場合もデータ領域のアドレスに配置されるようになりますが、
このアドレスはLPMなどのフラッシュアドレスアクセス用の命令は必要がなく
普通のSRAMのように読み出しができるため、main関数開始前にフラッシュから
SRAMに読み出すようなルーチンは実行されません。

AVR128DA/DBは御覧の通り従来のAVRと同じになってしまいます。実は
ATmega4809と違って制約があり、データ領域は64KB以内のアドレスしか
参照できないためさらにI/Oの分も差っ引かれて実際には最大4832kByte分しか
参照できないことからくると考えられます。
まぁこれAVRのアーキテクチャーの宿命なので仕方がないのですけど128kByte分
フルに参照せしめるためには10年前にねむいさんが行っためんどい手法をもってして
やらないといけません！。
※みなぎ氏の調査によるとAVR32DAxxとか32kByteのROM容量の品種では
　4809と同じくPROGMEMの考慮が必要なくなるそうです。
2023927追:
AVR-Dxシリーズでいろいろ試してみました！！

20240229追:
秋月さんよりAVR128DB28が販売されました！！！！！！

2021.05.31 Monday
23:24
ネムイ・トリノミアス
AVR
-
-

いろいろ試す47

●紫…本当に紫

やったZE！キャプ翼のけぉカードゲッツ！！！

…じゃなくてSandiskを喰ったWesternDigital社が監視カメラ用にリリースした
高耐久microSDカード"WD Purple QD101"をやっとこ入手しました！！！！
128GB品のWDD128G1P0Cの型番の製品です！

Sandiskはブランド名は残ってはいますが産業用/工業用はどんどんWDへと切り
替わってる感じですね～これは一般向けですが。
なお、現在はさらに高性能なQD312なるシリーズも出ているようですが値段がまだ
高すぎるのでまた今度の機会にします…

まずはいつものべんちです。
･･･うーｎ…トランセンドのあれが強すぎて霞んじゃいますね…
※宣伝ではない

おつぎはSTM32H7のいつものでハードウエア情報を読み出します

FatFs module test terminal for STM32H747XIH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Mar 19 2021

>fg piano



rc=0 FR_OK

>fo 1 ftbt.mp3



rc=0 FR_OK

>fr 132949600



132949600 bytes read at 16964 kB/sec.

>fs



FAT type = exFAT

Bytes/Cluster = 131072

Number of FATs = 1

Root DIR entries = 0

Sectors/FAT = 16384

Number of clusters = 975280

Volume start (lba) = 32768

FAT start (lba) = 49152

DIR start (lba,clustor) = 4

Data start (lba) = 65536



Volume name is WDD128G1P0C

Volume S/N is E240-C6DE

...

1 files, 132949600 bytes.

124835840 folders.

124705024 KiB total disk space.

4 KiB available.

>ds 0



rc=0

Drive size: 249737216 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 DB 79 00 03 B8 AB 7F 80 0A 40 40 5F  @..2.y.......@@_

CID:

00000000  03 53 44 57 58 31 32 38 80 57 E3 8D AF 01 4C 29  .SDWX128.W....L)



Parsing SD CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :WX128

Product HwRev      :8

Product SwRev      :0

Serial Number      :0x57E38DAF

DateCode.Month     :12

DateCode.Year      :2020



OCR:

00000000  C1 FF 80 00  ....

SD Status:

00000000  80 00 00 00 08 00 00 00 04 00 90 00 0F 05 19 0A  ................

00000010  00 08 00 00 00 02 FC 00 03 00 00 00 00 00 00 00  ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

SCR:

00000000  02 45 84 87 00 00 00 00  .E......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Spec Version X  :2

SD Security        :4

SD Bus Width       :5



SD_Spec V6.xx!

Detected as SDXC Card!

Available UHS-I Mode.

Available UHS Speed Class U1.

Available SD Speed Class 10.

Available Video Speed Class 10.

Available Application Performance Class2, A2 Card.

A2 CommandQueue Depth 32 Supported

A2 Cache Supported.

>

2020年12月製ですね～。そしてManufacturerIDサンディスク(0x3)のまんまです。
A2グレードだそうですがそれ引き出せられるハードがないです…

ところでWDPurpleQD101は"スマートなストレージ管理"なるものがありそれに
対応するカメラなどで寿命判定を行うことができます。
で、具体的にそれって何といいますとCMD56によるSMART値の取得に
ほかなりません!!!

WD製のSDカードはSandiskの流れを汲むのでCMD56の引数及び得られる構造体は
Sandiskと同じ(0x00000001)で行けます！

Sandiskのころと全く同じなのでとても安心感がありますね☆
ログはこちらに置いておきます。ご参考に。

というわけで一般向けでは安価にお手軽に安定して購入できるWDPurpleを
紹介しました。これからの時代はSDカードには高耐久かつ寿命判定ができる
ものが求められます！皆様もねむいさんのぶろぐを参考にして使用環境に
最適なカードを選んでください！

●国土地理院の地図の利用規約が緩和されていた件
すでに3か月もたってしまいましたが昨年末に毎年恒例の国土地理院の地図のweb
使用許可をもらおうと申請したのですがなんと却下されてしまいました。

なんでも令和元年１２月１０日に地図の利用手続きが改正になり、個人ブログの
登山マップで国土地理院の地図を利用する…つまりねむいさんみたいな使い方
する人は緯度経度等の位置座標のない地図は申請不要となったとのことです。

これはとてもありがたいですね～☆わたしのブログではGPSの軌跡を示す時は
↓みたいな感じで地図画像右下に使用表記をしております。

●最強LDO・LT1963A+3.3V版再降臨
一時期は面実装タイプのLT1963Aの3.3V版が売ってましたが秋月さんが型番を
間違ってて不人気だったのですが、ねむいさんがセラミックコンデンサ使用可能な
A版であることを見出したとたんに速攻売り切れになってしまい長いこと経って
しまいましたが使いやすいSOT-223パッケージになって大復活しました。

デジキで買うよりかは安いですが350円もしますが値段分以上の働きをしますので
ねむいさん激推しです！！！！

●Win10で月例更新のたびに｢Windows更新プログラムを構成できませんでした変更を元に戻しています」ってなって更新に失敗しやがる問題の対処の件
一回なると以後100%失敗するやばいやつ。0x80070003のエラーが出ることが
多いですがこれで検索してもとんちんかんな回答ばっかりorz
ねむいさんも半ばあきらめてましたがやっと対処法を見つけました！！！

やり方
①更新失敗したらC:/Windows/Inf/setupapi.dev.log を開く
②"FAILURE"という文字列を検索。
③検索がヒットした箇所に記載されているフォイルやフォルダを
　C:/Windows/System32/DriverStore/FileRepository内に作成
④たいていC:/Windows/System32/DriverStore/FileRepositoryに入っている
　ドライバをクリーナーソフトとかで強引に削除したりするとこうなるorz
　
こんなんわかるか～！
でも何とかアップデートできるようになりました…

今更STM32G0はぢめました

皆様あけましておめでとうございました！！
今年は初詣期間が２か月くらいあるそうなので全然遅くはないですね(手遅れ

さて、先月さらっと紹介したSTM32G0、秋月さんのところで9月に発売されていたのを
12月にようやく手に入れ、そして今ようやく記事にしてみた次第です。

STM32もついに8pinの世界に足を踏み入れてしまいましたがコアのほうもCorte-M0
じゃなくてM0+にパワーアップしています。しかしながらメモリ容量32kb、SRAMも
8kbもあるという小さなボディに大きな力を秘めているわけです！！

メモリ構造も慣れ親しんだSTM32の伝統のアドレス配置で移植も苦ではありません！

このマイコン用のプロジェクトの作成に当たってはSTM32G0-DISCOを参考にさせて
もらっております。

しかしピン数さすがに少なすぎできついですねこれ…どうしたらいいものか…

7,8ピンはSWDで潰れる…そして6ピンはLEDに使用済み…
この小規模なマイコンでもきることはやはり一つ…！I2C！！
PA9がリマップ済みになってるようなので用検討ですね…

ひとまずLチカできるレベルのプロジェクトをF0のプロジェクトをベースに拵えて
見ました…確認用の基板もやっけつ仕事で昔のLPC810基板に乗っけました。

デバッガの接続は定番のSWDです。8PinがSWCLK,7PinがSWDIOあとは電源の配線を
すればつながります。また、購入直後のSTM32G0の接続ではnReset(4Pin)の接続は
特に不要です！(重要)将来的にnResetをGPIO化して使う際には逆に邪魔になって
しまいますので…

OpenOCDはすでにG0シリーズの多くに対応しております。ねむいさんもG0用の
フラッシュ書き込み用のcfgを作成しました。
すでにOpenOCDのバイナリに収録済みです！

まずはVersaloonで書き込みしたところです。

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

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

Open On-Chip Debugger 0.11.0-rc1+dev-00032-gbd1adcffe (2021-01-23-19:37)

Licensed under GNU GPL v2

For bug reports, read

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

Info : VSLLink SWD mode enabled

swd

Info : Versaloon(0x15)by Simon(compiled on Sep 16 2014)

Info : USB_TO_XXX abilities: 0x0000176E:0x010001EF:0xC0000007

Info : clock speed 500 kHz

Info : SWD DPIDR 0x0bc11477

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

Info : starting gdb server for stm32g0x.cpu on 3333

Info : Listening on port 3333 for gdb connections

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

xPSR: 0xf1000000 pc: 0x08000c9c msp: 0x20002000

Info : device idcode = 0x10016466 (STM32G03/G04xx - Rev Z : 0x1001)

Info : flash size = 32kbytes

Info : flash mode : single-bank

Info : Padding image section 1 at 0x08000eac with 4 bytes (bank write end alignment)

Warn : Adding extra erase range, 0x08000eb0 .. 0x08000fff

Info : wrote 3760 bytes from file main.elf in 0.188402s (19.490 KiB/s)

Info : verified 3756 bytes in 0.029309s (125.148 KiB/s)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:01

Win10ではレジスタウインドウ使えませんがInsightのデバッグもすいすい
できちゃいます。

お次はSTLink(STM32-NucleoのSTLink/V2-1)でHLAデバイスとして
書き込んでみます。

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

openocd  -s C:/Devz/ARM/OCD/tcl -f interface/stlink.cfg -c "transport select hla_swd" -f target/stm32g0x_swd_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.11.0-rc1+dev-00032-gbd1adcffe (2021-01-23-19:37)

Licensed under GNU GPL v2

For bug reports, read

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

hla_swd

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

Info : clock speed 500 kHz

Info : STLINK V2J33M25 (API v2) VID:PID 0483:3752

Info : Target voltage: 3.272439

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

Info : starting gdb server for stm32g0x.cpu on 3333

Info : Listening on port 3333 for gdb connections

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

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

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

xPSR: 0xf1000000 pc: 0x08000c9c msp: 0x20002000

Info : device idcode = 0x10016466 (STM32G03/G04xx - Rev Z : 0x1001)

Info : flash size = 32kbytes

Info : flash mode : single-bank

Info : Padding image section 1 at 0x08000eac with 4 bytes (bank write end alignment)

Warn : Adding extra erase range, 0x08000eb0 .. 0x08000fff

Info : wrote 3760 bytes from file main.elf in 0.156605s (23.447 KiB/s)

Info : verified 3756 bytes in 0.031977s (114.706 KiB/s)

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

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

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:01

こんな感じでサクッと書くこむことができます。

ということでSTM32も8bitマイコンの牙城に続々と乗り込んできたおかげで
小粒マイコンも立派にSTM32として使えるような局面が出てくると思います。

今回はLEDの点滅だけですが豊富なメモリ資源とCPUスピードを利用してI2C
デバイスの制御にちゃれんぢしてみようと思います！

注：プロジェクトはまだ作成中のためもうしばらくお待ちください。

Transcendの産業用microSDカードUSD230Iシリーズを試す

20200617追:最後のほうにSMARTツールの追記あります

だいぶ前のコメントでTranscendの産業用SDとかどう？とネタをいただいたのですが
なかなか手が伸びず放置状態となっていたのが超進展しましたのでお知らせします。

2020年現在、Transcendの産業用SD/microSDカードはamazonで一般でも購入可能
です。ねむいさんも入山料を払い、登頂を開始しました！決して企業案件ではない!!!!

今回購入したTS32GUSD230IはSLCモードを搭載した高耐久性を誇る230Iシリーズに
今春新たに8~64GBの容量が追加された最新のモデルです！

さて、工業用/産業用では高い書き込み耐久性を求められますが本製品は3D-TLC
NANDのビットセルを疑似的にSLCみたいにして使う疑似SLC方式を取っております。
なんとTBWは32GB品で1400、64GB製品では5800に及び過去に紹介したマイクロンの
microSDでは容量最大の256GB品でも180TBWだったので破格の耐久性ですね。
この耐久性を実現しているSLCモードはTranscendさんの公式ﾋで解説がありますので
皆さんもよく目を通しておいてください。

んでもって230Iシリーズで使用している3D-TLCNANDも最新の製造プロセスのBiCS4が
使用されているとのことで(今春追加された8GB以上のモデルで適用されていると
思われます)、容量速度耐久性がここまで大幅に上がったと思われます。

というわけでとにもかくにもPCからベンチマークを取ってみました。

はい、御覧の通りとんでもなく早いです。特に4kの読み書き！
マイクロン産業用
 サンディスク産業用
 キオクシア高耐久
 サンディスク超高耐久
↑と比較してもチマチマ4k読み書きがスバ抜けて早いのがわかりますね～
シーケンシャル書き込みもピカ一です用途としてはドラレコや監視カメラにすら
もったいないくらい、まさに組み込み用PCの起動イメージにするべき逸品です！

お次はいつものでSDカード内のハードウエア情報を読み出します。

●TRANSCEND Industrial Class10 UHS-I V30 U3 A1 TS32GUSD230I

FatFs module test terminal for STM32H747XIH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : May 22 2020

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read at 21046 kB/sec.

>fs

FAT type = FAT32

Bytes/Cluster = 32768

Number of FATs = 2

Root DIR entries = 0

Sectors/FAT = 7534

Number of clusters = 964256

Volume start (lba) = 8192

FAT start (lba) = 9508

DIR start (lba,clustor) = 2

Data start (lba) = 24576



Volume name is USD230I_32G

Volume S/N is BDB6-0F99

...

1 files, 132949600 bytes.

30856192 folders.

30726080 KiB total disk space.

964256 KiB available.

>ds 0

rc=0

Drive size: 61736960 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 5B 59 00 00 EB 81 7F 80 0A 40 00 C1 @..2[Y.......@..

CID:

00000000  74 4A 60 55 53 44 55 31 20 19 00 57 30 01 44 23 tJ`USDU1 ..W0.D#



Parsing SD CID Register

Manufacturer ID    :0x74

OEM/Application ID :J`

Product Name       :USDU1

Product HwRev      :2

Product SwRev      :0

Serial Number      :0x19005730

DateCode.Month     :4

DateCode.Year      :2020



OCR:

00000000  C1 FF 80 00 ....

SD Status:

00000000  80 00 00 00 05 00 00 00 04 00 90 00 08 11 39 1E ..............9.

00000010  00 08 00 00 00 01 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 84 43 00 00 00 00 .5.C....



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Spec Version X  :1

SD Security        :3

SD Bus Width       :5



SD_Spec V5.xx!

Detected as SDHC Card!

Available UHS-I Mode.

Available UHS Speed Class U3.

Available SD Speed Class 10.

Available Video Speed Class 30.

Available Application Performance Class1, A1 Card.

SDSpecは5.xxでA1クラスで各スピードクラスもそろっていますね。
しかも2020年4月の出来立てほやほやの奴です☆
Manufacturer IDの0x74はJiaElec(Transcendの製造協力会社)を示しています。
TranscendはシリアルナンバでRMAの管理をしていますがカードから読み出す上記の
シリアルナンバはそれとは別物であくまでカード表面に記載された番号でなければ
なりません。ご注意ください。

さて、こっから本番ですが230Iシリーズは当然のごとくS.M.A.R.T.(以下SMART)
が搭載されております。搭載されているから買いました！！！
そして肝心のSMART値を得るためのCMD56のアレですがなななななんと!!!!
Transcend embedded様の特別のご厚意により特別に教えていただけることに
なりました！！！！ありがとうございます！！！！

STM32H7のいつものを使ってCMD56でSMARTを読み出してみました。
肝心のCMD56の引数ですがmicronの奴に酷似しているとだけ言っておきます。
多分7月更新のいつものには反映してると思いますのでお待ちください。

何はともあれ"Transcend"のプロダクトマーカーの存在が確認され、SMARTの読み
出しが成功しているとわかります。

SMARTの目玉、カードの寿命ですがTranscendでは70バイト目に存在しています。
まだ使い始めなので100(%)ですね。
読み出したデータはこちらに。4GB以下のモデルと8GB以上のモデルでは同じ230I
シリーズでも細かいスペックやSMARTの構造体が全く違うのでご注意ください。
これからは8GB以上の奴使っていけば間違いはないでしょう。

というわけで払った対価の以上のスペックを持つこのUSD230I、大事なことなので
二回言いますがラズパイとか産業用PCなどのタフな環境で動くOSの起動イメージに
大活躍できそうですね☆

・おまけ(内容だいぶ改訂)
なんとWindowsからSMART読み出せるツールまで提供していただきました…！！
DELKINの奴みたいに特定のセクタアドレス読み出すことでSMART取得できるのか！？
と期待したのですが…

残念ながらそううまくはいかなかったorz
使用しているカードリーダーがサンワサプライの汎用のカードなのでダメなのかなと
思ってTranscendさんに聞いてみるとツールが発行するCMD56を解釈できるRDF5なら
できるとのこと。さっそく購入して試してみました。

購入費用888円が無様に爆散したorz(昔買ったRDF8でもダメだった)
TS-RDF5のファームウエアバージョンは"TS3A"ですが多分特定顧客向けの特殊ファーム
じゃないとダメっぽいですねorz
もしくはCMD56通ってたけどねむいさんが購入したTS32GUSD230Iが新しすぎてSMART
読み出せるツールで対応してなくて撥ねられちゃったか。
エラーログには"Write IO Control Fail, Error Message is:6"って記録されていました。
やはりSD SMART TOOLのバージョンが低いとのことで差し替えたら
ちゃんと動作しました。一番下参照。

当然この程度で諦めるねむいさんではない。
STM32F7DiscoveryのUSB-MSC使ってSMART読み出せるツールが投げるSCSI
コマンドを捕まえてみました。するとUSB-MSCではまず使用しない0xD1なる
コマンドが…このコマンドの構造体を掘るとCMD56で投げるべき引数が
ずらずら出てきました…
なるほどそういうことか…！やっぱカードリーダ側でこれが解釈できる
奴じゃないと🙅なんだ。

これってUSBカードリーダーじゃなくてバス直結のSDA標準準拠SDカード
ホストコントローラードライバ使うようなタイプのカードリーダーなら直に
scsiコマンド送れるからうまくいくのかしらと思ったり逆にCMD56こういう
方法でUSBマスストレージ経由で送れるなら専用のファームとソフトを
こしらえるだけでTranscendだろうがsandiskだろうがmicronだろうがWindows
からいけるやんけと思いましたがそんな手間かけるなら素直に
マイコンで読み出せば簡単やんと安きに流れるねむいさんの情けない性格を
露呈させたところで本日の記事を〆させていただきます。
かしこ。

20200616追:
Transcend Embedded様から最新ソフトもらったので試合続行１１！！！！！１１１

ｷﾀ━━━(ﾟ∀ﾟ)━━━!!(※管理者権限で実行してください)
か…勝った…！
いくつかカードリーダー試しましたがTranscend製のTS-RDF5とTS-RDF8だけが
正しくCMD56を解釈できるのがわかりました。性能はそこそこですが価格も安く
入手もしやすくTranscend製産業用SDのSMARTも読めるのでこちらもおすすめです！

いろいろ試す42

6月になるというのに10万円まだ来ないよ

●Windows10でラズパイ4の起動SDイメージをバックアップ/レストアする
意外とネット上になかったのでねむいさん流のやり方を残しておきます。

使うアプリケーション
・バックアップ
　DD for windows
　R2のほうはまだベータ版で動作しないので(ねむいさんとこもダメ)旧番の
　Ver.0.9.9.8を使用してください。
・レストア
　balenaetcher
　かつてラズパイの初期イメージ書き込み用に推奨されていたものです。
　こちらはzip圧縮したイメージも展開して書き込みができるのでディスク容量の
　節約になります。
　
・DDwinでバックアップのやり方

RaspberrypiのOSがインストールされたmicroSDをUSBカードリーダーに指して
Windows10から認識させます。ラズパイのOSイメージが仕込んであるmicroSDは
bootというラベルが付いたFAT32のパーティションと本来のラズパイのOSがある
ext4があります。Ext2fsdなどのソフトをインストールしてない限りはフォーマットを
求められてしまうのでうっかりフォーマットしないようにして無視しましょう。

DDWinを管理者モードで起動します。管理者でないとドライブを認識できません。

｢ディスク選択｣でラズパイのOSのインストールされたmicroSDカード(bootのラベルの)
ドライブを指定して｢ファイル選択｣で保存先ディレクトリとファイル名を決定して
｢>>読み込み>>｣ボタンを押すとバックアップ開始です。

DDwinはlinuxのddコマンド宜しくディスク上のデータを1セクタずつ最初から
最後まで読み取ります。そんなわけでバックアップはSDカードの容量が大きければ
大きいほど悠久の時間がかかります。
時間がかかりますが確実です。こいつで読みだしたイメージは容量さえ足りれば
どんなmicroSDにも書き出すことができます！
sudo apt-updateの前は保険でバックアップしておくとよいでしょう。

さて、読みだしたデータはmicroSDのカード容量ぶん馬鹿正直に読み出すので
32GBのカードならなんと32GBのサイズになっちまいます！！！
こんなものそのまま置いておけないのでとっとこzip圧縮します！！
zipで固めるとラズパイOS｢Raspbian｣フルセットでも4GBちょっとに収まります。

・balenaetcherで書き戻す


さっきのzip圧縮したイメージをターゲットのSDに書き戻す！！！

展開しながら書き込んでくれます。

書き込みとベリファイ終わり。終わった瞬間にまたwindowsからフォーマットを
求められてしまうのでうっかりフォーマットしないようにして無視しましょう。

ラズパイ本体に描き戻したmicorSDを指して無事起動。
おしまいっ！めでたしめでたし。とっても簡単だ！

というわけで複数のツールと手間はかかりますが確実に起動可能なイメージが
保存/書き込みできますので変な設定してラズパイが起動できなくなった時の復帰
手段として覚えておいて損はありません！

●最近続々出だした高耐久SDカードの性能を見る

まずはTOSHIBA製の高耐久128GBカードEXCERIA THN-M303E1280A2(以下M303E)です。
ねむいさんがこのカードを手に入れたころにはTOSHBAメモリからKIOXIAに名前が
変わってしまいましたが(2019.10.01)、昨年の夏に世に出たようです。
SDSpeedClass10、UHS-I U3、VideoSpeedClass30,ApricationClass1(A1)の
規格や-25~+85度の動作環境温度を満足しており、さらに6,000時間の書き込み保証を
しているそうでドラレコや監視カメラに最適なカードとうたっております。

まずはWindows上からベンチを取ります。

チマチマ書きもめちゃくちゃ早いですね。ラズパイのOS用にも良いでしょう。
マイクロンの物と比べるとちょっと遅く感じますがこの数値でも十分早いです。

お次はSTM32H7からカードの情報を読み出してみました

FatFs module test terminal for STM32H747XIH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : May 31 2020

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read at 22726 kB/sec.

>fs

FAT type = exFAT

Bytes/Cluster = 131072

Number of FATs = 1

Root DIR entries = 0

Sectors/FAT = 16384

Number of clusters = 944384

Volume start (lba) = 32768

FAT start (lba) = 49152

DIR start (lba,clustor) = 4

Data start (lba) = 65536



Volume name is M303E_128GB

Volume S/N is 78EB-41E0

...

1 files, 132949600 bytes.

120881152 folders.

120750336 KiB total disk space.

4 KiB available.

>ds 0

rc=0

Drive size: 241827840 sectors

Erase block size: 16384 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 5B 59 00 03 9A 7F 7F 80 0A 40 00 AF @..2[Y.......@..

CID:

00000000  02 54 4D 44 52 31 32 38 74 07 63 06 A1 01 3C 03 .TMDR128t.c...<.



Parsing SD CID Register

Manufacturer ID    :0x2

OEM/Application ID :TM

Product Name       :DR128

Product HwRev      :7

Product SwRev      :4

Serial Number      :0x076306A1

DateCode.Month     :12

DateCode.Year      :2019



OCR:

00000000  C1 FF 80 00 ....

SD Status:

00000000  80 00 00 00 08 00 00 00 04 00 A0 00 20 07 3A 1E ............ .:.

00000010  00 08 00 00 00 01 00 00 01 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 C5 84 43 60 03 40 1A ...C`.@.



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Spec Version X  :1

SD Security        :4

SD Bus Width       :5



SD_Spec V5.xx!

Detected as SDXC Card!

Available UHS-I Mode.

Available UHS Speed Class U3.

Available SD Speed Class 10.

Available Video Speed Class 30.

Available Application Performance Class1, A1 Card.

>

単純な読み出しはSDHighSpeedの限界値まで出てますね～
また、SdSpecはV5.xxで各種規格はスペック通りに満たしているとわかります。

お次はSANDISK製(ここはWestanDigitalになっちゃいましたが)のMAX ENDURANCEと
謳う超高耐久microSDカードSDSQQVR-064G-GN6IAです。
なんと30,000時間の書き込み(128GBはその倍)を保証し-25～85度の動作温度保証
とSDSpeedClass10、UHS-I U3、VideoSpeedClass30の規格を満足しています。
アプリケーションクラスは無いみたいですね。こちらもドラレコや監視カメラ
の連続書き込み用でチマチマ書き込みはそれほど得意ではないのかも！？しかし…

とりあえずベンチ。

あれ…TOSHIBAのより性能高い…！？チマチマ書きもA1クラス保証の奴よりいいぞ！？

STM32H7からカードの情報を読み出すとその理由が判明！

FatFs module test terminal for STM32H747XIH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : May 31 2020

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read at 21631 kB/sec.

>fs

FAT type = exFAT

Bytes/Cluster = 131072

Number of FATs = 1

Root DIR entries = 0

Sectors/FAT = 16384

Number of clusters = 486992

Volume start (lba) = 32768

FAT start (lba) = 49152

DIR start (lba,clustor) = 4

Data start (lba) = 65536



Volume name is SQQVR-064G

Volume S/N is D6EA-C58C

...

1 files, 132949600 bytes.

62334976 folders.

62204160 KiB total disk space.

4 KiB available.

>ds 0

rc=0

Drive size: 124735488 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 DB 79 00 01 DB D3 7F 80 0A 40 40 F9 @..2.y.......@@.

CID:

00000000  03 53 44 53 48 36 34 47 80 17 A7 01 58 01 41 A1 .SDSH64G....X.A.



Parsing SD CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :SH64G

Product HwRev      :8

Product SwRev      :0

Serial Number      :0x17A70158

DateCode.Month     :1

DateCode.Year      :2020



OCR:

00000000  C1 FF 80 80 ....

SD Status:

00000000  80 00 00 00 08 00 00 00 04 00 90 00 0F 05 39 1E ..............9.

00000010  00 08 00 00 00 02 FC 00 03 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 45 84 87 00 00 00 00 .E......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Spec Version X  :2

SD Security        :4

SD Bus Width       :5



SD_Spec V6.xx!

Detected as SDXC Card!

Available UHS-I Mode.

Available UHS Speed Class U3.

Available SD Speed Class 10.

Available Video Speed Class 30.

Available Application Performance Class2, A2 Card.

A2 CommandQueue Depth 32 Supported

A2 Cache Supported.

>

御覧の通りなんとA2カードだった！？SDSpecもV6だし間違いない！！！

というわけでMAXENDURANCEを誇るSANDISKの超高耐久カードはカタログスペック
以上の規格を備えた高性能カードでもあったことがわかりました！！！

お値段的には202005時点では同容量では性能が若干劣るTOSHIBAのほうが安いです。
購入の際は価格対効果を考慮して自分に合ったやつを使っていきましょう。

(※STM32H7から読みだしたときに"FAT type = FAT0"とあるのはChaNさんのサンプル
　からポーティングした時のバグです(FAT0ではなくexFAT)。
　6月定期更新で修正します。)
20200531修正しました

OpenOCD小ネタ26 -とうとうXPともお別れ-

とうとうこの時が来てしまいました…
ねむいさんのぶろぐ創設時より長年サポートし続けてきたWindowsXPともお別れ…！

どういうことかというとOpenOCDがリンクしているlibusbのWindowsXPのサポートが
コードからオミットされて終了してしまったのです…もうXPで動かせません。

Oh...my...ｺﾝﾌﾞ

XPのマイクロソフトのサポートが終わってもう6年、Windows7のサポートすら終わった
のでXPはこれで完全にお役御免と相成ったわけです。
まぁ実際の開発の現場じゃ昔のソフト動かすためにバリバリの現役だったりするのです
けどもそれは特殊な状況ですから今日日の普段使いのWindows系OSはすでに
~~使いづらい~~Win10に切り替わっていると思います。

というわけでOpenOCDバイナリのダウンロードページのリンク先の奴はすでに
XPサポートはオミットされた最新のlibusb1.dllが梱包されたものに変わっております。
まだXPで踏ん張ってる人はこちらの最終verをご利用ください。

同じくして他ツールも今回のlibusbがらみで更新を適用し、最新化をしました。
UrJTAG、FlashROM、そしてavrdudeが影響を受けてwindows7以降専用となって
おりますのでご注意願います。
また、64bitOS下でも32bitバイナリで不都合はないため、利便性を重視して
x86版でもx64版でもどちらのOSでも使用できるようにOpenOCDも含めてすべて
32bitバイナリのみの提供とさせていただいております。

3D-TLC搭載のマイクロン製産業用MicroSDを使ってみる

とある用事で大阪に降りた際に寄ったいつものPCショップでねむいさんが前から目を
付けていたMicron製のMicroSD(ややこしい)を発見し、早速入手しました！

諸般の事情で128GB‥かつてはこの容量だと10000円越えだったのに産業用でも
5000円以下となりずいぶんと安くなったものです…

正式な型番はMTSD128AHC6MS-1WTとなっております。
Micron公式では産業用向けとして紹介されており3D-TLCセルを使用した大容量・長寿命
を以てネットワーク監視カメラ用途を想定したものとなってりますが当然のことながら
ドラレコにも最適です☆
そして産業用ならでわのS.M.A.R.T.(以下SMART)も当たり前のように存在しており、
ねむいさんはもちろんそちらの方が目当てだったりしてました！

-----------------------------------------------------------------------

CrystalDiskMark 5.2.1 x64 (C) 2007-2017 hiyohiyo

                           Crystal Dew World : http://crystalmark.info/

-----------------------------------------------------------------------

* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]

* KB = 1000 bytes, KiB = 1024 bytes



   Sequential Read (Q= 32,T= 1) :    70.235 MB/s

  Sequential Write (Q= 32,T= 1) :    45.021 MB/s

  Random Read 4KiB (Q= 32,T= 1) :     4.693 MB/s [  1145.8 IOPS]

 Random Write 4KiB (Q= 32,T= 1) :     4.378 MB/s [  1068.8 IOPS]

         Sequential Read (T= 1) :    71.302 MB/s

        Sequential Write (T= 1) :    42.824 MB/s

   Random Read 4KiB (Q= 1,T= 1) :     3.534 MB/s [   862.8 IOPS]

  Random Write 4KiB (Q= 1,T= 1) :     3.475 MB/s [   848.4 IOPS]



  Test : 1024 MiB [H: 0.0% (0.0/116.1 GiB)] (x5)  [Interval=5 sec]

  Date : 2019/06/07 21:17:20

    OS : Windows 7 Professional SP1 [6.1 Build 7601] (x64)

    Micron Industrial MicroSDXC 3D-TLC UHS-1 MTSD128AHC6MS-1WT ADR-3ML35BK USB3.0 uPF720202 M570RU

まずはPC上でベンチマークをとってみました
Sandiskの産業用(第三世代)と比べてみますとチマチマ書き込みがかなり強い印象がありますね(理由は後述)。

FatFs module test terminal for STM32F769NIH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Jun  8 2019

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 18452 kB/sec.

>fs

FAT type = exFAT

Bytes/Cluster = 131072

Number of FATs = 1

Root DIR entries = 17931

Sectors/FAT = 16384

Number of clusters = 951296

Volume start (lba) = 32768

FAT start (lba) = 49152

DIR start (lba,clustor) = 4

Data start (lba) = 65536



Volume name is MTSD128AHC

Volume S/N is DAD2-8E1E

...

1 files, 132949600 bytes.

0 folders.

121765888 KiB total disk space.

121635456 KiB available.

>ds 0

rc=0

Drive size: 243597312 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 5B 59 00 03 A1 3F 7F 80 0A 40 00 0F @..2[Y...?...@..

CID:

00000000  09 41 50 4D 42 35 33 41 01 E1 00 6F 10 01 28 C5 .APMB53A...o..(.



Parsing SD CID Register

Manufacturer ID    :0x9

OEM/Application ID :AP

Product Name       :MB53A

Product HwRev      :0

Product SwRev      :1

Serial Number      :0xE1006F10

DateCode.Month     :8

DateCode.Year      :2018



OCR:

00000000  C1 FF 80 00 ....

SD Status:

00000000  80 00 00 00 08 00 00 00 04 00 90 00 01 33 19 00 .............3..

00000010  00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 45 80 43 01 00 00 00 .E.C....



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Spec Version X  :1

SD Security        :4

SD Bus Width       :5



SD_Spec V5.xx!

Detected as SDXC Card!

Available UHS-I Mode.

Available UHS Speed Class U1.

Available SD Speed Class 10.

Video Speed Class NOT Supported.

Available Application Performance Class1, A1 Card.

お次はねむいさんのいつものでカード情報を読み出してみました。
FatFs移植例も7月更新分からSDカードのサポート情報の細分化を進めており各種
スピードクラスのサポート状況が分かるようになりました。
このMicron製の奴はカード本体には記載はないのですがA1クラスサポートとなってお
ります。いちおう公式でもA1対応と言っておりますが製造時にロゴのレタリング追加
するの忘れちゃっただけなんでしょうけど。

そしてこのマイクロSD買ったメインの目的のSMART情報の取得です!
このカードではDelkinやSandiskと同じくCMD56でSMART情報の取得が可能なのですが、
なんと公式に資料を公開しており超太っ腹です！こちらの資料によるとCMD56の引数は
0x110005FBとなります。これを引数にしてCMD56を打ち込んでやると無事SMARTの
情報を取ることができました♥(もちろんSPI互換モードでも獲れます )
こちらに読みだした生データを置いておきますのでご参考に。

今回SMARTをとるにあたり上のテクニカルノート見て気づいたのですがこのMicron製の
奴はNANDメモリセルが3D-TLCなのですが一部はSLCのようなんですよね…
"Internalbuffer"としてどういう使い方するかによりますがFAT/exFATファイル
システムで使用する際に先頭にある書き換えが激しいFAT領域まではSLCの区画を
使用して比較的消去サイクルが少ないデータ領域に関しては3D-TLCの区画が
使用されている……といった感じなのでしょうか？？？
そしてSLCの区画をバッファとして使用することによってチマチマ書き込みも
強化されている感がしますね。

こういったハイブリッドなメモリセル構成にすることでコストパフォーマンスと信頼性を
同時に確保して大容量化を目指す路線が今後のSDカードで流行りそうですね～
SDUCでの最大容量が128TBだそうですが近い将来にあっさり到達してしまいそうです。

いろいろ試す37 -平成最後の更新…か！？-

このぶろぐエントリを書こうとして気づいたんですが新元号は4月1日公表で
施行は5月1日なんですよね…平成最後のぶろぐ更新は来月ですね…
あぶないあぶない…さて、

●A2規格のマイクロSDカードｹﾞｯﾂ

チマチマ書きに高いパフォーマンスを見せるらしいSandisk製のA2規格の
microSDカードSDSQXCY-064G-GN6MAです！！！
(って買ったの去年の10月で今頃紹介ですが…)

カードの表裏はこんな感じです。A2ロゴがかっこいいですね！

早速ベンチをとって見ました。
事前にSDFormatterでexFATでフォーマットしております。

ほう…A1のカードはどうでしたっけ…

…
A1ってランダムライトが糞遅くて過去のExtremeと比べてもあんまし
使えない感じでしたがちょっと微妙ですね…
↑A2規格で新設されたキューイングとかに対応したSDホストじゃないと
　本来の力発揮できないそうですorz

恒例のSDの情報を抜き出してみました。

FatFs module test terminal for STM32F769NIH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Sep  9 2018

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 18051 kB/sec.

>fs

FAT type = exFAT

Bytes/Cluster = 131072

Number of FATs = 1

Root DIR entries = 14450

Sectors/FAT = 16384

Number of clusters = 486992

Volume start (lba) = 32768

FAT start (lba) = 49152

DIR start (lba,clustor) = 4

Data start (lba) = 65536



Volume name is SQXCY_064G

Volume S/N is 3BBB-87AE

...

1 files, 132949600 bytes.

0 folders.

62334976 KiB total disk space.

62204160 KiB available.

>ds 0

rc=0

Drive size: 124735488 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 DB 79 00 01 DB D3 7F 80 0A 40 40 F9 @..2.y.......@@.

CID:

00000000  03 53 44 53 52 36 34 47 80 24 74 BC C8 01 28 FB .SDSR64G.$t...(.



Parsing SD CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :SR64G

Product HwRev      :8

Product SwRev      :0

Serial Number      :0x2474BCC8

DateCode.Month     :8

DateCode.Year      :2018



OCR:

00000000  C1 FF 80 80 ....

SD Status:

00000000  80 00 00 00 08 00 00 00 04 00 90 00 0F 05 39 1E ..............9.

00000010  00 08 00 00 00 02 FC 00 03 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 45 84 87 00 00 00 00 .E......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Spec Version X  :2

SD Security        :4

SD Bus Width       :5



SD_Spec V6.xx!

Detected as SDXC Card!

Available UHS-I Mode.

SDSpecはV6となっていて2018年の8月製！当時は
出来たてのホヤホヤをｹﾞｯﾂしていたようですね。

●64GBのサンディスクの産業用のマイクロSDカードもｹﾞｯﾂ

ねむいさんが大阪に降りたときに日本橋のPCワンズという店に寄るのですが、
なんと64GB版の第3世代サンディスクの産業用のマイクロSDカードが販売して
おりました！値段も3,690円とリーズナブルで容量も十分です！

UHS-1なのでシーケンシャルでも超早いです！
…あれ？これA2のやつよりRead性能いいじゃないですか…
もう普段使いのmicroSDもこいつでいいんじゃないかな。

こちらもSDの情報を読み取って見ました。

FatFs module test terminal for STM32F769NIH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Feb 19 2019

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 19989 kB/sec.

>fs

FAT type = exFAT

Bytes/Cluster = 131072

Number of FATs = 1

Root DIR entries = 14448

Sectors/FAT = 16384

Number of clusters = 486992

Volume start (lba) = 32768

FAT start (lba) = 49152

DIR start (lba,clustor) = 4

Data start (lba) = 65536



Volume name is SDQAF3_064G

Volume S/N is 4415-38F9

...

1 files, 132949600 bytes.

0 folders.

62334976 KiB total disk space.

62204544 KiB available.

>ds 0

rc=0

Drive size: 124735488 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 5B 59 00 01 DB D3 7F 80 0A 40 40 DF @..2[Y.......@@.

CID:

00000000  03 53 44 53 41 36 34 47 80 EC 76 CD 3E 01 26 83 .SDSA64G..v.>.&.



Parsing SD CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :SA64G

Product HwRev      :8

Product SwRev      :0

Serial Number      :0xEC76CD3E

DateCode.Month     :6

DateCode.Year      :2018



OCR:

00000000  C1 FF 80 00 ....

SD Status:

00000000  80 00 00 00 08 00 00 00 04 00 90 00 0F 05 1A 0A ................

00000010  00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 45 84 43 00 00 00 00 .E.C....



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Spec Version X  :1

SD Security        :4

SD Bus Width       :5



SD_Spec V5.xx!

Detected as SDXC Card!

Available UHS-I Mode.

>

SDSpecはV5ですがこちらも2018年製ですね！
もちろん第3世代カードなので当たり前のようにSMARTが獲れます！
こちらに読みだしたSMARTのデータを置いておきますのでご参考に。

シーケンシャル読み書きもそれなりに速度出てて値段もお手頃なので
業務用/ドラレコ向けは勿論普段使いでデータの信頼性が欲しいなんて時にも
お勧めです。価格と性能を求める欲張りな貴女にぴったりかも！？

●定例のソースコード更新の件
ねむいさんが管理しているChaN師のFatFsの移植例いつものの月例更新です。
boochowさんよりコメントいただきました通りねむいさんのプロジェクトは
大文字小文字が統一されて無くてlinux系OSでは途中でエラーになっていましたが
今回からちゃんと整合性が出るようにmakefileを更新しました。
その中でUppercaseをLowercaseに替えるシェルコマンドがwindows環境下で上手く
動かないことがわかり↓のような結構見苦しい自前コマンドで逃げてます…。

# Exchange Uppercase into Lowercase

#MPU_MODEL_LOWER = $(shell echo $(MPU_MODEL) | tr A-Z a-z)

lc_jimae = $(subst A,a,$(subst B,b,$(subst C,c,$(subst D,d,$(subst E,e,$(subst F,f,$(subst G,g,$(subst H,h,$(subst I,i,$(subst J,j,$(subst K,k,$(subst L,l,$(subst M,m,$(subst N,n,$(subst O,o,$(subst P,p,$(subst Q,q,$(subst R,r,$(subst S,s,$(subst T,t,$(subst U,u,$(subst V,v,$(subst W,w,$(subst X,x,$(subst Y,y,$(subst Z,z,$1))))))))))))))))))))))))))

MPU_MODEL_LOWER  = $(call lc_jimae,$(MPU_MODEL))

だれかねむいさんの環境構築法でもっとスマートにできる方法あったら
教えてくだち。

そんでもってCMSISv5もgithubの変更を即反映して更新しておりますが、
なんでかこれの更新から一部のCMSISヘッダファイルがバージョンダウン
(しかも数字だけ)しやがっておりますので今回からV5.2.1とかの細かい更新は
whatnew.txtに書かないようにしました…
理由も書かずにしれっとこういう書き換えするのマジやめて。

●もう少しで10周年やん
やばい…四月になったらこのぶろぐ10年目だ…
…
よくよく考えたらARMマイコンの環境構築とChanN師のFatFsの移植から先に
ほとんど技術的に進んでない…10年も経ってるのに…

…
…

令和からがむばります！！！！！！！！！

2019.03.31 Sunday
21:16
ネムイ・トリノミアス
MISC
-
-

いろいろ試す36

今年は本当に波乱に満ちた年でしたね…
それでも月一ペースで何が何でも記事を更新できた私をほめてあげたい(自画自賛

●4GBのマルチメディアカードをついに入手！…しかし…

流通在庫が高すぎて敬遠していたのですがebayで新個品が放出されたタイミングを
見逃さなかった！！！！！Transcend製の4GBもあるMMC｢TS4GMMC4｣です！

同じトラ製のSDHCカードと比べてみました。

当たり前ですがねむいさんのSTM32F7のいつものでしっかり認識します。

カード情報も拾ってみました

FatFs module test terminal for STM32F769NIH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Sep 30 2018

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 17609 kB/sec.

>fs

FAT type = FAT32

Bytes/Cluster = 32768

Number of FATs = 2

Root DIR entries = 0

Sectors/FAT = 960

Number of clusters = 122752

Volume start (lba) = 8192

FAT start (lba) = 14464

DIR start (lba,clustor) = 2

Data start (lba) = 16384



Volume name is TS4GMMC4

Volume S/N is 9FB2-841B

...

1 files, 132949600 bytes.

0 folders.

3928064 KiB total disk space.

3797920 KiB available.

>ds 0

rc=0

Drive size: 7872512 sectors

Erase block size: 512 sectors

Default r/w block size: 2048 bytes

Card type: MMC(Byte)

CSD:

00000000  90 2F 00 2A 1F 5B 83 C0 F6 DB BF FF 96 C0 00 1D ./.*.[..........

CID:

00000000  1E FF FF 4D 4D 43 20 20 20 10 00 00 02 2E BD 73 ...MMC   ......s



Parsing MMC CID Register

Manufacturer ID    :0x1E

OEM/Application ID :

Product Name       :MMC   

Product Rev        :1.0

Serial Number      :0x0000022E

DateCode.Month     :11

DateCode.Year      :2010



Detected as MMCv4.1 Device!

OCR:

00000000  80 FF 80 00 ....

>

今から8年前に造られた最後の方のロットのMMCですね～

ebayの新古品は2000円近辺で購入できるので例のSDライセンス問題も全く心配なく
ホビーで使いまくれると思います！

…と思ったのですが！！！

なんとこのMMC、MMCv4.1なのですが今日びのSDカードですら存在する
SPI互換モードが存在しないためマイコンの工作でSPIで手軽に使用する
ことが一切できませんorz

上で認識してたのはSTM32F7のSDMMCからMMCネイティブモードで叩いたので
さくっと動いて見えたのですが…皆さんご注意ください。SPI互換モードが
存在しないのは4GB品だけで2GB以下の品種はちゃんとSPIでも動きます…。

外人さんも嘆いている
ちょうどeMMCへの過渡期だったので4GB品の製造の際に遅いSPIモードがオミット
されてしまったのでしょう…まぁ電子工作で4GBも使うって早早ないから2GBでも
十分じゃないかな～…うっかりSDカードが動いてしまうこともありますし

というわけで古のデバイスにも癖があったというおはなしでした！

●サポート止めたプロジェクトをメンテしてみた

3年前に更新停止したLPC2388のプロジェクトとかを最新のFatFsとかにあてがって
みました。arm-gccは表向きはcortex-mのサポートとうたっていますが昔の
ARM7TDMIとかも余裕でビルドできます。
OpenOCDの書き込み・デバッグも順調です☆

あとLPC2388はUSBデバイス機能があってMSCやCDCなんかができるんですけど
たとえばCDCでは現在ではzadigを使用して汎用のCDCドライバをあてがう
ことができるので格段に使い勝手が上がってます！
まぁあえてLPC2388を使っていく意味も今となっては有りませんが余興ということで

そしてMicrochipになってしまったATMEL製のXMEGAもFatFsの最新版(0.13c(patch1))
をあてがって動作確認できました。
コード効率が悪い上に容量も128kbしかないのでexFATはおろかLFNすら乗っけられ
ませんがまぁ余興と(ry

ちなみにAVRToolchainは数年前に更新しなくなりましたが有志の方がavr-gccのツール
チェインを更新し続けているためほぼ同じ感覚でgccビルドができます。

avr-gccを使う上で注意すべき点はavr-size.exeがAVRのフォーマットが使えず、
汎用の動作しかしないのでFLASH/RAMの容量は自ら管理しなくてはいけません。
まぁここもARMマイコンいじるさいはリンカスクリプト自前で起こす必要あって
皆さん経験済みなので問題ないでしょう。

avrdudeも更新停止したと思ていたらさりげなく更新してたので久しぶりにビルド
しました。おきぱにあるのでどしどしご利用ください！
また、avr-gccにはavrdude.exeが同梱されてますがかなり古いのでavr-gccと
ねむいさんのavrdudeを組み合わせて使う際はバッティングにご注意ください。

同時にUrJTAG、flashromも微妙に更新がかかっていたのでビルドし直しました。
ビルドに当たってはOpenOCDも含めてMinGW-w64 GCC8.1.0を使用してますので
ビルド環境もアップデートしております！

●arm-gccの新しい奴が出た！
例年年末に出るやつがやっと来ました。
今回の変更点はGCCのバージョンがついに8になったところです！
さっそく導入してみました！

…
ﾅﾆｺﾚ…ihexで出力できない…
64-bit address 0x4b4fa300000000 out of range for Intel Hex file
ってなんなんだＹＯ！
arm-none-eabi-objcopyバグってる…？

調べてみると同じ症状に遭遇された方がいました。どうやらarm-gccの新しい奴にある
objcopyにバグがあり、IntelHEXフォーマットの出力ができないようですorz

対処法はどうしても新しいarm-gcc使いたい場合はarm-none-eabi-objcopy.exe
だけ一個前のverに差し替えるだけでおｋです。
こんな基本的なところでエンバグするの止めてくださいよ～！
※バグじゃなくてオプションのつけ方悪いだけならご指摘願います

20190131追:
公式も認めました！！

●転職しました
読んで字の通りでございます。
2012年から長きにわたる派遣ジプシー生活からようやく解放されて正社員になれたん
やなぁ…って

あまり詳しいことはお伝えできませんが正社員への転職に当たっては最初は自力で
転職サイトとかに登録して活動しておりましたが有効求人倍率が1倍を上回る状況
にもかかわらず年齢的にも経験的にも箸にも棒にも引っかからず全く太刀打ちでき
ませんでした。

しかしながら存在は知っていたものの興味が無かった転職エージェントを利用した
ことで状況は大きく変わり、そこそこの待遇で内定をたくさんいただくようになり
その中で納得がいく会社に2018年内に無事就職する運びとなり、今も頑張っています。

この時利用したエージェントさんですが"め"ではじまる名前と"あ"ではじまる名前の
二社で進めていき両社とも技術系に特化した所でしたので私の適正に近い会社様を
すぐに紹介していただけました。リクルートとかエン転職とか有名どころですが
某魔法少女より｢それらは避けよ｣と事前に忠告されていたため、ちょっとマイナー
ですが"め"と"あ"ではじまるところにお世話になった次第でございます。

ちなみに両者のエージェントさｎより口をそろえてほぼ同じ内容を説教されましたが
｢あなたのブログは選考者に対して大きなマイナスの印象を与えるので紹介しては
　いけませんよ」って言われてもちろんgithubもそこからブログにたどり着けちゃう
ので当然ダメでそれらの要素省いた出がらしみたいなスキルシート作るのが一番
精神的に辛かったのですがたぶん自力でやってた頃あっさりbanされまくってたのって
これが原因かなと思ってたのですがねむいさん面白い記事書けるよう務めてきたはず
ですが、いないさんのちょっとぱんつがみえてるｲﾗｽﾂとか至って健全で普通なのに何故だ(錯乱

20190407追：
ねむいさんのぶろぐがスラドに！！！
マジレスしますと私のぶろぐ記事から読み取れる私の技術的能力・文章作成能力は
｢ありものを組み合わせて動いたつもり分かったつもりの素人レベル」でこいつに
プロとしての仕事はできないと判断下され採用に至らなかったからですがorz
エージェントさんより指導入りまくった実務経歴の方はしっかりと評価していただけた
会社様が多かったので私がダメだっただけでホントに個別論ですね個別論♨
↑苦しい突っ込み入れられたら個別論で茶を濁して逃げるのいいですねねむいさんもよく使います♨

●ねむいさんFAQ
Ｑ：昔のぶろぐ記事でdropboxの見えなくなった画像早く復旧してください
Ａ：ぇっと…
　　今年は大事なことにたくさんエネルギー使っちゃったので
　　
　　来年からがむばります！

OpenOCD小ネタ23 -新機能続々更新-

夏が終わったと思ったらもう冬かよ…秋はどこだ…

さて、そうこうしているうちにOpenOCDも着々とバグフィクスや新機能が追加されて
おります。そろそろV0.10からV0.11になっても良いと思いますがgerritで管理され
てる全員参加型のフリーウエアにそれを求めるのはあまりにも野暮ですがそれはおい
説いて紹介させてもらいます。

●CMSIS-DAPの速度がアップ！
CMSIS-DAPはARM肝入りのフリーなデバッガアダプタで最近販売されている安価な
Cortex-Mx系の評価キットでは欠かせないものとなっております。

ねむいさんのぶろぐでも2014年にいち早く紹介させてもらっています。当初は
マイコンへの書き込み速度が非常に遅く使い物にならなかったのですがその後機能強化
されようやく実用レベルに、そして今回の修正でさらにスピードアップしました☆
もっとも2017年春にはすでにパッチが上がっていてねむいさんが提供するバイナリ
にはそのパッチが適用されておりましたので皆さん実は気づかず使用されて
いたことになります！

それではさっそく比較してみましょう。
今回CMSIS-DAPを仕込んだLPC1549Xpressoを引っ張りだしてきて32kByteの
バイナリを書き込み、ベリファイを行いそれぞれの経過時間を比較しました。
●修正適用前

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

openocd  -s C:/Devz/ARM/OCD/tcl -f interface/cmsis-dap.cfg -f target/lpc1549_swd_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.9.0-dev-00357-g09ca5af-dirty (2015-03-31-00:00)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'swd'

none separate

cortex_m reset_config sysresetreq

adapter speed: 1000 kHz

Info : CMSIS-DAP: SWD  Supported

Info : CMSIS-DAP: JTAG Supported

Info : CMSIS-DAP: Interface Initialised (SWD)

Info : CMSIS-DAP: FW Version = 1.0

Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1

Info : CMSIS-DAP: Interface ready

Info : clock speed 1000 kHz

Info : SWD IDCODE 0x2ba01477

Info : lpc1549.cpu: hardware has 6 breakpoints, 4 watchpoints

target state: halted

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

xPSR: 0x01000000 pc: 0x030000b8 msp: 0x02001fe0

auto erase enabled

wrote 32768 bytes from file main.elf in 2.525144s (12.673 KiB/s)

verified 29400 bytes in 0.426025s (67.393 KiB/s)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:04

●修正適用後

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

openocd  -s C:/Devz/ARM/OCD/tcl -f interface/cmsis-dap.cfg -f target/lpc1549_swd_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.10.0+dev-00563-gda4b2d5-dirty (2018-10-29-08:10)

Licensed under GNU GPL v2

For bug reports, read

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

Info : auto-selecting first available session transport "swd". To override use 'transport select '.

none separate

cortex_m reset_config sysresetreq

adapter speed: 1000 kHz

Info : CMSIS-DAP: SWD  Supported

Info : CMSIS-DAP: JTAG Supported

Info : CMSIS-DAP: FW Version = 1.0

Info : CMSIS-DAP: Interface Initialised (SWD)

Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1

Info : CMSIS-DAP: Interface ready

Info : clock speed 1000 kHz

Info : SWD DPIDR 0x2ba01477

Info : lpc1549.cpu: hardware has 6 breakpoints, 4 watchpoints

Info : Listening on port 3333 for gdb connections

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

xPSR: 0x01000000 pc: 0x030000b8 msp: 0x02001fe0

auto erase enabled

wrote 32768 bytes from file main.elf in 2.477142s (12.918 KiB/s)

verified 29400 bytes in 0.425024s (67.551 KiB/s)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:03

書き込み速度だけ抜き出して比較
前 :wrote 32768 bytes from file main.elf in 2.525144s (12.673 KiB/s)
後 :wrote 32768 bytes from file main.elf in 2.477142s (12.918 KiB/s)
…
あらら…140%早くなるんじゃないの‥？？
…まぁちょっと早くなったしまぁいっか！

●NuvotonのNuLinkに対応！
台湾NuvotonのCprtex-M系マイコンNumicroシリーズ、数年前にねむいさんが
フラッシュ書き込み対応させて以来即効飽きて放置してましたが…なななんと！
Nuvotonの開発チームの人が直々にNuvotonのCortex-Mx向けのデバッガNuLinkを
OpenOCDに対応してくれました！！！！１１！！！

ちなみに秋月で購入できるNuvotonのキット付属のNulinkはUSBコンポジットデバイスで
制御対象マイコンとつながるのはUSB-HIDとなっており、これだけで動作させるならば
ドライバすら不要です☆

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

openocd  -s C:/Devz/ARM/OCD/tcl -f interface/nulink.cfg -c "transport select hla_swd" -f target/numicro_swd_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.10.0+dev-00563-gda4b2d5-dirty (2018-10-29-08:10)

Licensed under GNU GPL v2

For bug reports, read

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

hla_swd

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

adapter speed: 1000 kHz

none separate

Info : clock speed 1000 kHz

Info : NULINK is Nu-Link1

Info : NULINK firmware_version(6386), product_id(0x00012009)

Info : IDCODE: 0x0BB11477

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

Info : Listening on port 3333 for gdb connections

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

xPSR: 0x01000000 pc: 0x0000035e msp: 0x20003fd0

auto erase enabled

Info : Device ID: 0x00012000

Info : Device Name: NUC120LE3AN

Info : bank base = 0x00000000, size = 0x00020000

Info : Nuvoton NuMicro: Sector Erase ... (0 to 41)

Info : Nuvoton NuMicro: Flash Write ...

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

wrote 21504 bytes from file main.elf in 6.905395s (3.041 KiB/s)

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0

verified 21288 bytes in 0.324018s (64.160 KiB/s)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:13

パッチを適用したOpenOCD書き込んだログはこんな感じです。
仕様上ちょっと癖があり接続しに行くと他のデバッガと違ってワンテンポ間が開く
感じで繋がります。そして立ち位置としてはTI-ICDIやSTLink系と同じHLA扱いと
なっております。ですのでAPの直叩きはできないので注意が必要です。

それとCMSIS-DAPのようには最適化されていないのかVersaloonの1/2くらいの
書き込み速度となってますね…今後の改良はNuvotonチームに期待ですね。

SW-DPの直叩き等の低レベルの操作はできないですが通常デバッグで行える操作、
レジスタ、メモリ参照などは問題なく可能です。
これでNuvotonマイコンもフリー環境で使い勝手が大幅に上昇した感じがしますね！

今回の修正を反映したOpenOCDのバイナリはすでにおきぱにありますのでどしどし
使ってください！NuLink対応はまだ公式採用ではありませんがねむいさんバイナリには
すでに適用しております！

また、今回のNuLinkの対応に当たり私がかつて統合したnuvotonドライバで
デバッグ時に一部動作がおかしくなる品種があることも突き止め、それの
修正も加味しております。これについては次回詳しく説明させていただきます！

ドラレコに最適！第3世代サンディスク産業用マイクロSDカードを入手せよ！

ここ最近は諸般の事情で大阪への所要が頻繁にあるのですが、ふと立ち寄った
大阪日本橋のPCショップでとんでもないものを発見してしまいました！！

なんとサンディスクの産業用microSDカード第三世代のものが販売されていたのです！
昨年から一般では入手不可能なサンディスク産業用microSDが市場にﾎﾟﾂﾎﾟﾂと流出
しておりましたがドライブレコーダーや監視カメラなどへの需要が大きく、継続的に
PCショップなどの市場に出回ているようです。

しかも現在の最新モデルである第三世代！！！
もちろんS.M.A.R.T(以下SMART)による寿命判定可能！

第3世代のカードでは32GB以上のモデルでもUHS-Ⅰクラスとなっています。
過去のモデルではClass10表記しかなかったのですがこれで通常使用でも十分
使用に耐えるものになりそうですね。

とりあえずベンチとってみました。
第二世代
 第一世代
と比べるとシーケンシャル書き込みは段違いの性能を示していますね！
チマチマ書き込みに関しても1MB/Sec割ってないので断続的な書き込みに
安定して強く、ドラレコ等で十分使えます！

お約束のねむいさんのいつものでカード情報を読み出しました。

FatFs module test terminal for STM32F769NIH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Sep  7 2018

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 17637 kB/sec.

>ds 0

rc=0

Drive size: 62333952 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 5B 59 00 00 ED C8 7F 80 0A 40 40 C3 @..2[Y.......@@.

CID:

00000000  03 53 44 53 41 33 32 47 80 75 F0 3C AD 01 26 A1 .SDSA32G.u.<..&.



Parsing SD CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :SA32G

Product HwRev      :8

Product SwRev      :0

Serial Number      :0x75F03CAD

DateCode.Month     :6

DateCode.Year      :2018



OCR:

00000000  C1 FF 80 00 ....

SD Status:

00000000  80 00 00 00 05 00 00 00 04 00 90 00 0F 05 1A 0A ................

00000010  00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 84 43 00 00 00 00 .5.C....



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Spec Version X  :1

SD Security        :3

SD Bus Width       :5



SD_Spec V5.xx!

Detected as SDHC Card!

Available UHS-I Mode.

2018年6月製造の出来たてほやほやでした！
SDの世代もV5となっていますね。

さてこのカードの売りであるSMART機能ですが…もちろん第2世代カードと
同じくCMD56のコマンドで寿命判定を含む512バイト分のSMARTのデータを
読みだすことができます。
上の図の通り"Sandisk"のイニシャルコードが読みとれました。
こちらにCMD56で読みだした際のデータを置いておきますので参考にしてください。

また、当たり前ですが肝心の寿命に関するレジスタの配置はすべて過去の
世代のものと同一ですのでサンディスクの産業用SDでシステムを組んで
いたらソースの改変の必要が無くそのまま差し替えで使用可能です。

前途の通りドライブレコーダーや監視カメラなどが使用される個所は極端な
温度変化が起きさらに日本では高湿度環境下の動作を強いられます。
さらにその状況下でデータの確実性まで求められるため、TLCが使用されて
いる一般向けのmicroSDカード等は信頼性の面で到底使用できません。

タフな環境向けの高耐久なmicroSDカードも認知され始めていますが
サンディスクの産業用microSDカードは少しの電子工作の知識は必要ですが
SMARTが採れ寿命の判定もできるという点で普通の高耐久カードよりも
性能が一歩リードしていると言えるでしょう。あとシーケンシャル読み書き
速度の面でもですね。多くの単純な高耐久カードはまだClass10までですので。

昨年から言っていますがSD向けのSMARTが規格化されドラレコ上で容易に
寿命判定出来ればなおよいのですが現在急速に需要が増加している状態
なのでそのような時代はすぐやってくると思われます。

本家サンディスクも高耐久カードに関する取材を受けていますね。時代はタフさを
求められています！

追記：ドラレコ・監視カメラに使用する際は使用する機器の容量上限を確認しておいてください。
　　古いモデルでは上限値が32GBまでで、64GB以上で必須のexFATに対応していない物が
　　存在しています。容量は減りますが迷ったら32GBの奴選べばまず問題ないです。

いろいろ試す34

あああ…夏がおわる…

●GNU Arm Embedded Toolchainが新しくなった夏
忘れたころに更新されることで有名なARM提供のGCCツールチェインが
更新されていました…

日付は6/23版となっています…2018q2版になってますね
下記の修正が入っています。他は大きな違いはないと考えられます。

Important changes in 7-2018Q2 update release:

* Fixed powf/expf/exp2f/logf/log2f performance regression

  https://answers.launchpad.net/gcc-arm-embedded/+question/662462

* Added support for Arm Cortex-M33 without DSP via -mcpu=cortex-m33+nodsp

* Added Armv8-R multilib mappings

* Fix build requirements for GDB tui support

* Enabled C99 IO format specifier in newlib

* Fixed cmse_nonsecure_caller Armv8-M Security Extension intrinsic

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85203

* Fix crash in __builtin_arm_set_fpscr GCC builtin

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85261

* LTO bug https://bugs.launchpad.net/gcc-arm-embedded/+bug/1747966

  was fixed in previous release. Release note updated to reflect the change.

* Fixed issue with building libgcc's cmse.c without headers

  https://bugs.launchpad.net/gcc-arm-embedded/+bug/1717502

* Fixed issue with arm_cmse.h C99 compatibility

  https://bugs.launchpad.net/gcc-arm-embedded/+bug/1773934

●UHS-ⅡのマイクロSDカードを動かしてみる

買ってしまった…
日本橋に寄った際に目に入ったUHS-ⅡのマイクロSDカード…
ねむいさん今省エネモードなのでお金の使い方も省エネで64GBとか買えないので
32GBのSDHCとなっています…

東芝のEXCERIAシリーズの最高峰に位置するM501とかいうモデルです！！！
UHS-Ⅱ用の端子が追加されていますね！

SDカードサイズへの変換アダプタもUHS-Ⅱ仕様となっていますね～

早速ベンチマークをとって見ましたが…ねむいさんのUSB3.0カードリーダーは
UHS-Ⅱ規格に対応してなかったorz
ていうわけでUHS-Iの規格ですがチマチマ書き込みもまぁそこそこですし
使い物にはなると思います。

ねむいさんのいつものでカード情報を読み出してみました

FatFs module test terminal for STM32F769NIH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Jul 28 2018

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 20989 kB/sec.

>ds 0

rc=0

Drive size: 62529536 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 5B 59 00 00 EE 87 7F 80 0A 40 00 53 @..2[Y.......@.S

CID:

00000000  02 54 4D 58 41 30 44 35 44 E2 51 8E B2 01 12 6B .TMXA0D5D.Q....k



Parsing SD CID Register

Manufacturer ID    :0x2

OEM/Application ID :TM

Product Name       :XA0D5

Product HwRev      :4

Product SwRev      :4

Serial Number      :0xE2518EB2

DateCode.Month     :2

DateCode.Year      :2017



OCR:

00000000  E1 FF 80 00 ....

SD Status:

00000000  80 00 00 00 05 00 00 00 04 02 90 00 20 07 3E 00 ............ .>.

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 B5 84 03 3C 03 47 82 ....<.G.



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Spec Version X  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V4.xx!

Detected as SDHC Card!

Available UHS-II Mode.

ちゃんとUHS-Ⅱモードがあることを認識していますね。
STM32シリーズはUHS-Ⅱモードのインターフェースはまだ存在しておりませんが
UHS-Ⅱモードがあるか否かはACMD41コマンドでわかります。
ACMD41を打って還ってくるレジスタの37番目のビットが1ならばUHS-Ⅱ対応を
唱っていることになります。

●OpenOCDにセキュリティホールがあるらしい
まじかー
OpenOCDも攻撃されるほど有名になっていたのですね～

一応対応策が提示され、gerritにも上がっているようですが2018年の1月で
審議が止まっているようです

いろいろ試す33

冬が過ぎたと思ったらもう夏ですね…いやはや今年は本当に展開が早い
…STM32H7Discovery遅いな…H7自身もリリース遅れ気味ですし

●携帯音楽プレーヤーのリチウムポリマー電池を自力で交換する

！注！
リチウムイオン電池およびリチウムポリマー電池は取り扱いを誤ると簡単に
爆発炎上します！特にはんだ付けタイプのものは作業中にショートを起こし
やすく、はんだ付けの熟練者以外は絶対に興味本位で取り扱わないでください！
また、当ぶろぐエントリをもとに電池交換の真似をしてあらゆる被害をこうむった
如何に関わらずねむいさんは一切の保証をいたしませんのでくれぐれもご注意
願います！

2018年の現在ではスマホでなんでもできるようになってしまいましたがなんと
ねむいさんはまだガラケーですがそんなことどうでもいいのですがかつて隆盛を
極めた携帯MP3プレーヤも家電量販店のごくごく片隅にひっそりと販売されている
始末です。

当時のヨドバシ梅田店でcowonという南朝鮮のメーカ製のiaudio9(その後9+に
買い替え)を購入しトレランのお供として長らく使って参りましたがとうとう内蔵
リポ電池が消耗しきってしまいました。
5年以上も前の製品なのでサポートがあるかどうかも怪しく、保証もとうに切れて
いるので自分で交換してみることにしました。

ねむいさんのトレランのお供としてゼERO再生機と化したiaudio9+の背面です。
野外で使用しまくったためかなりﾎﾞｺﾎﾞｺ…
中央に見える黄色いテープはiaudioを操作中に突然ﾌﾞｰと大音量で鳴って操作
不能になる不具合に陥った際にリセットスイッチを押すためのピンを本体に
張り付けるためのものです。

スマホの皮むきツールを駆使して丁寧に裏蓋を外します。幸いにもリポ電池は
交換しやすい場所にあります。

リポ電池のアップです。リポ電池の型番は電池サイズが容易に分かるように
なっていてiaudio9+ではPR-383540なので厚さ3.8mm、幅35mm、長さ40mm
となります。

残念ながらそのものずばりは存在しないのでebayでそれに似たサイズの奴を探して
きました。とりあえずオリジナルよりも3サイズが小さければ問題ないです。
そして…

ｷﾀ━━━(ﾟ∀ﾟ)━━━!!

2週間ほどでやってきました。税関でﾎﾞｯｼｭｰﾄされるかもと思いましたが。
ねむいさんが購入したリポ電池は403040サイズのものでiaudio9+に十分入る
大きさでした。

それではリポ電池移植手術開始！
安全上リポ電池は過充放電防止回路やショート防止回路などが組み込まれている
(はず)です。ねむいさんも購入時は細心の注意を払って選んで買ったつもりですが
絶対に作業中にショートさせないようにして挑みました！

もとの電池を除去して新リポのリードを短く切って剥いて本体に慎重にはんだ
付け…あああ手が震える…もちろんもう片方のリードは厳重に絶縁しておきます。

そしてマイナス側…はんだコテでショートさせないように周りにマスキングを
貼り鉄壁の防御で作業開始…！GNDパッド広すぎて熱が伝わらん…

はぁはぁ…ｯｯできた～～！

そして緊張の火入れ…こちらも無事起動です☆
これでiaudio9+が復活しました！やったぜ！

ねむいさんiaudio9+を気に入ったので流通在庫があるうちにもう一台確保して
おきました。定期的に電池交換すればあと40年はゆうに戦える！！

●PCショップで販売されている廉価版のサンディスク製産業用マイクロSDカード
昨年サンディスク製の産業用microSDカードを紹介しましたがS.M.A.R.T(以下SMART)
が取れるものと取れないものがあるという検証も紹介しました。
今年に入って32GB版と64GB版のバルク版が安価で出回り出したので私もさっそく
一枚購入して動作確認をしてみました。

これが32GB版の廉価版です！

よく見るとSDSDQAF-032G-IとなっていてSDSDQAF2ではないことがわかります。
つまりこれはSMARTが取れない第一世代の製品である事を示します…が…！？

とりあえず第二世代の奴と並べてみました。
しまった…そっくりすぎてどっちがどっちか分からなくなった…

後ろから見た図です。
基板パタンに違いが見えますが製造プロセスで同じ世代でもいくらでも変わり
ますのでこれで判断することはできません…

とりあえずSDFormatterで更地にした後にベンチかけてみました。
読み書きは昨年の第二世代の奴と大差はないようです。

STM32のいつものでSDカードの情報を抜き出してみました

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Jul 17 2017

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 19019 kB/sec.

>ds 0

rc=0

Drive size: 62333952 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 5B 59 00 00 ED C8 7F 80 0A 40 40 C3 @..2[Y.......@@.

CID:

00000000  03 53 44 53 43 33 32 47 80 90 5C 11 05 01 1B 0D .SDSC32G..¥.....



Parsing SD CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :SC32G

Product HwRev      :8

Product SwRev      :0

Serial Number      :0x905C1105

DateCode.Month     :11

DateCode.Year      :2017



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 05 00 00 00 04 00 90 00 0F 05 00 00 ................

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 80 01 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Spec Version X  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

Available NS(or HS) Mode Only.

ぇええ…なんと2017年11月製ですって…
第2世代と並行して作っているということですか？？？？まぁいいや

とりあえず前回のようにSMARTの取得を試みましたが…
残念ながらCMD56に反応せず、フン詰まりになってしまいました…
読み書き性能は第二世代と互角ですがSMARTの取得ができずCMD56送信による
寿命判定ができないという結論になりました。

以上のような結果になりましたがSMART機能が必要なければパッケージ品よりも
安い値段で32GB・64GBの産業用のmicroSDが購入できてしまいますので寿命判定
機能はいらないけど耐久性のあるカードが欲しいという方にお勧めです☆

GNSSモジュールを試用する18 -みちびき四機体制記念-

2018年現在、日本製準天頂衛星｢みちびき｣は4機体制(うち一基は静止軌道)
となり試験運用されております。最も新しく打ち上げられたQZS-4(PRN195)もすでに
脱皮して試験稼働しているとの事でねむいさんもさっそくみちびきの受信状況を
ねむいさん特製GNSSロガーで確認してみました！

結果は後にしてとりあえず今回の走行ルートにあたる熊野古道の攻略もばっちり
進めてきましたのでしっかり見て行きなさい！

●2018.04.01 近畿自然歩道((道方～)村山～南島棚島)

前回の続きで南伊勢に向かうバスに乗るために伊勢市駅へ…
バスの待ち合わせのため近くの月読宮にお参りし道中祈願をします。

伊勢市駅からバスで1時間拷問タイム…
今回も三重交通の株主優待拳で費用を節約して移動です！

昨年末にも来た道方バスからスタートします。今回はR260をまっすぐ
西に向かいます！道路わきには満開の桜がお出迎えです！

阿曽浦口につきました。
はるか向こうには前回通過した南島大橋が見えますね★

今回の近畿自然歩道のエントリポイントはさらに西にあるの村山という
場所ですがかつての街道｢熊野脇道｣になるべく忠実に追ってみますが…
道が消滅して草かきわけで道路に出たりで前途多難です…

当面はR260の旧道に沿って"浦"めぐりをします。
桜と海の絶景が楽しめる良い季節です♥

そして熊野脇道に忠実に進み過ぎてまた迷う…
山桜が舞い散る中東宮トンネル上の古道を探し回った挙句
強引にR260に降りてしまうが…

おあつらえ向きに階段ができてるorz
無理に道なき道進まないでよかったやん

トンネル上の古道は今の整備され残されています。

東宮トンネルを抜けて奈屋浦に出ると川村瑞賢ゆかりの史跡が
多数みられます。

大仙寺です。ここも川村瑞賢ゆかりのお寺です。

街道は大山寺の東を北上し標高を上げていきますが…
道が消失してやがります…

はぁはぁ…R260をクロスして再び山の中へ…

なんだこの傾斜角！？
トカゲのようにへばりついて登る…

完全にシダで踏み跡も消えコンパスと地図を頼りに稜線を歩きます…
あ！先が開けてる！？

何とか林道に出ました…
(苦労しなくてももっと下からこの林道に沿って上って来れる場所があった)

再びシダラビリンスへ…ｺｺﾊﾀﾞﾚﾜﾀｼﾊﾄﾞｺ

8年間の道迷いの経験と動物的直感で無事に熊野脇道に復帰して
R260にも復帰…！さすが私…
ちなみに今回の行程でここが一番の難所でした…

R260はかつての街道をクロスしており
その地点には昔のお地蔵さんが整備されています。

山の中を抜け、河内川沿いに海に向かいます。
途中には倭姫命腰掛岩なる碑石が立っています。

海だ～～！私は戻ってきた！

さてここで問題発生です。
ここ神前浦(村山口)は近畿自然歩道｢竈方集落をめぐるみち｣の起点に相当する
場所なのですが忠実にルートを手繰っていると帰りのバスの時間にまったく
間に合わなくなってしまうため、一部はぶっちしてR260をぶっ飛ばします！１！！１！

てわけでショートカット開始！！
海沿いではないですが桜並木が美しく見てて飽きません♥

この地域はリアス式海岸のため結構上り下りがあり、旧街道は峠を何度も
越えたりしていました。再び近畿自然歩道と落ち合いますが熊野脇道は
「トンネルを直進(トンネル開削前は直登だったらしい)」のため、旧道の
近畿自然歩道に相当する峠道はぶっちですぶっち！

スーパーショートカットを駆使して栃ノ木竈に。
集落の入り口には役行者が祀られています。

自然歩道はトンネル直進ですが脇道はトンネル迂回です…
今回は迂回します…そして古和浦へ


古和浦漁港の対面の斜面には古和一族の碑が配座しています。

さらに旧国道に相当する古道を進むと北野神社に。
ここから標高を上げニラハマ展望台に向かいます。

3年前、超激曇りの最悪のコンディションにここにきてしまいましたが…
今はどうだ！？

oh....素晴らしい…♥
ちょっと霞がかかっていますがお日様が顔を出してくれました…

ニラハマ展望台も桜の花が満開ですね～☆

展望台を超えると海の水が思い切りきれいな棚橋に出ます！

新桑竈と棚橋竈がある南島棚橋バス停に到着。
バスの15分前に無事到着です…。ショートカットしまくりましたが
3年前は忠実にルート手繰っているので今回熊野脇道中心ですしセーフですセーフ！

少し時間ができたので棚橋竈を散策します。
南島棚橋バス停近くの廃校跡にできた道の駅はつぶれてしまったようです。
3年前は自販機もトイレも使えたのですが…

実は熊野脇道はここから新桑竈を通り姫越山を越えて錦に降りるのですが…
この南島棚橋バス停が付次の出発地点になるのですがトイレも自販機も
なくなった今ちょっと事前準備が必須のようです…。
ちょっと作戦を組み立てなおさないといけませんね。

そして桜吹雪舞う中帰りの町営バスに乗って道方へ…(一時間かかる)
4分くらい遅れてたので来ないのかと思ってビビりました…

ちなみに一時間かかる理由はR260を直進せず一旦いろんな集落を
めぐるためで地元の人の足な訳ですね～

そしてさらに1時間の拷問を経て伊勢市駅へ…バス移動のほうが疲れた…

特急待ち時間が少しできたので伊勢神宮の参道を散策します…

t　n　t　n　ﾓ　ﾏ　ｾ　ﾛ（ゼＥＲＯ）
とりあえず伊勢市に来たらこれです！

シモネタは置いといて熊野脇道もこれで大方つながりました。後は最大の難関、
姫越山を越えて錦に降り、紀伊長島まで向かうルートの攻略となります！

近畿自然歩道((道方～)村山～南島棚島)　GPSログ


そして肝心のみちびきは何基とらえられたか！？
GNGSVセンテンスからサテライトIDを抽出します！！

…

…

…ッッ！！！
っしゃぁっつ！！現行のにみちびき3機分捕捉成功ッ！！！

ちなみに静止軌道のみちびき参号機は捕捉できないのかというと、MT3333搭載
モジュールを使用したわたしのGNSSロガーではNOです。
三号機のPRNは199で残念ながらハードウエアレベルでQZSSの旧仕様のPRN193~197
しか対応していないため認識ははされないそうですorz
秋月のGNSSモジュール販売のQ&Aでも同様の回答があります。

まぁこれでもGPSのように捕捉できる衛星が3つも増えたことになるので
これでますます使い勝手が上がり頼もしくなる存在と思います！

だからメンテ頑張ってくださいJAXAさ～～ん！

いろいろ試す31(+今年の反省会)

●ねむいさんのもとに工業用SDカードが続々集まってくる！！！

12月上旬、ねむいさんの元にすこし早いクリプレが届きました･･･！
昨年紹介したS.M.A.R.T.(以後SMART)が取れる一般購入可能な貴重な工業用SDカード
のリピート購入です･･･！

そして今回はTG-4用に新手のカードも購入しました。MLCな64GBで、その名もUtility+
です！こちらも工業用の位置づけで工業用SDとしての機能は完備しておりもちろん
SMARTに対応しているそうです。

実際にTG-4に装着してUSBマスストレージから接続してDelkinDashBoardで
見たところです。以前のと同じようにしっかりとマスストレージからでも
SMART情報が取れてますね～♥

ちなみにベンチを取るとこんな感じでした。
工業用SDカードはデータの確実性を重視しているため読み書き性能に関しては
民生品よりかなり劣るものが多いのですがUtility+はそこそこ頑張ってる感じです。
実際のTG-4で使用したときも速度的な違和感はまったく感じませんでした。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Jul 17 2017

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 17484 kB/sec.

>ds 0

rc=0

Drive size: 125370368 sectors

Erase block size: 131072 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 5B 59 00 01 DE 3F 7F 80 0A 40 00 9D @..2[Y...?...@..

CID:

00000000  58 44 44 44 44 49 4E 43 30 00 03 96 E1 01 02 FF XDDDDINC0.......



Parsing SD CID Register

Manufacturer ID    :0x58

OEM/Application ID :DD

Product Name       :DDINC

Product HwRev      :3

Product SwRev      :0

Serial Number      :0x000396E1

DateCode.Month     :2

DateCode.Year      :2016



OCR:

00000000  C1 FF 80 00 ....

SD Status:

00000000  80 00 00 00 08 00 00 00 04 00 F0 02 00 AB 3F 00 ..............?.

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 45 84 03 01 00 00 00 .E......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Spec Version X  :0

SD Security        :4

SD Bus Width       :5



SD_Spec V4.xx!

Detected as SDXC Card!

Available UHS-I Mode.

今度はSTM32F4のいつものでSDカードの情報を読み出してみました。
2016年製ですね。

CMD56で読み出したところです。SMARTで取れるデータのフッタが昨年の
U331と同じようにCIDと同様の値が記述されてますね。

こんな感じでトレラン用のタフなデジカメにふさわしいタフな工業用SDカード
Utility+の組み合わせでこれからも厳しいフィールドを攻め込んでいきます！

●第三の刺客！SanDiskの産業用SDカード突如現る！
ねむいさんノーマークだったのですが2017年の初秋に一般のPCパーツショップで
SanDiskの産業用SDカードが安価な値段で出回っておりました。
こういったSDカードは一般に流通することはまれなので何らかの企業の大量購入品の
在庫処分でしょうか？なにはともあれありがたいことです。
容量のも8GB～64GB品があり32/64GB品は日本の正規代理店のパッケージ販売
なのでSanDisk特有のぱちもんの心配もほぼ無いかと思います。

出遅れた感じでしたがねむいさんも16GB品を入手せしめる事ができました。
SDSDQAF-016G-Iという型番です。

速度はUHS-Iに対応していますがまぁ良くある工業用グレードの速さですね～･･･
Utility+が早すぎるだけで工業用途にはこの速さで十分というところでしょうか。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Jul 17 2017

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 19279 kB/sec.

>ds 0

rc=0

Drive size: 31116288 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 5B 59 00 00 76 B2 7F 80 0A 40 40 13 @..2[Y..v....@@.

CID:

00000000  03 53 44 53 4C 31 36 47 80 61 6D 11 B0 01 15 63 .SDSL16G.am....c



Parsing SD CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :SL16G

Product HwRev      :8

Product SwRev      :0

Serial Number      :0x616D11B0

DateCode.Month     :5

DateCode.Year      :2017



OCR:

00000000  C1 FF 80 00 ....

SD Status:

00000000  80 00 00 00 04 00 00 00 04 00 90 00 0F 05 1A 00 ................

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 80 01 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Spec Version X  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

Available UHS-I Mode.

SDカード内の情報を拾ってみました。
なんと2017年5月製ですよぅ！しかもFatFsからの読み出しに関してはUtility+より
早いです･･･！

ところでねむいさんはいかに工業用といえども無闇に買うわけではありません。
このSanDiskのカードはなんとDelkin製のやつのようにSMART情報を取れるのです！！

Delkinの奴のように細かい情報は取れないのですが皆さんも気になる｢寿命に関する
ステータス｣は取得可能なのです！！！もちろん投げるコマンドはCMD56!
(※投げる引数はDelkinのとは違い0x00000001です･･･てか統一しようよこれ)

し　か　し　･･･

↑CMD56投げたところでデッドロックしてるorz

流出しているSanDiskのマニュアルをよく見ると8GBと16GB品の第一世代は
SMART積んでませんと明記されていた･･･32GBと64GBから･･･だと･･･
しかも32GB/64GB品はSDSDQAF"2"-032G-Iってなってて第2世代カードっぽい･･･
SMART積んでるの第二世代以降ですね。
(注：すでに第3世代のカードが流通しています。DigikeyやMouserで購入可です)

仕方が無いので32GB品の第二世代の奴売ってる店探してゲッツしてきました！！１！１

速度は･･･UHS-Iでは無くClass10なので読み書きともMAX約20MB/Secです･･･
でも書き込みはさっきの16GBと比べてダンチだからまぁいいですか･･･

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Jul 17 2017

>fg piano

rc=0 FR_OK

>do 1ftbt.mp3

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 16925 kB/sec.

>ds 0

rc=0

Drive size: 62333952 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 5B 59 00 00 ED C8 7F 80 0A 40 40 C3 @..2[Y.......@@.

CID:

00000000  03 53 44 53 43 33 32 47 80 3D 76 40 13 01 13 7F .SDSC32G.=v@....



Parsing SD CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :SC32G

Product HwRev      :8

Product SwRev      :0

Serial Number      :0x3D764013

DateCode.Month     :3

DateCode.Year      :2017



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 05 00 00 00 04 00 90 00 0F 05 00 00 ................

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 80 03 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Spec Version X  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

Available NS(or HS) Mode Only.

お約束のSDカードの情報も拾っておきます。
こちらも2017年製ですね～

お次はSTM32F7のSDMMCからCMD56を投げてDelkinみたいにSMARTが
取れるかどうか！いざ勝負！！

･･･！
帰ってきた512バイトのデータの中に｢SanDisk｣の文字が！！やった！！！！

ちなみに寿命を示すHealthStatusは9バイト目に相当します。
すでに1%使用されてるように見えますがこれはそうではなく｢0~0.99%消費された｣
ことを表すと記されています。
この値が100になったらデバイスはそれまで書き込んだデータを破壊しないように
読み取り専用になりデータ破壊から保護するそうです。

残念ながらSanDiskの奴はDelkinのようにUSBマスストレージからでもSMART取れる
仕組みはありませんがそれでも寿命推定ができるのは心強いことだと思います。
Linux系OSで物理バスにぶら下がったSDMMC持ったボードならCMD56直たたきで
見られるのでラズパイなんかでも活躍できると思います。

そんなわけで今年秋にPCショップで32GB/64GBのSanDiskの第二世代産業用マイクロ
SDカード買えた皆様、おめでとうございます！あなたのカードはSMART取れます！
逆にけちって8/16GBの第一世代の奴買っちゃったあなたはご愁傷様です･･･
まぁSMART取れないだけで物としてはバッチリ使えるのでしっかり
使い倒しまくってください！！！１１！！！

20180111追:
今度は32GB/64GBのバルク品が秋葉で販売しています！！が！！
型番から見て分かるようにこれは第一世代のSMARTが無いタイプですので、
SMART目当ての方は購入をしないよう注意してください！！
SMART積んでる奴はSDSDQAF2-***G-Iの第二世代以降の物です！
20180111追:

●ところでSPI互換モードでCMD56って効くの？
ねむいさん今まで組むのが容易なSDネイティブモードからしかCMD56の発行をして
いなかったのですがSPI互換モードからはCMD56は有効なのか？
年の瀬も迫るなかでねむいさんが公開しているFatFsの実装例、通称｢いつもの｣の
SPI互換モード用のSDカードドライバにCMD56を追加してみました。

ちなみにCMD56はSDネイティブモードではカードのイニシャライズが完了し
実際にカード内のデータの読み書きができるCMD17とかCMD24とかのコマンドが
通る状態になれば同じように使えました。SPI互換モードではステートマシンは
無いのですがとりあえずネイティブモードの挙動をまねてイニシャライズが
完了した直後にCMD56を送ってみました。

Delkin製はネイティブモードと同じく読み出しできました。

SanDisk製の奴も問題なく読み出しできました。

ねむいさんが確認した限りではCMD56はSPI互換でも問題なく通るのが確認されました。
一般的な電子工作でもSMART対応の工業用/産業用SDカードの恩恵をしっかり授かるこ
とができますね☆
ただし工業用でもSMART非実装ものや民生用の奴だとSPI互換モードでもやっぱり
フン詰まりになったり0xFFしか帰ってこないという結果になっています。

SMART取得を前提としてファームを組むならそのカード専用のドライバを作成する
ほうが無難かと思います。やはりねむいさんの希望はCMD56によるSMART情報取得が
規格化されて民生用でもSMARTが利用できるようになることです。
大事なことなので前回に引き続き2回アピールしました。

●毎年恒例反省会とねむいさんFAQ
Q:電磁波が飛ばします。受けとれっ(ﾋﾟｯ
A:ねむいさん昨年末から早々に手をつけて即効飽きてほったらかしにしたESP32で
　すが電磁波を扱っているせいかqiitaとか増田さんじゃないほうのはてなで技術
　風ぽゑむ書かれている方から(qiitaやはてなを利用している人たちはほとんどが
　まともな方でごくごく一部の人間がそういう特殊行動やってると信じたいですが)
　の抗議風自慢と思われる｢だからお前結局何が言いたいねん###｣といいたくなる
　怪文書いただくことが度々ありましてねむいさん最初は｢大変申し訳ありませんで
　したー！｣という内容(日本語訳で｢バーカ｣に相当する)の返事をしていたのですが
　社交辞令を真に受けたのかはっきり｢バーカ｣といわないとわから無いのか知りま
　せんが図に乗って私に無償で協力しろという方もいましてああもうこれかかわった
　時点でねむいさんの負けだなと感じて以後はそういう奴は存在しなかったことに
　しておきました。ねむいさんからはもう何も見えない。

　そんな事がありましてプロフィールの免責事項もちょっとお堅い内容に変えて
　おります。ついでに自分の襟も正して過去の自分の記事も読むと混乱するような
　変な内容や読んだ方に悪い印象を与えるような表現は正すように常に心がけてお
　ります。~~可愛がってるいないさんにオマパンさせるとかもってのほかです。~~

Q:(粋な写真もｽｲと添えつつ)しまかぜに乗って鳥羽まで行きましたよ☆
A:よかったですね＃＃＃
　ねむいさん近畿自然歩道の攻略で何度も近鉄に乗ってますが今に至るまで
　一度も乗れたことありません＃＃＃＃
　閑散期の平日狙えば少しはチャンスがあるのでしょうけど･･･

Q:(学生さんと思われる方から意図をぼかしつつ)｢***のソースコード書いて
　ください！！！！！｣｢***の回路図を描いてください！」等々･･･
A:メールのアカウントから推定して即効あなたのﾋ垢を見つけましたが
　まだ若いのに性癖全開なのは非常に期待が持てｒ･･･
　ｹﾞﾌﾝｹﾞﾌﾌﾝちょっと引きますよぅ･･･
　
　上の質問はちょっと極端ですがねむいさんより偏差値が20くらい上の子達から
　ねむいさんの知能を大幅に超える難しい専門的な問い合わせもびしばしもらうので
　すがねむいさん脳細胞どんどん死滅していっていないさんの今日穿いてるぱんつ
　のことしか考えられなくなっていく段階なのでもうちょっと手加減してくだち。

Q:フルブリッジドライバの下段アームのFETだけ壊れるんですけど
　壊れないようにしてください！！(←急遽当日になって)
A:(こいつまたかＹＯ！)ええいうるさい
　ゲートに抵抗でも入れてなさい！！！！

Q:スマホから見たら画像の読み込みばっかでめっちゃ通信量食うんですけど
A:ね　む　い　さ　ん　ま　だ　ガ　ラ　ケ　ー　Ｄ　Ｅ　Ａ　Ｔ　Ｈ　！

Q:ていうかそろそろねむいさんもスマホに換えましょうよ
A:実際どうしましょうかねぇ･･･キャンペーンがあったらガラホにでも
　移ろうかと思ってます。

Q:(パッチアンテナの面を地面に向けるように実装して)Gms-g9ってたいした捕捉
　性能ないっすねｗやっぱりu-bloxっしょ！(ｲｶｽ思想に取り憑かれた顔で)
A:(正気でやってるのかこれ･･･怖い･･･)
　が、眼科行った後メンタルヘ！

Q:ウンチーコングって知ってるぅ?
A:ウンチーコング･･･それはﾎﾟﾒﾗﾆｱｯｸ繊細空間が展開されたときのスレッド内の
　住人同士の仲が険悪になりﾚｽﾎﾟﾝﾁバトルが勃発せしめんとした際に発動して
　5cmにﾎﾟﾒﾗﾆｱﾝ出来たことにより無益な戦闘によって血を流すことを避け場を
　清らかに鎮めるための対繊細特化型概念である。こと虹裏においては平和的
　に発動される概念だがほかのコミュニティにおいては猿系のキャラクターが
　戦いにおいて敗北した際にギャラリーが連呼して敗北者にさらに精神的にダ
　メージを負わせるといったまったく逆の概念で使用されていることもあるの
　で留意すべし。また、冥府神がほかのキャラクターにその意味を無闇矢鱈に
　問うといった意味不明の行動も見られたがこれは第0話にて彼の行動の真実が
　明らかになっている。話を虹裏に戻すと猿空間においては｢座敷犬(ポメラニ
　アン)のくせに獅子(ライオン)の気持ちなんてわかるわけねーだろっ！｣
　というせりふとともに顔面パンチをｺﾞｯされる場面が見られ、ウンチーコングを
　発動するまもなくﾎﾟﾒが処分される技術も確立されだしている。
　やっぱりかませはかませだった。
　
Q:｢ねむいさん｣で検索するとサジェストに必ず入院とでるのですが何か大病でも
　されたのですか？
A:私のこと病院送りにしたい奴らの単なるサジェスト汚染ですね～！多分
　まぁ｢ねむいさん FX 必勝法｣とかでないだけ幾分マシですが･･･

Q:画像が見えなくなってる昔の記事の画像も早く復活してほしいのですが･･･
A:(う"･･･今年秋から差し替え作業サボったままだった･･･)

ぇっとあのその来年もがむばります！！

2017.12.31 Sunday
11:48
ネムイ・トリノミアス
MISC
-
-

いろいろ試す29

やばいっす･･･もう8月ですよぅ･･･
例のDropBox画像差し替えの進捗状況ですがここ最近のSTM32関連はほぼ
修正が終了し、これから過去の東海自然歩道関連の膨大な差し替え作業が
待っております･･･
これが一番きついかもしれませんが今が耐え時、がむばります！

●村田製作所が1uF未満の1608サイズのチップコンデンサ作るの止めるってよ
ねむいさんのぶろぐを見られている諸兄の方々なら7月第2週の初頭の時点で既にご
存知とは思いますが･･･ねむいさんもこの報を聞き"品の悪いギャグだ"と思っていま
したが詳細な説明を聞くにあたりマジになっているのが分かりました。

2017年現在、スマホが隆盛を極めておりますがそれに使用される0603サイズ以下の
チップセラコン大大大増産に対応するため1608用のラインを廃止することに決定
したそうです。一応2018年上旬までは発注に対応するそうですが納期がかなり掛かる
ことが必須で引いては村田製作所以外のメーカの製品の模索、ロットの確保のため
の争奪戦が既に始まっている次第です。

国産かつ信頼性という点で日本国内では村田が抜きん出でていましたがここにきての
生産終了予告に国内のメーカ、特にダウンサイジングが進んでいない工業用製品の
メーカとかは超困るはずなのですが容赦なくぶった切られております。切られました。
ちなみにNintendo Switchを販売し飛ぶ鳥を落とす勢いの任天堂すらも情け容赦なく
切られてしまった、と、世の趨勢はそれ程スマホの生産競争に向かっている、と、
桂川のほとりで昼寝をしていた猫が嘆いていました。上二行はねむいさんのコメント
では無くあくまでも桂川のほとりで昼寝をしていた猫のOpinionなので悪しからず。

で、代替品ですが国内ではやはり2012サイズはもちろんの事1608の品種はどこも生産
から撤退しており(1uF以上は除く)海外メーカから調達するしかないのが現状のです。
ねむいさん的には釜屋電機が国内ディストリビューターとなっている~~Walsin製~~の物が
丁度隙間産業的に村田の抜けた穴を埋めるのではないか？と予測しております。
電子製品の米とも言える最も大量に使用されているバイパスコンデンサ用の0.1uFの
物が村田が去った後どこが日本国内のパイを掻っ攫っていくのか？
ものの一年もすればその答えが分かると私は予測します。
ていうか1005サイズも量産が続くかどうか怪しいです。これもしっかり対策立てて
おいたほうがよいと思います。基板を0603で起こしなおすか、代替メーカを探すか。

そしてホビイスト的な観点からすれば現在秋月に流れている1uF以下の村田製の奴
は(1608サイズ自身が怪しいですが)2020年にはほぼ消失し、別の会社の製品がライン
アップに収まるはずです。まぁホビー用途なら信頼性の保証は自分もちなので自分が
信ずるモノならばなに選んでも自己責任で終わる話だと思います。

20230920追:
2017年時点では上記の通り1608サイズ消滅の危機がありましたが、
村田製作所は車載用向けMLCCにおいては2023年現在でも1608サイズの
製品の供給を続けております！！！！(いろいろ圧力あったんだろうな…)
20230920追:

●GNU Tools for ARM Embedded Processorsが定期バージョンアップ
7月頭にARM本家から配布されるようになったARMむけGCCコンパイラが
"The 6 2017q2"にアップデートしておりました。
前回からの目だった変更点は･･･

* Advanced SIMD-optimized memchr implementation in newlib
くらいでしょうか？purecodeが実装されてから効率がさらに良くなった感がしますが
いつもののコードを使ってとりあえずビルドログの新旧比較してみました。

Built Informations:

USING_SYSTEM = BARE_METAL

USING_DISPLAY = USE_OTM8009A_DSI_TFT

USING_DEVBOARD = USE_STM32F769I_DISCOVERY



Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 726616	      0	 726616	  b1658	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

 724016	   2600	2379504	3106120	 2f6548	main.elf

main.elf  :

section               size         addr

.text              0xb0ba8    0x8000000

.ctors                 0x0    0x80b0ba8

.dtors                 0x0    0x80b0ba8

.ARM.exidx             0x8    0x80b0ba8

.data                0xa28   0x20020000

.itcm                 0x80          0x0

.bss                 0xb20   0x20020a28

.heap                  0x0   0x20021548

.dtcm              0x10454   0x20000000

.stack                 0x4   0x20010454

.ethram                0x0   0x2007c000

.batram                0x0   0x40024000

.extram           0x233f78   0xc0000000

.qspirom               0x0   0x90000000

.comment              0x7f          0x0

.debug_aranges      0x3fd8          0x0

.debug_info       0x141d2c          0x0

.debug_abbrev      0x1d619          0x0

.debug_line        0x48aa5          0x0

.debug_frame       0x12d58          0x0

.debug_str         0x18c38          0x0

.debug_loc        0x10b358          0x0

.ARM.attributes       0x35          0x0

.debug_ranges      0x176c8          0x0

Total             0x5f076e

新(arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors 6-2017-q2-update) 6.3.1 20170620 (release) [ARM/embedded-6-branch revision 249437])

Built Informations:

USING_SYSTEM = BARE_METAL

USING_DISPLAY = USE_OTM8009A_DSI_TFT

USING_DEVBOARD = USE_STM32F769I_DISCOVERY



Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 726952	      0	 726952	  b17a8	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

 724352	   2600	2379504	3106456	 2f6698	main.elf

main.elf  :

section               size         addr

.text              0xb0cf8    0x8000000

.ctors                 0x0    0x80b0cf8

.dtors                 0x0    0x80b0cf8

.ARM.exidx             0x8    0x80b0cf8

.data                0xa28   0x20020000

.itcm                 0x80          0x0

.bss                 0xb20   0x20020a28

.heap                  0x0   0x20021548

.dtcm              0x10454   0x20000000

.stack                 0x4   0x20010454

.ethram                0x0   0x2007c000

.batram                0x0   0x40024000

.extram           0x233f78   0xc0000000

.qspirom               0x0   0x90000000

.comment              0x7f          0x0

.debug_aranges      0x3fd8          0x0

.debug_info       0x141e1b          0x0

.debug_abbrev      0x1d619          0x0

.debug_line        0x48aa5          0x0

.debug_frame       0x12d58          0x0

.debug_str         0x18c3d          0x0

.debug_loc        0x10b365          0x0

.ARM.attributes       0x35          0x0

.debug_ranges      0x176c8          0x0

Total             0x5f09bf

古(arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors 6-2017-q1-update) 6.3.1 20170215 (release) [ARM/embedded-6-branch revision 245512])
text領域が若干絞られていますね。

mapファイルを比較してみるとvprintf関連が若干異なるようです。
これが"Advanced SIMD-optimized memchr"の成果かも知れませんね。

新

旧
jpegファイルレンダリング比較行ってみましたがパフォーマンスにも余り影響は
無いみた･･･あっ！
なんか旧版だとxprintf使った表示がおかしくなってる！！

･･･と思ったらuSecタイマーで使用してるTIM5の最上位ビットを"UIF bit"のコピーと
して使用する設定になっていてCNTレジスタの値が変に読み出されていただけでしたorz
なんという罠orzこれSTM32F7特有の機能みたいですorz今まで気付かなかったorz
新板でもリセット後経過時間次第で同様の表示不具合が出ることを確認orz
ていうかデータシートしっかり読んでなかった事が露呈しました･･･猛省･･･。
8月1日版のF7向けサンプルでは修正しておきますのでよろしくお願いします。

新

旧
改めて新旧比較･･･
やっぱしパフォーマンスにも余り影響は無いみたいですね～～

●A1クラスのmicroSDカードの実力を試す

ボーナスとか言うものはなかったですけど費用を捻出してねむいさんもついに手に
入れましたA1 Class対応のmicroSDカード！！！
もちろんVideo規格のV30にも対応した最新版です！！！

それでは早速いつものカード情報を抜き出して見ました。
●Sandisk　ExtermePRO microSDHC 32GB SDSQXCG-032G-GN6MA

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Jul 17 2017

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 19632 kB/sec.

>ds 0

rc=0

Drive size: 62333952 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 5B 59 00 00 ED C8 7F 80 0A 40 40 C3 @..2[Y.......@@.

CID:

00000000  03 53 44 41 47 47 43 44 80 61 BB 43 93 01 16 03 .SDAGGCD.a.C....



Parsing SD CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :AGGCD

Product HwRev      :8

Product SwRev      :0

Serial Number      :0x61BB4393

DateCode.Month     :6

DateCode.Year      :2017



OCR:

00000000  C1 FF 80 00 ....

SD Status:

00000000  80 00 00 00 05 00 00 00 04 00 90 00 0F 05 3A 1E ..............:.

00000010  00 08 00 00 00 01 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 84 43 00 00 00 00 .5.C....



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Spec Version X  :1

SD Security        :3

SD Bus Width       :5



SD_Spec V5.xx!

Detected as SDHC Card!

Available UHS-I Mode.

>

2017年6月製の出来立てﾎﾔﾎﾔカードです♥
SD_Spec V5.xxとなっており、後々販売される"A2 Class"のカードではV6.xxに上がる
見込みとなっています。連続読み出しもそこそこ早いですね～。

ちなみにA1 Class(Application Performance Class 1)はランダムアクセスリード及び
ランダムアクセスライトの下限値が定められており、スマホなどのストレージの細かい
ファイルの読み書きに特化した規格となっています。つまりﾁﾏﾁﾏ読み書きに強いカード
を証明する規格な訳です。

それを確認するために今度はPCからベンチマークを取ってみました。
そして･･･

･･･
なんか4kランダムライトが異様におそいんですけぉ･･･

それじゃ昨年購入したV30表記のみのカード(SDSQXVF-032G-GN6MA)

･･･
ﾁﾏﾁﾏ書きめッちゃ早いやん･･･PROじゃないほうのExtremeなのに･･･

じゃ･･･じゃぁ2012年に購入した8GBの昔のExtreme(SDSDQXP-008G-J35)!

･･･
ﾁﾏﾁﾏ書きめッちゃ早いやん･･･PROじゃないほう(ry

ちなみに測定に使用した機材は全て同一の物なので相対的に性能が評価される
ため、リーダの性能が云々とかは理由に出来ません。もちろんテスト前にSD Formatter
のクイック削除で更地にした上で測定を行っております･･･

･･･
ま、まぁ直線番長度合いは旧版のカードと比べて仏契(ぶっちぎり)ですし多分ベンチ
ソフトじゃみえてこない所の･･･ぇっと体感速度とかのパフォーマンスが沢山アップ
しているのかも知れませんと思いたいです(脂汗)

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コアの奴が手に入ったら
またレポートさせて頂きます！

STM32F7を使ってみる15 -工業用SDカードからSMART情報をスマートに読み出そう-

あれ？ESP-WROOM-32が秋月から発売されて絶好のチャンスなのに
ESP-WROOM-32の記事書かないのですって？
あああれね…去年の時点で飽きました･･･今更になって弄ってるとか時代遅れ
ですよぅ！(挑発

今回はS.M.A.R.T.(以下SMARTと記載)対応のSDカードからSMART情報を読み出して
みます。別にF7じゃなくてもよいのですけど次回以降のネタに繋がる内容なので
しばし御静観願います。
今回もSTM32F746G-Discoveryを使います。

工業用のSDカードの中にはSSDやHDDのようにSMARTの情報が取れる希有なものが
存在しております。残念ながら一般に購入出来る民生向けSDカードではその
ような機能は搭載されておらず、SMART対応どころか工業用SDカードも入手が
ごく限られております。もちろん値段も民生品に比べ極めて高価です。

なんで高価かと言うとカードの動作に関する"信頼性"を保証しているからに
つきます。皆さんご存知の通り2017年現在市販で流通しているSDカードは明記が
無い限りはTLCタイプのNANDフラッシュメモリが使用されており、TLCという
のはSLCやMLCに比べて大容量が取れる割にデータ保持のための寿命が短い、
また書き換えできる回数も極端に短いという代物となっております。

一方工業用SDカードは4GB以下はSLC,それ以上の容量でもMLCを保証しており
(容量を犠牲にして疑似的にSLC風の動作をするpSLCやaMLCなんで奴もありますが)
さらにSDカード内コントローラのファームウェアもデータ保護に特化した
特別となっております。たとえばECCチェック機能とかパワーダウン
プロテクションとかオートリフレッシュ機能とかバッドブロックマネージメント、
ダイナミック+スタティックウエアレベリング等々いろいろありますが、実は
これTLCカードを世に出すために必須の技術でそれが耐久性がもともと高い
SLCやMLCを使用した工業用製品にフィードバックされて最強に強まった
信頼性を謳うわけです。

というわけでこれらの機能実装は最早当たり前となった今、カードの健康情報を
把握するための機構を仕込む事が新たな付加価値として注目されており、
各社でSMARTもしくは独自の寿命診断を組み込んだ工業用SDカードが販売
されております。

で、われわれホビイストが問題となるのはその工業用SDカードの入手から
始まりさらにSMART情報を取得するための"情報"を入手し利用せしめるまでに
多くの壁があることです！

まずDigikeyやmouser,RSの海外在庫くらいからしか工業用カードの入手法が
日本国内からではまず困難で、さらにSMART対応と謳っていてもカタログの
隅っこに(※オプション対応)とか書いてあったりして高い金出して購入したのに
目当てのSMART機能が実は搭載されてなかったとか悲惨なことがほとんどです。

それでやっと入手にこぎつけたとしてもSMART情報を取得するための手段や
ツールは公開されておらずメーカに直接問い合わせることになりますがほとんどの
場合対企業間の問い合わせにしか対応してなかったり(もちろん個人事業主として
問い合わせてもTHE・シカト)、SDAのライセンスに加入していないと情報を
渡すことができないよなどつっけんどんの反応しかもらえません。

ねむいさんも方々に手を尽くしましたが個人レベルではなしのつぶてて困り果て
ていましたが灯台下暗し、DELKINというメーカの工業用SDカードを扱っている
代理店が日本国内に存在しておりました。こちらは在庫があれば
一枚から対応(無ければ受注生産20枚単位)というホビイストにもうれしい
対応でしたので早速1GB品を注文し、ゲッツしました。

でかいDELKIN箱に小さいMicroSDが対照的です。

今となっては微々たる容量の1GB、見た目も普通のMicroSDカードですが…
このDELKINのU331というシリーズは中身は某粉飾決算にチャレンジしたおかげで
倒産寸前の日本メーカのSLC型NANDフラッシュが使用されております！
~~なにルネサスより先に死んでんだよ東芝！！１１！１１！！１！！！！！！~~
動作温度範囲もやたらと広くて-40~+85度まで保証しております。

ひとまずUSB接続のカードリーダーに接続してパフォーマンスを見てみました

規格的には"2GB以下のSDSC"に位置するカードなのでUHS-1とかには対応しておらず
理論上最大でも25MB/Secの転送スピードとなりますがマイコンで使用する限りでは
ハイスピードモード(最大SCLK=50MHz)に対応さえしてれば全く問題ないです。

SMART情報をPC経由で取得するために"USBカードリーダ"を用いて
"DELKIN DashBoard"なるアプリケーションを使用する必要があります。
ねむいさんの持っているTranscend製のUSB3.0カードリーダーは無事に
SMART情報を読み出すことができました。やったぜ！
どういう理屈でSMART読み出してるかしらないけど(伏線)

ちなみに"DELKIN DashBoard"の動作保証しているDELKIN製カードリーダーは
上記のねむいさんのもってるTranscendのと全く同じチップが使用されてます。

お次はSTM32を使って動作させてみます。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Dec  6 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 14338 kB/sec.

>ds 0

rc=0

Drive size: 1947648 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Byte)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  00 5E 00 32 5B 59 A3 B6 FF FF FF 80 0A 40 00 6D .^.2[Y.......@.m

CID:

00000000  58 44 44 44 44 49 4E 43 30 6D 6D D4 59 01 0C 49 XDDDDINC0mm.Y..I



Parsing SD CID Register

Manufacturer ID    :0x58

OEM/Application ID :DD

Product Name       :DDINC

Product HwRev      :3

Product SwRev      :0

Serial Number      :0x6D6DD459

DateCode.Month     :12

DateCode.Year      :2016



OCR:

00000000  80 FF 80 00 ....

SD Status:

00000000  80 00 00 00 00 00 00 28 03 03 90 02 00 AB 00 00 .......(........

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 25 80 00 01 00 00 00 .%......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Spec Version X  :0

SD Security        :2

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDSC Card!

Available NS(or HS) Mode Only.

>

先ずはいつものでSDカードの情報を読み出してみました(これだけSTM32F429を使用)
2016年製！
ATPの工業用カードでもそうでしたが現在はW/R性能はSDカード内コントローラの
ファーム次第なのでSLCとはいえ転送速度がめちゃくちゃ早いとは言えません。
どちらかと言うとSLCを使う理由は速さよりもデータの確実性を求める方向に概念が
遷移していると感じます。

そしてついにSTM32F7-Discoveryを使いSMART情報の読み出しに掛かります！
このDELKINのカードはSDカードに昔から存在するCMD56という"汎用コマンド"を
用いてSMART情報の取得を行います。SMART情報を取得する方法は各社バラッバラで
門外不出の所もありますがDELKINは"CMD56でSMART採れるYO!"と公言している
ためかなりフレンドリーと感じます。

この"CMD56"は引数によってデータの受信送信を変えることができるコマンドで
CMD17等のシングルブロック転送と同様最小512Byte単位でやり取りをおこないます。
DELKINカードにおいては特別な引数で、ある一定の順番で、CMD56の送受信動作を
行うことにより目的とするSMARTの情報を得ることができました。

↓

DelkinDashboardとCMD56で読みだしたSMART直値をUARTに吐かせて値の
比較です。カードに何らかの書き込み動作を行うと電源再投入時にDashboardの
"TotalPowerupCount"に相当するSMART直値が更新されているので正しく
SMARTが読めていると判断しました。
ところで具体的にどうやってCMD56投げたのと知りたい方がいると思いますが
対価を払って得た情報ゆえこのぶろぐ上で詳しく公表できません
が…
…おや？このデータシートDELKINと関係ないのになんだかそっくりだー(棒読み

詳しくは言えませんが512バイト分のSMART情報のフッタに相当する部分の
データがCIDの情報と一致しておりました。何かのvalidationに使うので
しょうか???????(棒読み
まぁあまり重要な情報ではないでしょう(伏線

このDELKINカードを選んだ理由は拙作のSTM32Primer2を使ったGNSSロガーの
信頼性向上につきます。一度Primer2の筐体中に組み込んでしまうと構造上
ケースの中にカードが封印されてしまうため簡単に取り出せなくなるのでSDカードの
寿命診断を何らかの形で外部から行いたいと思いSMARTが取れるカードを選んだ…
と言う経緯です。
次回のちょっとネタバレになりますがこのGNSSTrackerのマスストレージモード
でもDelkinDashboardを使いSMARTの取得に成功しています。
なんでCMD56発行してないのにSMART採れるんでしょうね(意味深

願わくばSMARTを利用した寿命診断機能がSDAで正式に規格化され、民生用の
SDカードでも気軽に寿命診断できる素敵な時代が来るようになることを願います。

だからSDAの中の人のPanasonicさん頼みますよ！
なぜか不自然なくらいﾊﾟﾅ推しのねむいさん。

ここでねむいさんFAQ特別編
Q:ねむいさんねむいさん、確実にSLCのカードを見極める方法を教えてくださいっ！
A:

　SLCってカードにでかでかと書いてあるカード選べばＯＫです☆

いろいろ試す26

今回もSDカード中心です。

●ついに発見！Transcendの4GBのSDカード

当初SDHCをつかまされてしまった私ですがSDコンパチブルな奴をついに見つけ出し
ました！！というかebayで新たに発売開始(？？？)されていました！

SDHC版と比較…ものすごく似てるけど色が微妙に違う…知らなかったこんなの…

一応SDカードの情報を抜き出してみました(あえてSDv1による初期化です)。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Nov  8 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 14597 kB/sec.

>ds 0

rc=0

Drive size: 7788544 sectors

Erase block size: 512 sectors

Default r/w block size: 2048 bytes

Card type: SDv1

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  00 0E 00 32 5B 5B 03 B6 9D B7 FF 80 0A C0 00 21 ...2[[.........!

CID:

00000000  74 4A 45 53 44 43 20 20 10 3C D5 6B 7B 00 08 AB tJESDC  .<.k{...



Parsing SD CID Register

Manufacturer ID    :0x74

OEM/Application ID :JE

Product Name       :SDC  

Product HwRev      :1

Product SwRev      :0

Serial Number      :0x3CD56B7B

DateCode.Month     :8

DateCode.Year      :2000



OCR:

00000000  80 FF 80 00 ....

SD Status:

00000000  80 00 00 00 00 00 00 20 03 03 90 00 08 05 00 00 ....... ........

00000010  00 00 00 00 00 00 00 00 00 53 4D 49 00 00 00 00 .........SMI....

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 0F 17 00 04 00 00 20 00 00 00 00 00 00 00 ........ .......

SCR:

00000000  02 25 80 00 00 00 00 00 .%......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Security        :2

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDSC Card!

製造年月が2000年とかなってますけど思い切り嘘ですね。2016年産でから。
一応製造元はTranscendの製造協力会社のものになっており真贋の方は分かりかね
ますが…一応PC上で容量チェックを行った所、4GB分正しく読み書きが可能でした。

SDHCだった方のカード情報はこんな感じです。



FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Nov  7 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 21688 kB/sec.

>ds 0

rc=0

Drive size: 7812096 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5F 59 00 00 1D CC 7F 80 0A 40 00 D5 @..2_Y.......@..

CID:

00000000  1C 53 56 53 44 43 20 20 10 01 D2 00 BC 00 82 DB .SVSDC  ........



Parsing SD CID Register

Manufacturer ID    :0x1C

OEM/Application ID :SV

Product Name       :SDC  

Product HwRev      :1

Product SwRev      :0

Serial Number      :0x01D200BC

DateCode.Month     :2

DateCode.Year      :2008



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 02 00 00 00 03 03 90 00 08 05 00 00 ................

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 00 00 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :0

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V2.00!

Detected as SDHC Card!

れっきとしたTranscendの奴ですね。

ちなみに読み出し速度は圧倒的にSDHC版の奴の方が上でしたorz

このSDコンパチブルなTranscendのはSDv1の初期化でバイトアクセスとなり、SDv2の
初期化ではブロックアクセスとなりました。この辺以前紹介した4GBカードたちと同じ
ですね。(ていうか同一の会社がガワだけ別で中身同じの作ってそうです･･･。)

そしてそのうちの前回紹介した4GBのドイツカードなのですが端子の埃をふき飛ば
そうとエアダスターを吹き込んだからカードのプラスティックの隙間に圧縮空気が
入り込み、内部から分解してしまいましたorz貴重な4GBカードがッ…！！！

とりあえず分解して荼毘に付しました。基板がこんなにペナッペナです。工業用の
堅牢な奴に比べて明らかに強度的に弱いですね。値段も安価なのでいたしかたなし
なのですけど。

●CMD1の初期化はどのカードまで可能なのか！？
12月頭にCMD1による初期化がSDカードのライセンスの影響を避けるために必要だと
えらそうに言ってしまいましたので今回は実際にCMD1のカードで初期化が通るん
かいな？という疑問を実際に動作させて検証していきたいと思います。

使用するカードは256MB～4GB(SDHCじゃない奴)までの容量のSDカードです。
これは春先にひたすら読み込みまくった時の連中をセレクトです。

前回同様STM32F4-DiscoveryのSPI互換モードでSDにアクセスするほうのいつものを
使い、ChaN師謹製の初期化ルーチンからCMD1による初期化のみ残したプログラムを
動作させてファイラーが起動してディレクトリが見えたら初期化成功とします。
…
結果ですがATPProMAX 1GBのminiSDを除きすべてCMD1による初期化が成功しました!
もちろん成功したカードの中には冒頭で紹介したSDこんぱちなTranscendの4GBの
カードも含まれております。

もちろん2016年製造のPanasonicの工業用SDカードもCMD1の初期化が通ってます！
こいつはCMD8の初期化も通るんですよね～。CMD8で通っても4GB以下なのでバイト
アクセスになります。

ちなみに私が持っているeMMCはSPIモードが既に削除されている品種のため、どう
がんばってもSPIモードに突入することができずだめでした。SDカードと同一の形状を
保って方のいるMMCplusなどのv4系カードなら問題無いです。

お次はネイティブモードでCMD1の初期化だけを残した奴を試してみましたが…。
･･･
結果は全滅orz

Argumentとか0にして見ましたが何してもどのカードでもタイムアウトで全滅ですorz
ネイティブモードだとCMD1は通らないのか！？

答えはSDIO Specificationに有りました。以下13ページ目のフローチャートを抜粋。

…
･･･
ネイティブモードが相手ならMMCの例外な実装によってSDカードがたまたま
偶然に動作せざるを得ない！１１！！１(CV:リョウ・サカザキ)

♥ねむいさんのおまとめ♥
電子工作においては現在も入手可能な4GB以下のSDカードに対してSPI互換モードで
CMD1による初期化のみでカードを動作させることは十分可能であり、この方法ならば
SDAのライセンシーにも全く抵触しません。

CMD1が確実に通るカードの中でねむいさんの激押しは
・TOPRAM製4GB
・ドイツ製4GB
・Transcend4GB
この３種の4GBカードです！値段も安いですし4GBもあれば十分でしょー

それ以外の方法(SDネイティブモードによるアクセス、もしくはSDHC/SDXCカードを
使う)をどうしても施行したい場合はソースコード中にMMCが実際に動作できるCMD1
による初期化を残しつつMMCまたは互換カードの例外的な実装によってたまたま動作
しているように見せかけてあげればよいと思います。よくない。

●SD Specfication Version5のカード

ﾃﾚｯﾃﾚｯﾃｰﾃｯﾃｰ　ﾃﾚﾚﾚﾚｯﾃｰ(ﾃｭｨｰｰｰﾝ)

Ｖ！Ｖ！Ｖ！
もういいわ

2000円ちょっとで売っていたのでつい購入してしまいました。以前私はロゴだら
けや！って予言しましたが本当にロゴだらけですね。
V30のビデオ規格のロゴが付与されたものがSDSpecV5のカードの証です。
これにA1ロゴとかもつく予定なのでさらにカオス状態になりそうです。

ねむいさんの予想では山盛りになってしまった性能表記のロゴのすべてを包括する
新たな統一ロゴが来年あたりに登場すると思います。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Dec  6 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 19787 kB/sec.

>ds 0

rc=0

Drive size: 62333952 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 00 ED C8 7F 80 0A 40 40 C3 @..2[Y.......@@.

CID:

00000000  03 53 44 53 45 33 32 47 80 A4 38 40 2C 01 07 C7 .SDSE32G..8@,...



Parsing SD CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :SE32G

Product HwRev      :8

Product SwRev      :0

Serial Number      :0xA438402C

DateCode.Month     :7

DateCode.Year      :2016



OCR:

00000000  C1 FF 80 00 ....

SD Status:

00000000  80 00 00 00 05 00 00 00 04 00 90 00 0F 05 3A 1E ..............:.

00000010  00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 84 43 00 00 00 00 .5.C....



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Spec Version X  :1

SD Security        :3

SD Bus Width       :5



SD_Spec V5.xx!

Detected as SDHC Card!

Available UHS-I Mode.

おやくそくのSDカードの情報を抜き出してみました。
予想通り確かにSD_Specは"5"を示しておりますね★

いろいろ試す25

今回はSDカード関連中心です。

●SDカードの規格がバージョンアップ
SDカードの規格(Specification)が今年夏にV5.00にバージョンアップしています。

主な変更点は4Kや8K等の高精細映像録画に対応した"Video Speed Class recording"
略して"VSC"の追加です。これに対応したカードは｢V6｣とか｢V30｣とかの転送MB数を
保証する"V値"の付いたロゴが付きます。
既存の速度規格もすべて付与されるのでカードはロゴだらけのゴテゴテ状態となっ
ちゃいますね…実際そうなってるようですけど。
市場には現実的に購入可能な値段で既に出回っております。私も金銭的に余裕が
出来たら買って試してみるつもりです。

また、SCRレジスタのSDSpecにはV5.0を示す値が新たに付与されています。V値が書か
れたロゴが付いているカードはこの値が"5"になるはずです。私のいつものの今月の
更新でこちらにも対応していますので、既に入手した人は試してみてください。

20161201追:
ねむいさんいますぐSDAのサイト見てください！！！ってメール頂いたのですが
お昼にSDAのサイト見たら早くもSDSpecV5.1のアナウンスがされていました…。
今度は"Application Performance Class"の追加だそうで…これに対応した
奴は新たにA1なるロゴが付くようです。
もうロゴだらけですよぅ！！！！！

●ところで電子工作でSDカードを使用する際のライセンスの件について
SDカードをシステム用ストレージとして使用する組み込み機器の開発の際に必要な
ライセンスについて、SDAの中の人(具体的にはP＠n＠s○nic(＠と○は伏字)の人)に
確認を取ることになりました。それのついででさりげなく電子工作においてSPI互換
モードでSDカードを動作せしめる際のライセンシーの扱いについても尋ねてみました。
巷でよく言われている｢SPIモードでSDカードを動かす時はSDAとライセンス契約を結ぶ
必要はあるのか！？｣っていう定期的に話題に持ち上がるもやもやしたアレの事です。

本当は枝葉末節の細かい条件に至るまで尋ねたかったのですが、そこまでやって
しまうとさすがにコンサル料を取られてしまいそうなのであくまであたりさわりの
ない範疇で"さりげなく"です。

ね｢そいえばSPI互換モードだとライセンス不要とかトラ技とかにたまに書いて
　　あるんですけどやっぱSPI互換モードでSDカード使う場合でもちゃんと契約
　　結ぶ必要ってあるんですよね？」

P「はい」

…
…
ねむいさん藪をつついて蛇どころかオロチだしちゃいましたごめんね(ﾃﾍﾍﾟﾛ
外人さんも正攻法で尋ねた方がいたみたいで同じ回答をもらっています。

別ジャンルですが今年頭に似たようなことやった人がいてちょっとした騒ぎに
なったケースがありますね。

そもそもの｢SPIモードなら云々｣経緯ですがこれに｢2GBまでのカードなら云々｣
｢SPIモードはCPRM使えないから問題ない｣とか尾ひれが付いたりした文章も
散見されますがMMCとSDカードの歴史を掘ってみると以下の経緯で現在の概念に
変質していったと私は推測します。

①MMC登場！SPI互換モードも搭載！MMCホストはロイヤリティ不要！
　　　　　　　　　　　↓
②MMCをネイティブモードで動作させる際はお金払って動かし方教えて
　もらう必要がある(2016年現在は｢あった｣)。
　　　　　　　　　　　↓
③だけどSPI互換モードについては当時すでに解析されたり一部情報公開
　されたりでホビイストにもMMCの動作方法が知れ渡っていった。
　　　　　　　　　　　↓
④てわけでMMCをSPI互換モードで動かすだけならお金の心配は不要！
　　　　　　　　　　　↓
⑤SDカード登場や！MMC互換のインターフェースやけどSDホストの開発時
　とかSDホスト採用した製品とか売るときはしっかり銭取るで！
　　　　　　　　　　　↓
⑥げー…SDって開発だけでも金取るのかYO…
　ぁ…一部のSDカードはMMCの初期化(CMD1による初期化)が通るやん…
　これはMMCカードとして動かしてるよSDカードじゃないアルよ(棒
　｢MMCホスト上で"たまたま"SDカードが動いてしまった場合開発側はSDAに
　対してロイヤリティを払う責は無い」
　　　　　　　　　　　↓
⑦MMCの初期化が通るSDカードはSDv1のカードのみで一般的に流通している
　のは当時2GBが上限だった(例外はあるが)。当然4GB以上のSDHC(SDv2)は
　CMD8による初期化必須なのでMMCとしての初期化は一切不可能。
　　　　　　　　　　　↓
⑧…そして現在
　①～⑦までの事柄が伝言ゲーム形式でまぜこぜになり｢全てはMMCとして
　の動作である｣という大前提も忘れ｢2GBまでのSDカードでSPIモードで動
　かすならばライセンス不要って聞いた｣とか挙句の果てには｢SPIモードなら
　ライセンス不要なはず」と勝手に危険な解釈しだす。

これはいけない。

2016年現在ではJEDEC(旧MMCA)にもMMCネイティブモードについての簡易資料が
公開されてます。また、アマチュアでもMMCネイティブモードでMMCやeMMCを動作
させた作例なぞ沢山溢れかえっていますからSPI互換モードがとかネイティブモードが
とかは実際はあまり関係はなくMMCとしての動作、つまりCMD1によるカードの初期化
にてカードを動作させているか否かが本当は重要なのです。
それをしっかり理解して情報を公開されているのはサンテック社の製品解説の
ページとChaN氏の解説です。

マイコンでSDカードを使いたければ筋を通すのであればSDAとNDAを結び、さらに
maker系イベントで製作物を販売したいのならHALAも結ぶ必要があります。
企業ならともかく一個人がSDA+HALAの3000USD(2016年現在)の大金を毎年
払うのは荷が重すぎますしSDA側も民事訴訟を仕掛けて利益を回収できるレベルの
悪質な例を除いては黙認している状態なのでしょうね(この辺の関係ってなんだか
同人誌みたいだ…おっと現在は同人ではないケースもあるから薄い本でしたっけ)。

話を戻してわれわれ一個人のホビイストとしてどうすべきかですがねむいさんと
しましてはChaN氏の解説にある｢MMCまたは互換カード対応｣をお題目とすることを
支持いたします。MMC以外の形状互換のメモリーカードを｢MMC互換カード｣と纏めて
看做す作戦です。SDカードもFlashAirも立派なMMC互換カードですからね☆

ここまで徹底する必要があるのかと問われそうですがあなたがweb上で成果を
発表したりmaker系イベント等で成果物を販売したいなんてときにSDカードの
ライセンスを盾に正義感をはき違えたハナクソ野郎に絡まrt問題点を鋭く見つけ出し
追及することに余念がない方の目に止まり貴重な時間を浪費しないためにも論理的
防御策を講じておくのはとても重要なことです。

そのためには実際にMMCもしくはeMMCを動作させることができるのは必要条件です！
これだけはしっかりと行ってください。メーカー配布のライブラリ等ではMMCは最早
過去のものと断定されCMD1による初期化そのものがソースコード上から消去
されてやがるケースもありますので復活させてあげましょう！作品を展示する際も
eMMCをかっこよく使いこなしているところを魅せるとあなたも一目置かれるかも
しれませんヨ！？
↑なんかすでに｢SD対応じゃなくてMMC対応といっておけばいいらしい｣と都合よく
　曲解してる者たちがいるようですが何度も言いますがその製作物上でMMCが実際に
　動作できなかったりCMD1による初期化ルーチンを記述していないソースを公開し
　ちゃったりしてる場合はそのエクスキューズが一切まかり通りません。
　結局嘘ついてることになりますのでSDカードを｢MMCの例外的実装｣と主張できる
　ようにするためにもCMD1にて初期化するMMCが実際に動作するコードは必ず記述
　しておきましょう。

…ぇ？もしかしてねむいさんがわざわざ昔のMMCや変換基板付きのeMMC入手して
動かしたぜアピールしてたのってまさか…ですって？
はいそのまさかです。
でもAndroid等のボードだとロイヤリティフリーなeMMCが花形ですし凝った使い方
しなければSDHC/SDXCとおんなじ使用感覚ですし使い方は覚えておいて損はないと
言い切ることができます！さぁ今日から皆さんもお題目を唱えましょう！
MMCまたは互換カード対応!

MMCまたは互換カード対応!

MMCまたは互換カード対応!
…
20170107追:
CMD1の初期化がどこまで通るか実際に試しました。
20170107追:

でもめんどくさいのでこのぶろぐでは普通に｢SDカード｣って書いちゃいます。
SDAの中の人に怒られたら書き換えます＞＜

肝心な事言い忘れていましたがこれは皆さん存じてるかと思いますがSDやMMCAの
ロゴを各組織のライセンス契約を結ばずに勝手に成果物や展示物に使用した場合、
商標権を侵害したこととなり非親告罪の刑事罰の対象になります！！！
おふざけでやっても御用となるので絶対にやめましょう！！！！！！！

20230918追:
LANGSHIPのたなかまさゆき様がねむいさんのわかりづらい上記の話を
簡潔にまとめてくださいました。
2023年になったんですからSDAもフェアユース条項とかS.M.A.R.T.の
規格を搭載してほしいと思いまし、た！
20230918追:

●74クロックの怪
MMC/SDカードは電源投入後、VDDが2.0V(VDDmin)を越えたら74クロック分カードに
クロックを送出し最初のコマンド(CMD0とか)を受け付ける準備をします。

(part1_500.pdfより)
SDSpecV5.00では電源立ち上がりの規定がさらに詳しく描かれていますのでこれを
参考にしてドライバを組むとどんなカードでも安定して動くと思います。

①SDカード/MMCに供給するクロックは400kHz～100kHzに設定してマイコンのSPI
　若しくはSDIOモジュールを有効にする。
　(SPIと違いSDIO/SDMMCの場合はこの時点ですぐにクロック垂れ流しになる)
②カードに電源投入してカードの電圧がVDD(2.7~3.6V)に達してからさらに1mSec
　待ち、その後最低74クロック供給する。SDIOの場合はクロック垂れ流しなので
　最低74クロック分供給されるまで待つ。
③SPIモードならCS(DAT3)をLOにしてCRC付きでCMD0送信してSPIモードに移行。
　SD/MMCネイティブモードならそのまま各カードの初期化へ

SD/MMCの規格には上記の際のデータラインの信号レベルはどうすべきかが明記
されていませんがSD/MMCはネイティブ/SPI互換に限らずスタートビットで始まり
ストップビットで終わるクロックに同期したビットストリームによって処理されて
いるデバイスであるためビット列の同期を取るため(=スタートビット(LOレベル)を
ちゃんと受けるため)には無信号時はデータ線をHIに固定しておくべきです。

SDIOではコマンド投げてないときはHIレベルでありさらにCLK垂れ流しのため勝手に
74クロック分進んでビットの同期が取れてしまい問題は無いのですがSPIモードの
場合は明示的に74クロック(SPIは8bit単位なので実際は80クロック)送信する必要が
あり、その際のデータとして0xFFを送信してビット同期をとっておかないといけません。

で、説明が長くなりましたがこの74クロックをわざと省くとどうなるか、SPIモードで
SDカードを動作させているSTM32F4Discoveryで実験してみました。

↑80クロック送信してる行をコメントアウトしただけです。

・まずは大昔のSDV1.10の256MBのMicroSDカード
　->無事動作
　･･･あれ？
・お次はさらに超大昔のSDv1.0xの256MBのMiniSD
　->余裕で動いた
　　あれれ？？？
・超最新の東芝Exceria並行輸入版MicroSDXC64GBの奴！！
　->余裕で動いた
　　？？？？？
・Sandiskの金色の奴！！
　->余　裕　で　動　い　た
　　？？？？？
・じ、じゃぁMMCPlusの2GBの奴！
　->余裕余裕♥
　　は？(CV:スパーク・マンドリラー)
　　んぁ～すまんが～ねむいさんが正しくてお前が間違ってるってことはぁ～ないかぁ？
・さすがにMMCv3の128MBの骨董品なら74クロック抜きじゃ初期化できないでしょ！！
　->余裕のよっちゃん
　　････
・さっきのMMCPlusの2GBは1.8V動作も出来るからこれなら絶対動かんでしょ！！
　
　ここでちょっと素敵デヴァイスの紹介です。
　今年春にヘル朝鮮製のSD->MicroSDの変換アダプタ買ってウボァーしましたが
　その後台湾製のちゃんとした作りのSD->MicroSD変換基板を購入しました。
　これは信号も安定していて安心して使えます♥カードに供給する電圧も
　1.8Vに切り替えられますし♥
　->1.8Vでも正常動作♥
　　?????????????????????????????????????????

･･････････････
わけがわかりませんよぅ･･･

・結論・
結構いい加減な初期化でも大抵のカードは動いた。STM32はこういう結果になり
ましたが他のマイコンやChaN氏の作例に沿ったコーディング以外では動かないかも
しれませんのしっかり規格を守って動かしましょうね！特にCLKを除く信号線の
外部プルアップは必ず施しましょう！

20161214追：
xilinxのサイトで今回のSDカードの74クロックについて言及しているページが
ありました。やはり電源が+3.3Vになりさえすれば74クロック放たなくても
実際は殆どのカードで余裕で動いてしまうようですね！

その一方でChaN氏からコメントいただきましたとおりねむいさんのSTM32F4向けの
SPI互換モード版ではCMDを発行する前にビジーチェックする先行ビジーチェックの
方式をとっていますのでこれにより最低3バイト分のSPIクロックを空撃ちをする形と
なります。xilinxの見解と合わせるとこれだけでもう十分なクロックを放っている
と言えますね。

そしてFatFsとSTM32F4のSPIを結合するHALに相当する私のコードはChaN氏の
AVR向け実装例を源流としています。今回の検証でChaN氏のコードのロバスト性の
高さが判明し今更ながらChaN氏の偉大さがまた一つ確認された形となりました。

･･･ｻｽｶﾞﾀﾞｧ♥

●UHSモードの識別とか
現在主流になった"UHS-1"モードは通電中にI/Oの電圧を1.8Vに遷移させ消費電力の
低減と電圧スイング幅が狭くなった事による速度の向上を図るモードです。
しかしながらSTM32ですらマイコン単体でI/O電位を3.3V->1.8Vに遷移できる機構を
持つ品種は存在しないのであんまし意味は有りませんがUHSに対応しているか否か
程度は判別できるので組み込んでみました。

具体的には初期化動作時、つまりACMD41送出の際の引数にS18Rビット(24ビット目)を
立てるだけです。対応していればOCRレジスタに24番目のビットが立った状態で
返事が返ってきます。

通常OCRレジスタが0xC0FF0800と読み出されるところでS18Rビットが有効だった場合
0xC1FF0800となります。UHS-IIをサポートしたカードだと28ビット目がたちます。
でもそういったカードが私の手に入るのはまだまだ先でしょうけども。

ついでに今月のいつものの更新でSPI互換モードで取得できるSDカードの情報を大幅に
強化しています。SDIO/SDMMCとほぼ同じレベルとなりました♥

それはさておきちょっと興味深い発見をしました。
殆どのカードはSDネイティブモードでもSPI互換モードでも読み出された値は同じに
なるのですがSandiskのカードだけはSPI互換モードの場合はS18Rビットを立てた
引数でACMD41を送出しても反応がありませんでした。
いくつか試しましたがUHS-I対応を謳うUltraやExtremeのカードは全てダメでした。
もちろんSDネイティブモードの時は問題ないです。

Drive size: 15523840 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 5B 59 00 00 3B 37 7F 80 0A 40 40 AF @..2[Y..;7...@@.

CID:

00000000  03 53 44 53 55 30 38 47 80 1B B8 C2 F6 00 C8 2F .SDSU08G......./



Parsing SD CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :SU08G

Product HwRev      :8

Serial Number      :0x1BB8C2F6

DateCode.Month     :8

DateCode.Year      :2012



OCR:

00000000  C1 FF 80 00 ....

SD Status:

00000000  80 00 00 00 03 00 00 00 04 00 90 00 14 05 1A 00 ................

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 80 03 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Spec Version X  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

Available UHS-I Mode.

SDネイティブモードの時

Drive size: 15523840 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 5B 59 00 00 3B 37 7F 80 0A 40 40 AF @..2[Y..;7...@@.

CID:

00000000  03 53 44 53 55 30 38 47 80 1B B8 C2 F6 00 C8 2F .SDSU08G......./



Parsing SD CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :SU08G

Product HwRev      :8

Product SwRev      :0

Serial Number      :0x1BB8C2F6

DateCode.Month     :8

DateCode.Year      :2012



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  00 00 00 00 03 00 00 00 04 00 90 00 14 05 1A 00 ................

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 80 03 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Spec Version X  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

Available NS(or HS) Mode Only.

SPI互換モードの時

そもそもSPI互換モードではUHSモードは一切サポートせずNS(MAX25MHz)
どまりなので反応しなくても実害はないのですけど。

SDカードは奥が深いですね。

いろいろ試す24

今年の暑は夏いですね････
頭が沸騰して凝固しないように少しでも文章を残す訓練をしないと･･･

●LPC11U14の悲劇
マジかよ･･･ユーザーマニュアルにはROMディバイダあるって明記してあるのに･･･

というわけで実機で調べてみました。ねむいさんの持っていたLPC11U14Expressoは
最々初期のLPC11U14が乗っています。

0x1FFF1FF8にはROMドライバのアドレスが格納されています。実アドレスは
0x1FFF1E38となっています。

LPC11UxxのROMディバイダへのポインタが格納されているアドレスはその先頭
から16バイト先にあります。つまり0x1FFF1E48に有効なアドレスが格納されて
いない場合ROMディバイダは使用不可能となります！

ア"ア"ア"ア"ア"ア"ア"ーーーーーーーッ！！！！

･･･
NxPのLPCマイコンはこう言う罠がたくさん張り巡らされていますのでユーザー
マニュアルとか鵜呑みにしないで海外のフォーラムも積極的に巡って情報を
収集してください。

そいえば2年位前ねむいさんが指摘したLPC1500のIAPのアドレスが間違ってる件も
2016年現在まだ治ってない･･･NxP(xは伏字)さんにメッセ送ったのに･･･。

●STM32Primer2を使ったGNSSロガーのリポ電池を変更
ねむいさんはトレランのトラックログ取り用にSTM32Primer2にハード的改造を施し、
それをGNSSロガーとして使用しております。電池もSparkfun製の1000mAhの
リポ電池に乗せ買え12h以上稼動できるようにしていました。
そして2010年から約6年間もの間戦い続けてきたそのリポ電池もかなりへたってきたので
交換する運びとなったわけです。

･･･がしかし！！！なんと昨今の規制強化のせいか850mAh以上の大容量のリポ電池が
軒並み販売終了となっていて購入する事が出来なくなっておりました！！！

探しに探しまくってこちらの通販会社さんから1000mAhのリポ電池を購入する事に
しました。最悪中華直販から輸入も考えたのですがチャイナボカンされたら困るので
国内から購入できる店があって助かりました♥

で、来たのはこちら。
6年前に購入したSparkFun製のものより薄く少し長くなっています。もちろん保護
回路付コネクタ付です。

元からついているコネクタは不要なのでJSTのRCYコネクタに付け直しました。
これで電池の脱着が自由に出来ます。･･･以前はテストのために直付けしたので
6年間そのままにしてましたが今回の電池交換でようやくです。

ぁーちなみにハーネスの力がかかる部分をポリイミドテープでガチガチに固定して
ますがこいつ意外と剥がれません！wifiモジュールをポリイミドでガチガチに固定してた
EnchantMOONのこと｢こんなん振動ですぐ取れるやん｣とさんざ馬鹿にしてましたが
前言撤回ですすみません！！でもよい子は真似しちゃだめだよ！

もちろん交換後も無事正常起動しました。
2016年真夏の炎天下の近畿自然歩道でバリバリ活躍しております！

たぶんねむいさんが世界でSTM32Primer2をいちばん長く使い続けてる女だと
思います･･･！もちろんあと30年は電池交換し続けて使い倒しますよぅ！

●FatFsに大量のぱっち
今年の四月にExFatに対応したChaN氏のFatFsですが、ねむいさん含めた有志からの
使用報告を受けパッチがパチパチ当たってます。現在はpatch7まで行っていますが
ねむいさんもそれに即追従してアップデートしております。

私が特に力を入れているSTM32F7をはじめSTM32F4系、STM32F1系も順次最新の
ものにアップデートしております。皆様どしどしご利用ください★

●ウィルキンソンドライコーラ

･･･
甘味抜いたタブクリアだこれ

●おそロシアふたたび
Latticeの提供しているプログラミングツールはFT2232H系のデバイスに対応して
いてJTAGKey2CompatibleでもEEPROMを書きかえるだけでLatticeのプログラマに
化けるナイスな対応をしてくれましたが、AlteraとXilinxのツールはかたくなに
FT2232系のデバイスには対応しておりませんでした。
しかしながらロシアから恐ろしい刺客がやって来たのです･･･！もちろんLatticeと
違ってかなりダーティな裏技なので詳しいやり方は伏せさせていただきます･･･。

こちらのロシア系BBSのリンク先にあるとあるファイルにAlteraのプログラミング
ツールにFTDI系デバイスを対応させるdllがあり、それに差し替えるだけでQuartus
からAlteraのCPLD/FPGAのプログラミングツールとして使えちゃいます！！！

↑実際に使ってるところ。書き込み速度はもちろん超★爆★速！
　もうこれでUSBBlasterもどき作らなくてもいいんじゃ♥

そして問題のXilinx....
ねむいさんは過去に何度もXに挑戦し敗れてきましたがおそロシアのおかげでついに、
ついに攻略せしめました！！！！
注：ただし以下の条件を全て満たす必要があります。
　　１．FT2232Hのみ有効。FT232HやFT2232Dは不可！
　　２．FT2232Hにぶら下がるEEPROMは93LC56もしくは93LC66のみ有効。
　　　　93LC46はユーザー領域が足らず不可！
　　３．JTAGKey2 Compatible Rev.5を使用する場合、メインモジュールの
　　　　DLP-USB1232Hに搭載されたモジュールが93LC56or93LC66である事。
　　　　これは何が来るか分からないのでばくちですね･･･しかもQFNパッケなの
　　　　で引っぺがすのは普通の人にはちょっと無理でしょう。
　　　　かわりにFT2232H Minimoduleがオススメです。これ93LC56乗ってますし。

↑コツですがMProgを使ってEEPROMのデータを書きこむときにシリアルナンバを
　"有効"にしておきます。この後FTDI_User_Area_Writer.exeを起動しMprog/FTProg
　からは書き込めないユーザ領域にデータを書きこみます。

やったぜ。Digile○ntのJTAG-HS2として認識されました♥ちなみにISE14.7は
プラグインの調達の必要もなくIMPACTから普通に使えます。

実際にSPARTAN3をつなげてJTAGチェインを見てみます。

やったぜ！

もちろんふつうにコンフィグレーションできます♥

2010年からずっと奮闘してきた内容ですがようやくつっかえていた小骨が取れた
感じです♥EEPROMを書き換える少しの手間はありますがこれでねむいさん謹製の
JTAGKey2Compatibleが更に強力なフラッシュ書き込み/デバッグツールとして
活躍していけると思います！！

いろいろ試す23

せっかく貴重なGWの休みだというのに何をやっているんだ私は･･･
でもこれを消化しないと先に進めないというBADハマリ状態なのです･･･

●FTDIのFT232Rはぱちもんを撥ねるドライバが出てFT232Rの安いぱちもん
　使えなくなったから中華製のCH340G使おうぜムーブメント
みなさんはすでにご存知のこととは思いますがFT232Rはぱちもん対策が仕込んで
あってあんなことやこんなことでぱちもんを使えなくさせています。
中華製のFT232R基板はまずぱちもんなのが前提だそうでぱちもん愛好家の方には
FTDIのドライバ改変で使えなくなるのは死活問題なのは必須です。そういうわけで
中華製のUSB-シリアル変換ICであるCH340Gを使おうという動きがあるようです。

ねむいさん的には何か大前提が思いっきり間違ってる気がしますが｢自己責任
なら良いのではないでしょうか自己責任なら｣といい居たいところですが大抵は
ぱちもんに分かって手出す人はケチなくせに文句だけは百人前でそういう人に
関わると時間と金を浪費してしまいますので皆様方はそういう人種を機敏に察知し
いち早く距離を置かれることが良いと思います。

…すみません話がそれてしまいましたが残念ながらCH340Gにもぱちもんが存在している
ようです。こちらをご覧ください。真ん中あたりにくわしい解説の画像があります。

CH340Gのぱちもんの見分け方として1Pinのマーキングの丸の削りが大きく広い
物が正規品で丸が小さくクレーター状に削られてるものがぱちもんだそうです。

ねむいさんも何故かCH340Gの出来合いボード持ってました･･･そして･･･

ぱちもんでしたー！！！！
クソァ！！１！１！！１

ちなみにぱちもんCH340Gは公式のドライバ宛がっても上手く動作しないようで
やっぱし中華メーカといえどもしっかりドライバでぱちもん対策してるようです。
このへんFTDIやProlificも同じなのでたとえイタチごっことなろうとも
メーカの自衛策としてぱちもん対策を仕込むのは必然となっているようですね。

安物買いの銭失い、安全/安心は金で買うものとはよく言ったものです。
たまにその売り物の安全安心すらぱちもんのことがありますけど…ふふふ。

20160512追:
こちらの方のブログのコメントに具体的な情報を見つけました。以下引用。

Commented by 中華マニア at 2015-04-24 10:11 x
CH340G自体にも通電していると内部のボンディングワイヤが焼き切れて
すぐ使えなくなる粗悪な偽物があふれかえっているそうです。

あれ…副業先で生産が間に合わず海外の別ルートで購入したNxP(xは伏字のx)製の
FETで似たような経験したような…

●FatFsが0.12にアップデートしてついにexFATに対応！！
GW前にChaN氏のFatFsがexFATに対応してアップデートしておりました。
64GByte以上のSDXCカードが安価で販売されるようになった今、exFATへの対応は
必然であるといえるのです！
･･ぇ？FAT32で無理やりフォーマットできるですって！？それはおいといて･･･

ところでSDHCとSDXCの違いは何か、どうやって見分けるのかという素朴な疑問が
わきますが規格では64GB以上の容量を持つカードがSDXCとなっています。
一般の方が単純明快に見分けられるたった一つの方法です。
SDHCはどう頑張っても32GBどまりです。この辺はこちらの方の解説が詳しいです。
逆に言うと128GBのSDHCとかは絶対に存在しないのでぱちもんであるとわかります。
海外通販でだまされないように注意してください。

ソフトウェア的に見分ける方法はいくつかあって前回もさらっと触れましたが
SCRを読み出しSD_Securityフィールドの値を見ることでも簡単に判別できます。
SDXCはここの値が必ず4になっています。ここの値はSD_SpecのVerには関係あり
ませんのでSDSpecのVerが4でもSDHCだったり3のカードでもSDXCなのが存在する
のは前回の読み出し比較でご存知だと思います。

さて、exFATにすることでFatFsがどういう挙動になるかを実際にフォーマット別
に比較してみました。使用するカードは前回へなちょこ判定したSuperTalentの
64GBのカードです。

前回無理やりFAT32にフォーマットして使ったといいましたがWindows上ではSDXC
カードはほぼ強制的にexFATでフォーマットされてしまうのでParagonHardDiskManager
を使いFAT32にフォーマットして使いました。
exFATのフォーマットについてはもちろんおなじみのSDFormatterV4.0です。

というわけでChaN氏のFat情報を読み出すfsコマンドといつものシーケンシャル
リードの速度比較を行ってみました。STM32F7-Discoveryで行ってます。

※FAT32フォーマット

FatFs module test terminal for STM32F746NGH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : May  4 2016

>fs

FAT type = FAT32

Bytes/Cluster = 16384

Number of FATs = 2

Root DIR entries = 0

Sectors/FAT = 30576

Number of clusters = 3913672

Volume start (lba) = 2048

FAT start (lba) = 2080

DIR start (lba,clustor) = 2

Data start (lba) = 63232



Volume name is SDXC_64GB

Volume S/N is 7022-3F80

...

19 files, 520994673 bytes.

2 folders.

62618752 KiB total disk space.

62109728 KiB available.

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 15414 kB/sec.

※exFATフォーマット

FatFs module test terminal for STM32F746NGH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : May  4 2016

>fs

FAT type = exFAT

Bytes/Cluster = 131072

Number of FATs = 1

Root DIR entries = 0

Sectors/FAT = 16384

Number of clusters = 489208

Volume start (lba) = 32768

FAT start (lba) = 49152

DIR start (lba,clustor) = 4

Data start (lba) = 65536



Volume name is SDXC_64GB

Volume S/N is DF51-7DE4

...

19 files, 520994673 bytes.

2 folders.

62618624 KiB total disk space.

62107904 KiB available.

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 18442 kB/sec.

なん･･･だと･･･！？
exFATにしたらへなちょこじゃなくなった･･･！？
exFATになってクラスタサイズがデカイのが効いているのかもしれません。

FatFsのexFATの対応はまだ始まったばかりでバグも洗い出されて洗練されて
いく真っ最中ですのでこれからの発展に期待ですね。

ついでにFatFsのexFAT対応する時の注意点をいくつか･･･
1.常にLFN対応が必須
　exFATはロングファイルネームしか存在しないためです。それに伴って従来の
　8.3形式ファイル表記に頼ったプログラムだと既存のものから0.12にアップ
　デートする際にかなりの改修が必要です。

2.そんなわけでメモリ消費量が多くなる
　これも致し方ないですね。SRAM容量32kByte以下の小規模マイコンはexFAT
　対応はやめたほうが無難でしょう。尤も32GB以下のSDHCもまだまだ生産されて
　流通しているのでSDXCしかカードが無い！って事態は当分の間無いといえます。
　無理にexFAT対応にするべきではありません。ライセンスの問題もありますから。

･業務連絡･
ChaN様へ
もしここ見てたら"Well written implementations for STM32F/SDIO and LPC2300/MCI"
の"STM32F/SDIO and LPC2300/MCI"のところを"STM32F/SPI & SDIO and LPC4088/SDMMC"
に書き換えておいてください･･･。
↑ご協力ありがとうございました(ぺっこりん

皆様へ、
おきぱのSTM32F4とSTM32F7向けのいつものはFatFs0.12に対応してすでに公開
しております！もちろん0.12向けのパッチも適用済なのでどしどしご利用ください！

●4GBのSDカード
かつて4GB以上の容量をサポートするSDHCの規格が登場し実際に市場に出回り
はじめる過渡期に4GBの容量を持ちながらSDv1規格で動作するいわゆる"規格外"の
SDカードが存在していました。

いったいこのカードはどのような動作をするのか！？実際に現在でも流通している
カードを購入して調べてみることにしました。

ebayでドイツの販売主から購入しました。SDV1.1規格の4GBのSDカードでSDHCに対応
しないちょっと昔の機器で活躍するかも！ていう触れ込みです。

さっそくねむいさんのいつものでSDカードの情報を読み出してみました。
が････

>ds 0

rc=0

Drive size: 7784448 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 5B 59 00 00 1D B1 7F 80 0A 40 00 39 @..2[Y.......@.9

CID:

00000000  1B 53 4D 46 46 46 46 46 10 00 00 20 46 00 FC F3 .SMFFFFF... F...



Parsing SD CID Register

Manufacturer ID    :0x1B

OEM/Application ID :SM

Product Name       :FFFFF

Product HwRev      :1

Product SwRev      :0

Serial Number      :0x00002046

DateCode.Month     :12

DateCode.Year      :2015



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 02 00 00 00 04 04 90 00 08 05 00 00 ................

00000010  00 00 00 00 00 00 00 00 00 53 4D 49 00 00 00 00 .........SMI....

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 80 00 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

･･･
なんですかこれ単なるSDHCじゃないですかーヤダー！！！
･･･ちなみにh2testwでも調べましたがカードとしてはちゃんと4GBの容量をもった
"SDHC"でした･･･ﾋﾞｷﾋﾞｷ

ぱちもんつかまされたと思って捨てるのもあれなので副業先の修理品撮影用でぢかめ
の記憶素子として利用することになりました。
が･･･
後輩から｢ねむいさんこのカード1GBしか認識しないんスけど？｣と文句を言われ
このカードのホントの力を知ることになります。

後輩が撮影した画像データを取り出そうとして使ったUSBカードリーダーは10年
以上前の骨董品で、4GBに替える前のでぢかめ用SDも時代遅れの1GBでした。
もちろんこのカードリーダはSDHCを一切認識しないため私が提供した4GBのカードが
容量が変だとはいえ認識すること事態がおかしいのです。

ねむいさん後輩からそのカードを取りかえし、デバッガで動きを追ったところ以下の
事実が分かりました。

1.イニシャライズ時に最初にCMD8(SDv2専用の初期化コマンド)を投げていると
　SDHCとしてブロックアドレッシングモードで動作する。
2.ACMD41をいきなり投げると(SDv1の初期化)SDSCとしてバイトアドレ
　ッシングモードで動作する

つまり新旧の初期化方法のどちらでも正しくカードを初期化できて正しく動作する
ように作られたいわば魔法のカードだったのです！！！

ねむいさんのおきぱのFatFsの移植サンプルはSDカードの初期化手順がCMD0->CMD8->
ACMD41というSDv2もSDv1も包括する流れだったので必ずSDHCとして初期化されて
しまうのでぱちもんだー！と誤認してしまいました。

以下に通常のSDv2の初期化とわざとCMD8を飛ばしてSDv1で初期化したときのカード
情報の違いの差を示します。
・SDv2

FatFs module test terminal for STM32F746NGH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr 28 2016

>fl

----A2011/07/27 23:51    351416  0c4f42da.jpg

----A2015/03/03 15:07    307254  1c3e744f.bmp

----A2010/07/20 13:52 1993197471  91sp2_quartus_free.exe

----A2011/06/04 06:07    324588  1c3e744f.jpg

----A2010/03/24 17:47    132389  002.jpg

----A2016/01/30 10:54    244527  2d35e710.jpg

----A2013/06/20 22:49     47566  2ecd0b3e.jpg

----A2010/03/24 17:48    198903  003.jpg

----A2011/05/25 01:11     53023  3c3ba2bd.jpg

----A2010/03/24 17:48    137038  004.jpg

----A2013/05/29 21:02     22235  4b62585a.jpg

----A2012/09/19 23:32     80490  4db4ceb4-d00d-5891-b900-4f97ec745309.image.jpg

----A2010/12/02 23:28    102769  4e61b17f.jpg

----A2010/03/24 17:48    148307  005.jpg

----A2015/07/08 14:32 318848704  install_sw4stm32_win_32bits-v1.2.exe

----A2016/02/26 11:57 421760368  MDK518.EXE

----A2008/09/12 20:19     47341  2005-03-24otter02.jpg

  17 File(s),2736004389 bytes total

   0 Dir(s), 1239515136 bytes free

>fs

FAT type = FAT32

Bytes/Cluster = 32768

Number of FATs = 2

Root DIR entries = 0

Sectors/FAT = 948

Number of clusters = 121334

Volume start (lba) = 8192

FAT start (lba) = 14488

DIR start (lba,clustor) = 2

Data start (lba) = 16384



No volume label

Volume S/N is 3688-4D7E

...

17 files, 2736004389 bytes.

0 folders.

3882688 KiB total disk space.

1210464 KiB available.

>ds 0

rc=0

Drive size: 7784448 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 5B 59 00 00 1D B1 7F 80 0A 40 00 39 @..2[Y.......@.9

CID:

00000000  1B 53 4D 46 46 46 46 46 10 00 00 20 46 00 FC F3 .SMFFFFF... F...



Parsing SD CID Register

Manufacturer ID    :0x1B

OEM/Application ID :SM

Product Name       :FFFFF

Product HwRev      :1

Product SwRev      :0

Serial Number      :0x00002046

DateCode.Month     :12

DateCode.Year      :2015



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 02 00 00 00 04 04 90 00 08 05 00 00 ................

00000010  00 00 00 00 00 00 00 00 00 53 4D 49 00 00 00 00 .........SMI....

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 80 00 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

・SDv1

FatFs module test terminal for STM32F746NGH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr 28 2016

>fl

----A2011/07/27 23:51    351416  0c4f42da.jpg

----A2015/03/03 15:07    307254  1c3e744f.bmp

----A2010/07/20 13:52 1993197471  91sp2_quartus_free.exe

----A2011/06/04 06:07    324588  1c3e744f.jpg

----A2010/03/24 17:47    132389  002.jpg

----A2016/01/30 10:54    244527  2d35e710.jpg

----A2013/06/20 22:49     47566  2ecd0b3e.jpg

----A2010/03/24 17:48    198903  003.jpg

----A2011/05/25 01:11     53023  3c3ba2bd.jpg

----A2010/03/24 17:48    137038  004.jpg

----A2013/05/29 21:02     22235  4b62585a.jpg

----A2012/09/19 23:32     80490  4db4ceb4-d00d-5891-b900-4f97ec745309.image.jpg

----A2010/12/02 23:28    102769  4e61b17f.jpg

----A2010/03/24 17:48    148307  005.jpg

----A2015/07/08 14:32 318848704  install_sw4stm32_win_32bits-v1.2.exe

----A2016/02/26 11:57 421760368  MDK518.EXE

----A2008/09/12 20:19     47341  2005-03-24otter02.jpg

  17 File(s),2736004389 bytes total

   0 Dir(s), 1239515136 bytes free

>fs

FAT type = FAT32

Bytes/Cluster = 32768

Number of FATs = 2

Root DIR entries = 0

Sectors/FAT = 948

Number of clusters = 121334

Volume start (lba) = 8192

FAT start (lba) = 14488

DIR start (lba,clustor) = 2

Data start (lba) = 16384



No volume label

Volume S/N is 3688-4D7E

...

17 files, 2736004389 bytes.

0 folders.

3882688 KiB total disk space.

1210464 KiB available.

>ds 0

rc=0

Drive size: 7784448 sectors

Erase block size: 512 sectors

Default r/w block size: 2048 bytes

Card type: SDv1

CSD:

00000000  00 0E 00 32 5B 5B 03 B6 1D B3 FF 80 0A C0 00 E9 ...2[[..........

CID:

00000000  1B 53 4D 46 46 46 46 46 10 00 00 20 46 00 FC F3 .SMFFFFF... F...



Parsing SD CID Register

Manufacturer ID    :0x1B

OEM/Application ID :SM

Product Name       :FFFFF

Product HwRev      :1

Product SwRev      :0

Serial Number      :0x00002046

DateCode.Month     :12

DateCode.Year      :2015



OCR:

00000000  80 FF 80 00 ....

SD Status:

00000000  80 00 00 00 00 00 00 20 04 04 90 00 08 05 00 00 ....... ........

00000010  00 00 00 00 00 00 00 00 00 53 4D 49 00 00 00 00 .........SMI....

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 25 80 00 00 00 00 00 .%......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Security        :2

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDSC Card!

もちろんどちらの初期化手順でも得られる使用可能総容量はCSDレジスタの値自体が
アジャストされ変化するためSDv2,SDv1のどちらの初期化手順でもまったく
同一の容量となり、さらにバイト/ブロックアドレッシング両方の読み書きも
すべて正しく行えております。
しかもご丁寧にSCRのSDSecurityのバージョンまでちゃんとアジャストして
SDv1で初期化したらちゃんとSDSCとして認識されるという充実ぶりです！！

ついでですがその他の"4GBのSDカード"も調べてみました。これはTOPRAM製の
カードです。結果から言うと同じく初期化手順の違いでSDSCにもSDHCにも化ける
タイプでした。

こちらは規格外カードの本家ともいえるTranscendの4GBカードです･･･がUSEDで
しか手に入らなかったのでなんか茶色いのがいっぱいこびりついててきちゃない･･･

中華からかった中古なので何がついてる分からずIPAでよごれをこすって落とし
まくって2時間後にようやく動作確認･･･

こいつこそホントに単なるSDHCでした！！！！！F**K!

20160512追:
後でさらに調べて分かりましたが"SD Compatible"とパッケージにはっきり
書かれたものでない限りはSDHCの表記が無くてもただのSDHCでSDv1の
初期化は一切通らないそうですF++K!!!

というわけで規格外な"4GBのSDカード"は規格外ながらも今日もどこかの
ちょっと古い機材で活躍しているかもしれません。

●秋月の006Pリチウム電池
テスタの電池用に秋月さんの006P型リチウム電池を購入してみました。

一般の006Pと比べるとやたら軽くちょっと大きく見えて不安になります･･･

一応無理なく収納できました★

動作も問題ありません♥
実はもう4ヶ月近く使用していますが今のところ電圧が出なくなったり爆発
したりとかはなく、至って問題なく使用できています。このリチウム電池は一
般的な006P型乾電池と比べると電流容量はかなり低いですがテスタのような
消費電力が低い機器で使用する分にはまったく問題は無いのでオススメです♥

STM32F4シリーズを使ってみる15 - FatFsとSDカード再考その4(SDカードを手当たりしだい読み出してみる) -

一年以上ぶりの企画になってしまいましたが前回の続きです。
STM32F4を使ってSDカードのカード情報を読み出したり読み取り速度の比較を
行います。

とりあえず手持ちのカードを全部！！！

MMCから始まり10年以上前のSDカードや最新のSDXCまで網羅します！！

条件は以下のとおりとします。
・各カードはあらかじめSDFormatterでFAT32でフォーマットする。
　64GB以上のSDXCもHardDiskManagerで無理やりFAT32でフォーマットします。
・プログラムはSTM32F4版のいつものの3/31日版とします。
・使用するボードは180MHzで動作可能なSTM32F427IIT6が乗った
　STM32F4全部乗せボードを使用します。
・SDのクロックはハイスピードモードとします。このボードでは
　SDIO_CLKの最高クロック周波数は51.43MHzとなります。
　また、SDIOの転送にはDMAを使用します。
・読み出し速度は132949600Byteのファイルのシーケンシャル読み出しの速度を
　比較します(128MBのMMCv3を除く)。また、ねむいさん的には読み出ししか興味
　ないので書き込み比較はやりません。

それでははじめましょう！

●Toshiba製eMMCv5 8GB

まずは前回のおさらい、Toshiba製のeMMC8GBです。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 22961 kB/sec.

>ds 0

rc=0

Drive size: 15269888 sectors

Erase block size: 1024 sectors

Default r/w block size: 512 bytes

Card type: MMC(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  D0 5E 00 32 0F 59 03 FF FF FF FF EF 92 40 00 D3 .^.2.Y.......@..

CID:

00000000  11 01 00 30 30 38 47 45 30 00 5A DD 41 40 B2 0D ...008GE0.Z.A@..



Parsing MMC CID Register

Manufacturer ID    :0x11

OEM/Application ID :<0>

Product Name       :008GE0

Product Rev        :0.0

Serial Number      :0x5ADD4140

DateCode.Month     :11

DateCode.Year      :2015



Detected as MMCv5.0x Device!

OCR:

00000000  C0 FF 80 80 ....

読み出し速度が22961kByte/SecとSDカードを抑えてダントツに早いです！

●Transcend製2GB MMCplus

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Mar 22 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 21261 kB/sec.

>ds 0

rc=0

Drive size: 3939328 sectors

Erase block size: 256 sectors

Default r/w block size: 1024 bytes

Card type: MMC(Byte)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  90 2F 00 2A 1F 5A 83 C1 B6 DB 9F FF 96 80 00 3F ./.*.Z.........?

CID:

00000000  37 FF FF 4D 4D 43 30 32 47 10 F3 02 67 50 2C F5 7..MMC02G...gP,.



Parsing MMC CID Register

Manufacturer ID    :0x37

OEM/Application ID :��

Product Name       :MMC02G

Product Rev        :1.0

Serial Number      :0xF3026750

DateCode.Month     :2

DateCode.Year      :2009



Detected as MMCv4.0 Device!

OCR:

00000000  80 FF 80 80 ....

こちらもなかなかのお手前で。

●日本製MMCv3カード

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fl

D---- 2016/03/14 23:28         0  .             

D---- 2016/03/14 23:28         0  ..            

----A 2010/03/13 20:06  44679600  ftbt.mp3      

   1 File(s),  44679600 bytes total

   2 Dir(s),   83640320 bytes free

>fr 44679600

44679600 bytes read with 1904 kB/sec.

>ds 0

rc=0

Drive size: 250880 sectors

Erase block size: 32 sectors

Default r/w block size: 512 bytes

Card type: MMC(Byte)

SpeedMode: NomalSpeedMode(17.14MHz)

DataBusWidth: 1bit



CSD:

00000000  8C 26 01 2A 0F 59 81 E9 F6 DA 81 E3 9E 40 00 7D .&.*.Y.......@.}

CID:

00000000  11 00 00 30 31 32 38 4D 32 0A 05 80 FE CB 28 7D ...0128M2.....(}



Parsing MMC CID Register

Manufacturer ID    :0x11

OEM/Application ID :<0><0>

Product Name       :0128M2

Product Rev        :0.10

Serial Number      :0x0580FECB

DateCode.Month     :2

DateCode.Year      :2005



Detected as MMCv3.xx Card!

OCR:

00000000  80 FF 80 00 ....

MMCv3は20MHz以下のクロックでなければいけないのでそれを守っています。
20MHz以上では確かに動作しませんでした。

ここから先はSDカードです。

●Transcend製x600のMicroSDHC8GB(TS8GUSDHC10U1)

昨年末に紹介したMLCアピールの奴です。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Mar 22 2016

>fg piano

rc=0 FR_OK

>fo  1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 20025 kB/sec.

>ds 0

rc=0

Drive size: 15759360 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 00 3C 1D 7F 80 0A 40 00 63 @..2[Y..<....@.c

CID:

00000000  74 4A 60 55 53 44 55 31 20 3B A1 5F AA 00 F6 25 tJ`USDU1 ;._...%



Parsing SD CID Register

Manufacturer ID    :0x74

OEM/Application ID :J`

Product Name       :USDU1

Product HwRev      :2

Product SwRev      :0

Serial Number      :0x3BA15FAA

DateCode.Month     :6

DateCode.Year      :2015



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 03 00 00 00 04 00 90 00 08 11 39 00 ..............9.

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 80 03 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

結構読み出しが早いですね。SDカードでは20000kB/Sec以上だと
早い部類です。

●Transcend製x600のSDHC32GB(TS32GSDHC10U1)

今度はさっきの32GB版、かつ通常サイズのものです。
今年春までTG-3の撮影用記録媒体として活躍していました。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 18130 kB/sec.

>ds 0

rc=0

Drive size: 63272960 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 00 F1 5D 7F 80 0A 40 00 79 @..2[Y...]...@.y

CID:

00000000  74 4A 60 53 44 55 31 20 20 46 F9 B9 1D 00 F5 67 tJ`SDU1  F.....g



Parsing SD CID Register

Manufacturer ID    :0x74

OEM/Application ID :J`

Product Name       :SDU1 

Product HwRev      :2

Product SwRev      :0

Serial Number      :0x46F9B91D

DateCode.Month     :5

DateCode.Year      :2015



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 05 00 00 00 04 00 90 00 08 11 39 00 ..............9.

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 80 03 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

まずまずですね。

●Transcend製MicroSDHC8GB

普通の廉価版の奴です。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 15279 kB/sec.

>ds 0

rc=0

Drive size: 15456256 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 00 3A F5 7F 80 0A 40 00 43 @..2[Y..:....@.C

CID:

00000000  74 4A 45 55 53 44 55 31 02 05 B0 00 60 00 D1 E3 tJEUSDU1....`...



Parsing SD CID Register

Manufacturer ID    :0x74

OEM/Application ID :JE

Product Name       :USDU1

Product HwRev      :0

Product SwRev      :2

Serial Number      :0x05B00060

DateCode.Month     :1

DateCode.Year      :2013



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 03 00 00 00 04 00 90 00 08 11 19 00 ................

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 80 03 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

廉価版だけに速度はそれなりです。

●SuperTalent MicroSDHC 4GB

お店で同容量比で最安値に近い値段で買えたSupterTalentのSDカードです。
たしか780円でした。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 13677 kB/sec.

>ds 0

rc=0

Drive size: 7841792 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 00 1D E9 7F 80 0A 40 00 69 @..2[Y.......@.i

CID:

00000000  73 42 47 4E 43 61 72 64 10 19 23 6D 71 00 BB 81 sBGNCard..#mq...



Parsing SD CID Register

Manufacturer ID    :0x73

OEM/Application ID :BG

Product Name       :NCard

Product HwRev      :1

Product SwRev      :0

Serial Number      :0x19236D71

DateCode.Month     :11

DateCode.Year      :2011



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 02 00 00 00 04 04 90 00 08 05 00 00 ................

00000010  00 00 00 00 00 00 00 00 00 53 4D 49 00 00 00 00 .........SMI....

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 80 00 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

リードが13MB/Sec･･･ﾀﾞﾒﾀﾞﾒですね。

●SuperTalent MicroSDXC64GB(FAT32 Format)

続いては64GB版のSDXCの奴です。フォーマットは無理やりFAT32で
行ったうえで試しました。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Mar 22 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 15772 kB/sec.

>ds 0

rc=0

Drive size: 125302784 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 01 DD FD 7F 80 0A 40 00 07 @..2[Y.......@..

CID:

00000000  28 42 45 20 20 20 20 20 02 00 33 3C 22 00 FA D3 (BE     ..3<"...



Parsing SD CID Register

Manufacturer ID    :0x28

OEM/Application ID :BE

Product Name       :     

Product HwRev      :0

Product SwRev      :2

Serial Number      :0x00333C22

DateCode.Month     :10

DateCode.Year      :2015



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 08 00 00 00 04 00 90 00 08 11 19 00 ................

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 45 80 03 00 00 00 00 .E......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Security        :4

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDXC Card!

4GBの奴よりマシなものの15MB/Secちょっと･･やっぱしダメですね・・・
ちなみにSCRの値が示すとおりちゃんとSDXCとして認識できているので
カードとしてはれっきとしたSDXCです。

SDHCとSDXCの見分け方は容量のほかにSCRのSD Securityのバージョンから
分別することも可能です。

●KingMAX MicroSDHC32GB

こちらも廉価で替えるカードの筆頭です。
当時ちょっと値が張った32GBをFatFsの動作確認用に購入していました。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 13668 kB/sec.

>ds 0

rc=0

Drive size: 62683136 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 00 EF 1D 7F 80 0A 40 00 27 @..2[Y.......@.'

CID:

00000000  13 4B 47 53 44 33 32 47 10 C2 00 51 1A 00 C7 A3 .KGSD32G...Q....



Parsing SD CID Register

Manufacturer ID    :0x13

OEM/Application ID :KG

Product Name       :SD32G

Product HwRev      :1

Product SwRev      :0

Serial Number      :0xC200511A

DateCode.Month     :7

DateCode.Year      :2012



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 05 00 00 00 04 04 90 00 08 05 00 00 ................

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 80 00 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

SuperTalentと同じ13MB/Sec...ﾀﾞﾒﾀﾞｺﾘｬ

●Toshiba EXCERIA 16GB Type2国内正規版

こちらはTG-3の購入と同時に購入した国内の正規品です。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 21617 kB/sec.

>ds 0

rc=0

Drive size: 30867456 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 00 75 BF 7F 80 0A 40 00 93 @..2[Y..u....@..

CID:

00000000  02 54 4D 53 44 31 36 47 86 DE 58 C2 6E 00 E3 23 .TMSD16G..X.n..#



Parsing SD CID Register

Manufacturer ID    :0x2

OEM/Application ID :TM

Product Name       :SD16G

Product HwRev      :8

Product SwRev      :6

Serial Number      :0xDE58C26E

DateCode.Month     :3

DateCode.Year      :2014



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 04 00 00 00 04 03 90 02 00 06 1A 00 ................

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 B5 80 03 32 02 23 82 ....2.#.



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

20MB/Sec越えです･･･やったね☆
値段張った甲斐がありました･･･

●Toshiba EXCERIA MicroSDHC32GB 並行輸入版

今度は並行輸入版の奴です。高速の信号のやり取りを意識してか
いかなる変換アダプターも使用不可と警告がありました。ねむいさんの
使用法では高々50MHzぽっちなので別に関係ありませんが。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 22154 kB/sec.

>ds 0

rc=0

Drive size: 61079552 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 00 E8 FF 7F 80 0A 40 00 AF @..2[Y.......@..

CID:

00000000  02 54 4D 55 43 30 44 33 20 E9 C2 CF A5 00 EC 01 .TMUC0D3 .......



Parsing SD CID Register

Manufacturer ID    :0x2

OEM/Application ID :TM

Product Name       :UC0D3

Product HwRev      :2

Product SwRev      :0

Serial Number      :0xE9C2CFA5

DateCode.Month     :12

DateCode.Year      :2014



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 05 00 00 00 02 02 90 02 00 06 3C 00 ..............<.

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 B5 84 03 32 02 29 02 ....2.).



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Security        :3

SD Bus Width       :5



SD_Spec V4.xx!

Detected as SDHC Card!

おおっ！東芝のeMMCv5に匹敵するスピードですよぅ!!
こいつはオススメです☆

●Toshiba8GB MicroSDHC

廉価な東芝製のmicroSDHCです。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 20202 kB/sec.

>ds 0

rc=0

Drive size: 15564800 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 00 3B 5F 7F 80 0A 40 00 75 @..2[Y..;_...@.u

CID:

00000000  02 54 4D 53 44 30 38 47 56 C0 14 C0 4F 00 B1 C5 .TMSD08GV...O...



Parsing SD CID Register

Manufacturer ID    :0x2

OEM/Application ID :TM

Product Name       :SD08G

Product HwRev      :5

Product SwRev      :6

Serial Number      :0xC014C04F

DateCode.Month     :1

DateCode.Year      :2011



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 03 00 00 00 04 03 90 08 00 F2 19 00 ................

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 B5 80 03 28 03 51 02 ....(.Q.



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

これもなかなかですね～

●Panasonic 2GB MicroSD

380円でたたき売りされていたMicroSDです。
STM32Primer2用に控えで購入していました。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo  1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 10776 kB/sec.

>ds 0

rc=0

Drive size: 3862528 sectors

Erase block size: 8192 sectors

Default r/w block size: 1024 bytes

Card type: SDv2(Byte)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  00 7F FF 32 5F 5A 83 AE F6 DB DF FF 8E 80 00 4B ...2_Z.........K

CID:

00000000  01 50 41 53 30 32 47 46 12 43 20 E0 52 00 B6 E1 .PAS02GF.C .R...



Parsing SD CID Register

Manufacturer ID    :0x1

OEM/Application ID :PA

Product Name       :S02GF

Product HwRev      :1

Product SwRev      :2

Serial Number      :0x4320E052

DateCode.Month     :6

DateCode.Year      :2011



OCR:

00000000  80 FF 80 00 ....

SD Status:

00000000  80 00 00 00 00 00 00 28 02 02 90 00 10 05 00 00 .......(........

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 25 00 00 00 F0 02 10 .%......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :0

SD Spec Version 4  :0

SD Security        :2

SD Bus Width       :5



SD_Spec V2.00!

Detected as SDSC Card!

まぁこんなものですね･･･

●Panasonicの512MBSLC金色カード

これは他の奴らとは一味違います！！！
Panasonic製の工業用SDカードです！！！
そしてTLCが全盛になった今希少なS・L・C!!!!

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Mar 22 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 17939 kB/sec.

>ds 0

rc=0

Drive size: 967680 sectors

Erase block size: 4096 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Byte)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  00 0E 01 32 5B 59 81 D8 7F FF FF FF 12 40 00 FD ...2[Y.......@..

CID:

00000000  01 50 41 52 46 35 31 32 23 74 EF 95 6D 00 F6 B9 .PARF512#t..m...



Parsing SD CID Register

Manufacturer ID    :0x1

OEM/Application ID :PA

Product Name       :RF512

Product HwRev      :2

Product SwRev      :3

Serial Number      :0x74EF956D

DateCode.Month     :6

DateCode.Year      :2015



OCR:

00000000  80 FF 80 00 ....

SD Status:

00000000  80 00 00 00 00 00 00 14 03 03 80 00 08 07 00 00 ................

00000010  00 00 00 00 00 00 00 00 00 98 DC 90 26 76 16 08 ............&v..

00000020  01 00 93 02 41 12 22 00 00 00 00 00 00 00 00 40 ....A."........@

00000030  29 29 00 00 10 20 82 88 00 01 C6 00 00 00 17 1F ))... ..........

SCR:

00000000  02 A5 80 00 01 F0 01 01 ........



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Security        :2

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDSC Card!

あり･･･普通だ･･･ま、まぁ工業用ですからピーキーな性能よりも
安定性とかｿｯﾁのほうがすごいのでしょうね(脂汗)

●名も無き16GB MicroSDHC

1078円でたたき売りされていたMicroSDHCです。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 18257 kB/sec.

>ds 0

rc=0

Drive size: 31275008 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 00 77 4D 7F 80 0A 40 00 9D @..2[Y..wM...@..

CID:

00000000  28 42 45 48 30 33 30 39 10 00 00 19 C9 00 B1 ED (BEH0309........



Parsing SD CID Register

Manufacturer ID    :0x28

OEM/Application ID :BE

Product Name       :H0309

Product HwRev      :1

Product SwRev      :0

Serial Number      :0x000019C9

DateCode.Month     :1

DateCode.Year      :2011



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 04 00 00 00 04 04 90 00 08 05 00 00 ................

00000010  00 00 00 00 00 00 00 00 00 53 4D 49 00 00 00 00 .........SMI....

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 80 00 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

･･･たたき売りのくせにやるじゃない(ﾆﾔ

●名も無き256MBMicroSD

こちらは10年位前に6800円で購入した古の256MBのカードです。
まだまだ現役バリバリなのですよぅ

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 12321 kB/sec.

>ds 0

rc=0

Drive size: 499712 sectors

Erase block size: 128 sectors

Default r/w block size: 512 bytes

Card type: SDv1

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  00 5E 00 32 57 59 83 CF ED B6 FF 87 96 40 00 D3 .^.2WY.......@..

CID:

00000000  4B 46 4D 53 44 20 20 20 10 03 00 25 63 00 69 7D KFMSD   ...%c.i}



Parsing SD CID Register

Manufacturer ID    :0x4B

OEM/Application ID :FM

Product Name       :SD   

Product HwRev      :1

Product SwRev      :0

Serial Number      :0x03002563

DateCode.Month     :9

DateCode.Year      :2006



OCR:

00000000  80 FF 80 00 ....

SD Status:

00000000  80 00 00 00 00 00 00 28 00 00 00 00 00 00 00 00 .......(........

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  01 25 00 00 00 00 00 00 .%......



Parsing SCR

SD Spec Version    :1

SD Spec Version 3  :0

SD Spec Version 4  :0

SD Security        :2

SD Bus Width       :5



SD_Spec V1.10!

Detected as SDSC Card!

大昔のカードなのでSDのバージョンは1.10です。
このカードはBIOSの更新用ブートメモリとしてUSBカードリーダと
組み合わせて今でも使用しております。

●RiDATA 256MB MiniSD

そして更に昔の11年前にMP3プレーヤー用に購入したMiniSDのカードです！
確か9870円くらいで買ったと思いました。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 7666 kB/sec.

>ds 0

rc=0

Drive size: 492544 sectors

Erase block size: 128 sectors

Default r/w block size: 512 bytes

Card type: SDv1

SpeedMode: NomalSpeedMode(25.72MHz)

DataBusWidth: 4bit



CSD:

00000000  00 7F 00 32 13 59 81 E0 EE BB 3F FF 16 40 00 E9 ...2.Y....?..@..

CID:

00000000  04 00 00 53 44 00 00 2A 10 00 00 03 3A 00 48 97 ...SD..*....:.H.



Parsing SD CID Register

Manufacturer ID    :0x4

OEM/Application ID :<0><0>

Product Name       :SD<0><0>*

Product HwRev      :1

Product SwRev      :0

Serial Number      :0x0000033A

DateCode.Month     :8

DateCode.Year      :2004



OCR:

00000000  80 FF 80 00 ....

SD Status:

00000000  80 00 00 00 00 00 00 14 00 00 00 00 00 00 00 00 ................

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  00 A5 00 00 00 00 00 00 ........



Parsing SCR

SD Spec Version    :0

SD Spec Version 3  :0

SD Spec Version 4  :0

SD Security        :2

SD Bus Width       :5



SD_Spec V1.0x!

Detected as SDSC Card!

なんとSDのバージョンはHighSpeedModeにすら対応していないV1.0です･･･
私が持つ最古のSDカードです。

●ATP ProMAX MiniSD 1GB x150

ねむいさんイチオシのメーカーATP製のカードです。
こちらは箱にSLCと明記されておりました。15000円くらいでヨドバシで
買った記憶があります。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 19499 kB/sec.

>ds 0

rc=0

Drive size: 1999872 sectors

Erase block size: 128 sectors

Default r/w block size: 512 bytes

Card type: SDv1

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  00 5E 00 32 5F 59 83 D0 6D B7 FF 9F 96 40 00 8F .^.2_Y..m....@..

CID:

00000000  09 41 50 41 46 4D 44 50 10 45 30 00 C2 00 63 DD .APAFMDP.E0...c.



Parsing SD CID Register

Manufacturer ID    :0x9

OEM/Application ID :AP

Product Name       :AFMDP

Product HwRev      :1

Product SwRev      :0

Serial Number      :0x453000C2

DateCode.Month     :3

DateCode.Year      :2006



OCR:

00000000  80 FF 80 00 ....

SD Status:

00000000  80 00 00 00 00 00 00 38 00 00 00 00 00 00 00 00 .......8........

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  01 25 00 00 00 00 00 00 .%......



Parsing SCR

SD Spec Version    :1

SD Spec Version 3  :0

SD Spec Version 4  :0

SD Security        :2

SD Bus Width       :5



SD_Spec V1.10!

Detected as SDSC Card!

やりますね～！

●ATP MicroSDHC4GB MLC (AF4GUD-ATP023)

こちらはSTM32F4のいつもので使用しているおなじみのATPのMicroSDHCです。
一般用なのでMLCです。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Mar 22 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 21173 kB/sec.

>ds 0

rc=0

Drive size: 7861248 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5F 59 00 00 1D FC 7F 80 0A 40 00 97 @..2_Y.......@..

CID:

00000000  09 41 50 41 46 20 55 44 10 26 3B 15 32 00 83 A5 .APAF UD.&;.2...



Parsing SD CID Register

Manufacturer ID    :0x9

OEM/Application ID :AP

Product Name       :AF UD

Product HwRev      :1

Product SwRev      :0

Serial Number      :0x263B1532

DateCode.Month     :3

DateCode.Year      :2008



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 02 00 00 00 03 03 90 00 08 05 00 00 ................

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 00 00 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :0

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V2.00!

Detected as SDHC Card!

速度も文句なし！

●ATP MicroSDHC4GB SLC (AF4GUDI-5ABXX)

そして同じATPの工業用のMicroSDHCです！！！！！
もちろんSLCなのですよぅ！実力やいかに！？

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Mar 22 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 16330 kB/sec.

>ds 0

rc=0

Drive size: 7892992 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 00 1E 1B 7F 80 0A 40 00 B1 @..2[Y.......@..

CID:

00000000  09 41 50 41 46 20 55 44 10 12 60 75 7A 00 F2 39 .APAF UD..`uz..9



Parsing SD CID Register

Manufacturer ID    :0x9

OEM/Application ID :AP

Product Name       :AF UD

Product HwRev      :1

Product SwRev      :0

Serial Number      :0x1260757A

DateCode.Month     :2

DateCode.Year      :2015



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 02 00 00 00 03 03 90 00 08 05 00 00 ................

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 00 00 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :0

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V2.00!

Detected as SDHC Card!

ぁ･･･あれ･･･？ま、まぁ工業用ですからピーキーな
性能よりも安定性を強化しているのでしょう(脂汗)
大事な事なので二度言いました。

●Sandisk Ultra8GB MicroSDHC

トリはSanDiskのSDカードたちです！
偽者が乱舞するSandisk製ですがねむいさんいちおうちゃんとしたお店で
買っているので偽者には引っかかっておりません･･･はず･･･

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 16421 kB/sec.

>ds 0

rc=0

Drive size: 15523840 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 00 3B 37 7F 80 0A 40 40 AF @..2[Y..;7...@@.

CID:

00000000  03 53 44 53 55 30 38 47 80 02 37 95 01 00 C6 87 .SDSU08G..7.....



Parsing SD CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :SU08G

Product HwRev      :8

Product SwRev      :0

Serial Number      :0x02379501

DateCode.Month     :6

DateCode.Year      :2012



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 03 00 00 00 04 00 90 00 14 05 1A 00 ................

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 80 01 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

ふつー･･･

●Sandisk UltraⅡ 8GB SDHC

このカードはお尻にUSBの端子が付いていてUSBメモリとしても機能します。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 14268 kB/sec.

>ds 0

rc=0

Drive size: 15954944 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 00 3C DC 7F 80 0A 40 40 C5 @..2[Y..<....@@.

CID:

00000000  03 53 44 53 44 30 38 47 80 01 9C 01 36 00 84 65 .SDSD08G....6..e



Parsing SD CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :SD08G

Product HwRev      :8

Product SwRev      :0

Serial Number      :0x019C0136

DateCode.Month     :4

DateCode.Year      :2008



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 03 00 00 00 02 02 90 00 0B 05 00 00 ................

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 00 00 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :0

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V2.00!

Detected as SDHC Card!

機能盛り込みすぎてちょっと速度が遅いですがしかたは無いです。

●Sandisk ExtremePRO SDXC64GB(FAT32フォーマット)

そして！現在TG-3用の記憶媒体としてバリバリに使っていますExtremePROの
64GBのカードです！！！

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Mar 25 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 16448 kB/sec.

>ds 0

rc=0

Drive size: 124735488 sectors

Erase block size: 32768 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 01 DB D3 7F 80 0A 40 40 DF @..2[Y.......@@.

CID:

00000000  03 53 44 53 50 36 34 47 80 F2 D6 14 07 01 01 D5 .SDSP64G........



Parsing SD CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :SP64G

Product HwRev      :8

Product SwRev      :0

Serial Number      :0xF2D61407

DateCode.Month     :1

DateCode.Year      :2016



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 08 00 00 00 04 00 C0 00 0F 05 3A 00 ..............:.

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 45 84 03 00 00 00 00 .E......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Security        :4

SD Bus Width       :5



SD_Spec V4.xx!

Detected as SDXC Card!

ありゃりゃ･･･
ま･･まぁ･･･FAT32で無理糞フォーマットしてますしそのせいでしょう(脂汗)
カードのﾓﾉとしてはSDのバージョンも4の最新のやつです。
今回の評価でSDバージョンが4の奴はこれと並行輸入版EXCERIAだけでした。
どうでもいいですけどeraseblocksizeが32768セクタもあります。

●I/ODataのClass4 SDHC4GB

ねむいさんのおとうちゃんから｢お前が山に行った時の写真分けてくれ｣と
頼まれ手渡されたどっかの家電量販店で買ってきたかのようなデータ保存用の
やっすいカードです。どうせゴミみたいな性能だろうから哂ってやるつもりで
半ば冷やかしにベンチとってみたのですが･･･

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Mar 25 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 19063 kB/sec.

>ds 0

rc=0

Drive size: 7878656 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 00 1E 0D 7F 80 0A 40 00 A5 @..2[Y.......@..

CID:

00000000  1D 41 44 53 44 20 20 20 10 A0 90 08 0A 00 02 E3 .ADSD   ........



Parsing SD CID Register

Manufacturer ID    :0x1D

OEM/Application ID :AD

Product Name       :SD   

Product HwRev      :1

Product SwRev      :0

Serial Number      :0xA090080A

DateCode.Month     :2

DateCode.Year      :2000



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 02 00 00 00 02 02 90 00 08 11 00 00 ................

00000010  00 00 00 00 00 00 00 00 00 53 4D 49 00 00 00 00 .........SMI....

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 51 00 00 00 00 32 00 00 00 00 00 00 00 ...Q....2.......

SCR:

00000000  02 35 80 00 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

>132949600 bytes read with 19063 kB/sec.
なん･･･だと･･･！？

･･･
こ、こう言うベンチマークの結果は特に気にせず皆様はそれぞれが納得し信頼できる
メーカのSDカードを選んで使用していただければよいと思いますよ(脂汗)

STM32F7を使ってみる11 -最新のeMMCを動かす-

前回までは古き世代の遺産であるマルチメディアカードをSTM32F7で再び動作せしめる
までになりましたが、今回は新しい世代へと進化したeMMCモジュールの動作に
ついに、ついに挑みます！

eMMCは最早カードの形状ではなく、ごく一般的なICの形となっていますがそれが
故に使い慣れたSDカードコネクタとかで使うには少々骨が折れます。
市販のギャングプログラマ用のSDカード変換付きソケットは100$以上するのであんまし
手を出したくはないです…
簡単かつ確実に使う良い方法ないかといろいろ探ってみるとODROIDと言うLinux系の
ARMボード向けのオプションパーツとしてeMMC実装済みのMicroSDの変換基板が販売
されているのを発見しました！

SouthKorea製なのがほんの少し心配でしたが値段も送料込みで38USD
(2016年3月下旬時点)だったので早速注文してみました！！

で、発注後4日くらいで親父の家に届きました。一週間以上かかるかと思いましたが
予想以上に早かったです。Androidを意識した質素の箱の作りで"Do it yourself"
なるコメントがあります。

一応ぷちぷちにくるまれていましたがこの色って静電対策してないやｔ

これって静電対策してないやｔ
まぁでもうごけばいいのですよぅ動けば！！

ボードとしてはｺﾃｺﾃの南朝鮮製ですが実装されているeMMCは東芝製で容量8GB,
そして規格はeMMCv5の最新版です！！！

一応コリアンボードのmicroSDへの変換パタンもやっけつではなく信号のIntegrity
を考慮した配線をしてくれているようです。

eMMCは古いタイプのカードリーダーでは認識すらしない場合があります。
ねむいさんが昨年購入したUSB3.0のTranscend製のカードリーダーでは無事に
認識できました♥
もともとこのeMMCはODROIDのオプションパーツとして販売されているので、
こんな風に最初から何らかのOSが仕込んであります。

ねむいさんはそんなもん関係なくeMMCを使用すること自体が目的なので速攻
FAT32でフォーマットして更地にてやりました！！！

前回の最後でちょろっと漏らしているように実は公開したF7のサンプルでは
既にeMMC(とMMCのブロックアドレッシング)に対応しております。

ビルド時間は結構長いので暇つぶしがてらF7からeMMCのルーチンを移植中の
STM32F4の板に差して反応見てみるかと思ったらなんと普通に認識してしまった…。
拍子抜けするくらいあっさり読めちゃって感動もへったくれもない…
ぇっ！？黒澤ダイヤちゃんのお口がｲｹﾅｲことになってるって！？何のことやらﾊﾊ
虹裏メイドねむいさんは｢ラブライブ!サンシャイン!!｣を応援します。

さてビルドが終わってF7のプログラムの書き換えも終わったのでF4板から外すか
…と思ったら…

あ…あれ…？？？

･･･
案の定HELL朝鮮製ボードに罠がありました…微妙にサイズが大きいようで刺さる
には刺さるんですけど安易に抜けません(意味深)。
無理やり引き抜くと基板で擦れてMicroSDコネクタを壊してしまいます…

てわけで削ります。
いきなりF7-Discoveryで試さなくてよかった…

ｺﾞﾘｺﾞﾘ削ってこんな感じに…

うまいこと削れたのでF7-Discoveryのコネクタにスムーズに差さります。

F7でも無事に認識して画像や動画データも自由自在に読み出しできます♥

このeMMCは8GBの容量でSDHCと同じくブロックアドレッシングになります。
私の移植例ではMMCv4以降に新設されたブートパーティション等にアクセス
するための特別なコマンド群は使用しておらず、SDHC/SDXCと同じ感覚で読み
書きします。腕に自信がある人、私のコードを参考に拡張してください･･･(懇願)

そしていつも通りカード(？)の情報を読み出してみました。

>ds 0

rc=0

Drive size: 15269888 sectors

Erase block size: 1024 sectors

Default r/w block size: 512 bytes

Card type: MMC(Block)

CSD:

00000000  D0 5E 00 32 0F 59 03 FF FF FF FF EF 92 40 00 D3 .^.2.Y.......@..

CID:

00000000  11 01 00 30 30 38 47 45 30 00 5A DD 41 40 B2 0D ...008GE0.Z.A@..



Parsing MMC CID Register

Manufacturer ID    :0x11

OEM/Application ID :<0>

Product Name       :008GE0

Product Rev        :0.0

Serial Number      :0x5ADD4140

DateCode.Month     :11

DateCode.Year      :1999



Detected as MMCv5.0x Device!

OCR:

00000000  C0 FF 80 80 ....

前回述べたとおりMMCv4.xx以降はExtCSDレジスタを読み出すのは重要です。
MMCv4以降のバージョン判定はExtCSDREVフィールドを参照し解釈する必要
性があります。ちなみにこの東芝のeMMCはv5とのことですがですが読み出すと
ExtCSDREVは”7”となりちゃんとv5のデバイスであることが分かります。
ちなみにdatecodeが1999とあるのはCIDレジスタの年数を示すフィールドが4bit分
しかないので2012年を境に年数が一巡してしまっているからです。最新のMMCAの
データシートではExtCSDREVから2012年以降を判別せよというようになっていますので
~~次回リリースでこちらも修正します。~~差し替えました。
一方、SDカードでは年数を示すフィールドは6bit分あるのであと50年くらい安泰です。

FatFs module test terminal for STM32F746NGH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Mar 31 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 22000 kB/sec.

>

シーケンシャルライトも見てみました。F7のサンプルではSDIO_CLKはMAX48MHz
かつ4bitモードの設定がeMMCで可能ですがご覧のとおり理論値に近い読み出し
速度が出ました。やるじゃない！

FatFs module test terminal for STM32F746NGH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Mar 31 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 20753 kB/sec.

>

因みに前回紹介したMMCPLusも結構速いです。

と言うわけでユーザー領域のみですがeMMCでもSDHC/SDXCと同じく読み書きする
ことが出来るようになりました！今秋くらいに市場に出回るであろうSTM32F777等の
最強に強まったF7シリーズではSDMMCが二つに増えるので基板付け置きのeMMC
(とかMCP)が今後は発言力を増してくると思います！！

今回の成果はSTM32F4系やSTM32F1系、そしてLPC4088のMCIにも移植しています
のでどんどん試して下さい！ついでにバグもこっそり教えてもらえると助かります☆

STM32F7を使ってみる10 -いにしえのマルチメディアカードを動かす(うごかす編)-

ぇえええぇぇえええぇええ(どん引き)
↑イレギュラー化した部下に突如愛の告白されるシグマﾀｲﾁｮｳ風に

いったいいつからIF誌はねむいさんのお株を奪うようなシモネタを炸裂させる
ようになったのでしょうか…???今回はちょっと笑えたので許しますが。
ああプロテインってそういう･･･

そんなどうでもいいことは置いといてさっさと本題に掛かります！！！！！前回は
microSD->SDの変換アダプタ作っただけで力尽きましたが今回は実際に動かします。

先ずはebayで購入した2GBのMMCPlusカードです！

MMCPlusの規格なので8bitバスで転送もできます…がソケットの互換性を考えると、
4bitバスモードで動かした方が無難でしょう。
因みに妙に汚いように見えますがUSEDでした。MMC自体最早新規生産なんかしてない
ので致し方なしです。カードとして正しく動作すればOKです。

で、その前に問題のソフトウエアの方ですが…こちらでも紛糾してるように
STM32CubeHALライブラリにMMCのサポートは全く有りません。それどころかなんと
過去のSPLには対応していたSDv1.xx系カードのサポートすらもHALライブラリでは
おもいくそぶっちされておりました！！！F**K!!

とりあえずSDv1.xx系のサポートは復活させて動作確認したのですがMMCネイティブ
モードにおけるイニシャライズはどうしたらいいのか全く分からなかったので
暫くの間ネットの海にダイブして情報を沢山漁ってきました。

幸いにもJEDECのMMCの規格は2016年現在は一般人でも公式のJEDECのサイトから
容易に入手することが出来るようにになっていてさらに中華圏のサイトでは
動作するかどうかは不明ですがSTM32向けのeMMCドライバも入手出来たので
それを参考にMMC向けのドライバをF7のHALライブラリ向けに組み込みました。

当然最初は思った通りに動かなかったのですがSTM32のSDIO/SDMMCのハード
ウエア自身にかなりクセがあることが分かり、クセを理解して全種類のカードを
イニシャライズせしめるよう克服していきました。
以下にMMCPlus/MMCv3なカードを使い認識していく過程をデバッガで実動作を
追いながら解説していきます。

STM32のSDカードドライバは基本的にSDv2->SDv1->MMCの順に認識しようとして
いきます。これは現在のSDカードの規格においても推奨される初期化手順と
されています。カードをリセットするCMD0を除くと最初に放たれるのはCMD8です。

MMCとSDv1系ではSDHC用初期化CMD8:SEND_IF_CONDはタイムアウトエラーとなります。
過去のSTM32のSPLに収録されているsdカードのサンプルではその状態から
なぜかCMD55を単品で投げてから改めてCMD55+ACMD41を投げていました。

CMD8が撥ねられた後いきなりCMD55+ACMD41を撃つとSDIOモジュールがエラーで
コケる対策にCMD55を空撃ちしていた感じです(SPLではあったけどHALライブラリ
はそれすらない!)。これはCMD55を受け付けるSDカード系は問題ないのですが
MMCv3以前だとCMD8が撥ねられた後のCMD55の空撃ちがILLEGAL_COMMANDとなり
またまた撥ねられてしまい、先に進めません(※MMCv4以降はこのCMD55が通ります)。

と言うわけでCMD55の代わりにCMD0でカードをリセット状態にしてから改めて
CMD55+ACMD41を送るようにするとうまく先に進めました！勿論SDv1系でも
CMD55の空撃ちではなくCMD0で問題有りませんでした。

MMCではCMD55+ACMD41は当たり前ですがタイムアウトエラーとなります。

先ほどと同じくCMD0を送りMMCをリセットしますが、eMMC対応を考えて引数を
0xF0F0F0F0にしたCMD0の後0x0000000な引数のCMD0を送るようにしてみました。

ここまで来てようやく本来のMMCの初期化ができます。
CMD1を送ってSDカードの｢ACMD41｣と同じように初期化します。
が、ブロックアドレッシング必須のSDHCと同じくCCSビット(0x40000000)を
ORして引数に渡さないとブロックアドレッシングを必要とするMMCv4.x以降の
規格では初期化が完了できませんのでしっかりとおっ立てた状態で引数として
わたしましょう。ちなみにv3以前のカードにおいてはCCSビットが立っていても
影響は受けずスルーされて初期化がそのまま通るので問題ないです。

上手く初期化が出来たらOCRレジスタの0x80FF8080が読みだされます。
MMCPlusでDualVoltage対応なので上記の値となっています。
因みにv3以前のカードでは0x80FF8000,ブロックアドレッシングな
v4系のデバイスでは0xC0FF8080が帰ってきます。
ここまで認識が通ったらだいぶ気が楽になります。

所でMMCv4.x系のカードでは新たに追加されたExtCSDレジスタから512バイト分の
追加情報を取得可能です。実はこのExtCSDは4GB以上のeMMCの総容量計算では
必須のビットが存在しています。

212～215バイト目がそのSEC_COUNTフィールドなのですがここに総セクタ数が
記録されていて512を掛けると総バイト数が分かる仕組みになっています。
この2GBのMMCplusではSEC_COUNTフィールドからの算出方法でもCSDレジスタ
から算出する従来の容量計算方法(計算式はSDv1系と全く同じ)でも両方とも
可能です。

初期化を越えたらクロックを転送用の高速クロックに上げていきますが…
MMCv4系では最大52MHz,8bitバスモードまで動かせられます。当ぶろぐでは
4bitバスモードまでとします。MMC専用の呪文を投げる以外はSDカードの
4bit化やHighSpeedMode化と流れは同じです。そして…

無事ファイラーからディレクトリが読みだされました♥

サイズのでかい動画でもカクカクせずスムーズに動きます☆
(後でかなり早いカードなことが分かった)

お次はさらに古いMMCv3世代のカードです。容量はたったの128MB!
そしてもちろん中古品。

初期化を越えたらクロックを転送用の高速クロックに上げていきますが…
10年以上前のものですがちゃんと現在のPCカードリーダーからも認識できます。

MMCv3系のカードなので数が7ピンしかありません。MMCネイティブモードでも
当然バス数が1bitです。早速こちらも動きを追ってみましょう！

CMD1の初期化を終えるとOCRレジスタの0x80FF8000が読みだされました。

初期化を越えたらクロックを転送用の高速クロックに上げていきますが…
MMCv3系はクロック上限値が20MHzできっちり線引きされていてそれ以上はまず
動作しないので20MHz以下にクロックを落とす工夫が必要です。もちろんデータ
バス幅は1ビットのままです。

さすがに遅いですけど無事認識です♥

上記2つのカードの各レジスタをSDカードと同じようにパースしてみました。
CIDレジスタの扱いがSDカードと微妙に違うので注意です。
そんでもってMMCv4以上の細かいバージョン識別はExtCSDの"ExtCSDVER"
フィールドを読みだして解釈する必要があります。
eMMCの使用をにらんでこちらも正しく解釈できるようにしておきました。
●2GB MMCPlus

>ds 0

rc=0

Drive size: 3939328 sectors

Erase block size: 256 sectors

Default r/w block size: 1024 bytes

Card type: MMC(Byte)



CSD:

00000000  90 2F 00 2A 1F 5A 83 C1 B6 DB 9F FF 96 80 00 3F ./.*.Z.........?

CID:

00000000  37 FF FF 4D 4D 43 30 32 47 10 F3 02 67 50 2C F5 7..MMC02G...gP,.



Parsing MMC CID Register

Manufacturer ID    :0x37

OEM/Application ID :

Product Name       :MMC02G

Product Rev        :1.0

Serial Number      :0xF3026750

DateCode.Month     :2

DateCode.Year      :2009



Detected as MMCv4.0 Device!

OCR:

00000000  80 FF 80 80 ....

●128MB MMCv3

>ds 0

rc=0

Drive size: 250880 sectors

Erase block size: 32 sectors

Default r/w block size: 512 bytes

Card type: MMC(Byte)

CSD:

00000000  8C 26 01 2A 0F 59 81 E9 F6 DA 81 E3 9E 40 00 7D .&.*.Y.......@.}

CID:

00000000  11 00 00 30 31 32 38 4D 32 0A 05 80 FE CB 28 7D ...0128M2.....(}



Parsing MMC CID Register

Manufacturer ID    :0x11

OEM/Application ID :<0><0>

Product Name       :0128M2

Product Rev        :0.10

Serial Number      :0x0580FECB

DateCode.Month     :2

DateCode.Year      :2005



Detected as MMCv3.xx Device!

OCR:

00000000  80 FF 80 00 ....

>

いろいろありましたがMMCの動かし方も上手くモノにすることができるように
なりました！次はいよいよMMCから進化したeMMCの動作に挑みます！！

今回の更新はすでにおきぱに上げてあります。eMMCのSD変換アダプタを持ってるひとは
いいことあるかも･･･！？

●おまけ
前回言及したCubeF7のバグですが、｢とりあえずuint64_tでキャストしときゃ
いいだろ｣が祟って出てしまったカルマなのですが実際どうなるかをSTM32上で
確かめて見ました。

先ず使用する変数/定数は以下とします。
#define SECTOR_SIZE 512
uint64_t unk0;
uint32_t tnk = 8388612; /*512を掛けるとオーバーフロー*/

まずキャスト無しの場合…
unk0 = tnk * SECTOR_SIZE;
この場合は、普通にuint32_tの演算として扱われオーバーフローしたぶんは
そのまま頭が切られます。よって0x100000800ではなく0x800がunk0に代入
されました。

次に括弧でくくってuint64_tでキャストしてみます。今回フォーラムで指摘
されてたのがこのバグです。
unk0 = (uint64_t)(tnk * SECTOR_SIZE);
これもunk0に0x800が代入されてしまいました。*の演算を括弧でくくってしま
ったためにやっぱり0x800になっちゃいました。

正しいキャストの仕方がこちらです。
unk0 = (uint64_t)tnk * SECTOR_SIZE;
uint32_t変数のtnkをuint64_tにキャストしたうえでSECTOR_SIZEを掛けることで
0x100000800がunk0に正しく代入されます。

これ結構引っ掛かりやすいポイントなので私も気を付けるようにします。
フォーラムで指摘されるまで私も気づいて無くて同じミスしてましたがorz

因みにMMCv4.x系のSEC_COUNTの計算で
(代入先が64bit変数の場合)

(uint64_t)((uint64_t)(ext_csd.EXT_CSD.SEC_COUNT[3] << 24 | ¥

                       ext_csd.EXT_CSD.SEC_COUNT[2] << 16 | ¥

                       ext_csd.EXT_CSD.SEC_COUNT[1] << 8  | ¥

                       ext_csd.EXT_CSD.SEC_COUNT[0]));

もしくは

(uint64_t)((ext_csd.EXT_CSD.SEC_COUNT[3] << 24 |  ¥

                       ext_csd.EXT_CSD.SEC_COUNT[2] << 16 | ¥

                       ext_csd.EXT_CSD.SEC_COUNT[1] << 8  | ¥

                       ext_csd.EXT_CSD.SEC_COUNT[0]));

もしくは

((ext_csd.EXT_CSD.SEC_COUNT[3] << 24 | ¥

                       ext_csd.EXT_CSD.SEC_COUNT[2] << 16 | ¥

                       ext_csd.EXT_CSD.SEC_COUNT[1] << 8  | ¥

                       ext_csd.EXT_CSD.SEC_COUNT[0]));

と誤った式にしてしまうとext_csd.EXT_CSD.SEC_COUNT[3]の最上位ビットに1が立つ
ような値がSDカード/eMMCから得られた場合、uint64だろうがint64だろうが負の値と
みなされた状態で整数拡張されて上位32bitが0xFFFFFFFFでパディングされた状態で
64bit変数にキャストされてしまい、結果として意図しない値がストアされてしまいます。

ですので、

(uint64_t)((uint32_t)(ext_csd.EXT_CSD.SEC_COUNT[3] << 24 | ?

                       ext_csd.EXT_CSD.SEC_COUNT[2] << 16 | ¥

                       ext_csd.EXT_CSD.SEC_COUNT[1] << 8  | ¥

                       ext_csd.EXT_CSD.SEC_COUNT[0]));

もしくは

(uint32_t)((ext_csd.EXT_CSD.SEC_COUNT[3] << 24 | ?

                       ext_csd.EXT_CSD.SEC_COUNT[2] << 16 | ¥

                       ext_csd.EXT_CSD.SEC_COUNT[1] << 8  | ¥

                       ext_csd.EXT_CSD.SEC_COUNT[0]));

として頭をきっちり削っておけば問題ありません。

ってわけで型の合わない変数に何も考えずキャストとか代入したらこうなります
なったorz

いろいろ試す22

30日は〆のトレランに行くので年末恒例の奴を今やらせていただきます･･･

●フェライトビーズの使いどころ

注：SDMMC/SDIOのCLK信号に対してはまず初めに直列終端を行ってください。
　　それでもだめなら下記フェライトビーズの使用を考えてください。

ねむいさんはおきぱでSTM32のFatFs移植サンプルを公開してることから｢FatFsが動き
ません＞＜｣という漠然とし過ぎる困った質問を今でもコンスタントに頂くのですが、
もはやその原因の99.99%が単純な結線ミスとか接触不良が起こりやすいブレッド
ボードで配線30cmくらい引き伸ばしまくって通電してたとかそんなモン動くわけ無い
でしょ的内容だったのですがまた新たに別のクリティカルヘンテコな報告を頂きました。

最短の配線でSTM32F407ZGT6の基板を起こしたにもかかわらず昨今のUHS-1のカード
ではSDIOで認識すらしない、クロックの速度を落としてもダメで昔のUHS表記が無い
Class6とかのカードならOKというこれまた奇怪な不具合だったのです。

STM32のSDIOは1.8VのUHS-1の高速クロックモードには対応しておらず、早くても
HSモード(3.3V/52MHz)ですがHSどころかNSモード(25MHz Max)でもダメとのこと。
ダメなカードも型番を教えてもらったのでPCOnes'sで購入して私も試して見ました。
TranscendのmicroSDHCカード Class 10 UHS-I 600x (Ultimate) なるものです。

謎のMLCアピール･･･。

私が持ってるSTM32F407ZG系の基板は紅牛に無理やりF4を乗っけた基板です。
配線長もなるべく質問を頂いた方と合わせるようにmicroSDソケットを無理やり
とりつけてました。

で、こいつで試すと確かにHSどころかNSモードのクロックでも全く認識しなかった！
念のため別の会社のUHS-1のカードも複数枚試しましたが結構な確率で認識できない
ものが存在していました･･･！UHS無しのClass10表記の奴やねむいさん愛用のATPの
Class6の4GBの奴はエラッタもちのF407系のいんちきHSモードでもバッチリ認識
できてるのですが･･･ひとまず信号の測定に掛かります。

これがATPのmicrosdhcのクロックの波形(NSモード/24MHz)です。

んでもってこっちがTranscendのほうの波形(NSモード/24MHz)。
ATPのよりも信号のふり幅が狭くなおかつリンギングも激しくなってる感がしますね。

波形の測定に関してはGNDリードの影響を抑えるために当然最短にして測定して
います。あとPCオシロのトリガはETSモードにして等価サンプリングレートを
10GHzとしてます。
STM32のSDIOのクロックはパワーセーブにしない限りは常に出っ放しになるので
繰り返し信号として測定でき、精確な波形測定ができるわけです。

話を戻しますが二つの波形の違い、なぜこんなに違うかですがこれはUHS-1のカードは
100MHz以上で動作できるUHSモードで転送する際はNSモードやHSモードよりも高速な
立ち上がり/立ち下がりを当然要求されるわけでそれに合わせてI/Oをこしらえて
いますが、悪い条件が重なったときに信号の反射によってオーバーシュートや
リンギングが激しく出ることになります。
過去のClass表記のみのカードでは高々50MHzまで動けたら良かったので高速な
I/Oを必要とせず、オーバーシュートやリンギングは同条件でもそこまで大きくは
ならない･･･と想定できます。

さて、状態は観測できたので後は対策です。こういうケースの場合はフェライト
ビーズを各信号ラインに直列に入れてやると効果が出るはずです。

いろいろ試してねむいさんの手持ちのフェライトビーズの中ではBLM18BB121SN1Dが
かなり効果があることが分かりました。この対策で認識できなかったUHS-1のカードも
無事見ることができました(NS/HSモード共)。

これが対策後のTranscendのCLKの波形です(NSモード/24MHz)。
リンギングがしっかり抑えられてるのが分かりますね～。

こんな感じに無理糞つけけております。
念のためTranscendのとは別の認識できなかったUHS-1のカードも試してみましたが
すべて無事認識できるようになりました。ちゃんと対策として効いているようです♥

これより大きい抵抗値の奴ではHSモードでクロックが大きく崩されすぎてダメになって
しまいます。やっぱり程々が大事です。
また、秋月さんのとこで購入できるタイプのフェライトビーズでは特性が少しなだらか
なため余り効果が出ませんでした。とはいえねむいさんが選んだ奴もかなりピーキー
なのでそのまま真似しても多分効果は出ないと思います。

こういった信号の反射の影響度合いは設計するボードごとに大きく変わってくるので
オシロとにらめっこしながらカットアンドトライをしなければならない領域です。
GNSSモジュールの時も言いましたがむやみやたらにフェライトビーズを突っ込み
まくっても逆にノイズやリンギングをパワーアップさせてしまうことになりかねません。
また、オシロのプローブも見たい信号を正しく測定できるようにGNDリードを超最短
にするなどの配慮も必要で開発者としての様々なセンスが問われることになります。

と、ここまで苦労してSDIOの信号波形整て認識できるところまで持ってきましたが、
GPIOが速度面で強化されたSTM32F43x/42x系とかF7系を最初から使っとけば
上記のめんどくさいことをなーんにもやらなくても安定してSDカードを読み書き出来
たりします･･･酷いオチだ･･･。

全然関係ないですが大阪日本橋のPCOne'sでSDカードのついでに買ったスマホ置き台が
STM32F7Discoveryとぴったりフィットできる形状なので重宝してます♥

●GCC ARM Embedded in Launchpadの2015年Q4版が出る！
一年に４回リリースされるLaunchpad GCCの最新版がリリースされています。
今回はついにGCCバージョンが5になりました！

早速新旧比較をしてみたいと思います。まずは同じ条件でビルドした際のバイナリ
サイズ比較です。条件は以下のとおり。

・F7のいつものの20151224版
・SDMMCのクロックはNomalSpeed(24MHz)
・-Ofast,HardFP
・AXIMからフラッシュ実行/SDRAM有効/フォントは内蔵フラッシュに格納
・使用SDカードはAF4GUD、SDFormatter4.0でフォーマット

旧：2015q3版(GCC4.9.3)

arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.9.3 20150529 (release) [ARM/embedded-4_9-branch revision 224288]

Copyright (C) 2014 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.  There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 602096	      0	 602096	  92ff0	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

 599808	   2288	 821392	1423488	 15b880	main.elf

新：2015q4版(GCC5.2.1)

arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 5.2.1 20151202 (release) [ARM/embedded-5-branch revision 231848]

Copyright (C) 2015 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.  There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 612272	      0	 612272	  957b0	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

 609984	   2288	 821392	1433664	 15e040	main.elf

バイナリサイズは2015q3版より10kByteほど増えてますね･･･
今度は実行処理速度比較です。SDRAMの時と同じようにlibjpegの展開時間の比較を
行ってみました。

旧：2015q3版(GCC4.9.3)

新：2015q4版(GCC5.2.1)

･･･イケてるじゃないですか･･･(セルピコ顔で)
なんか去年もモズグス編のセルピコさんになった気がしますが、最適化の悪影響が
及んでるかもしれないのでもうすこし様子見して安全性を確かめたいとおもいます。
丁度明日は今年最後のトレランに行くので屈作のSTM32Primer2GPSTr@ckerに2015q4版で
ビルドしたバイナリを書き込んで試してみるつもりです★

●Firefox版赤福が署名に対応する
虹裏関連のお話ですがFirefox版赤福spが署名チェックに対応することになりそうです

FirefoxはVersion44から拡張の署名が強制になり署名が無い拡張は撥ねられて
動作不可能になるとアナウンスされており署名が無い赤福spが使えなくなると
言われていましたが･･･作者の方ももう気付かれて対処されるようなので等分の間は
安泰でいられると思います♥

この調子で合間合間にも対応してくだち･･･

●年末恒例のねむいさんFAQ

Q:わたしは(何らかの下らない他人の自慢話なので省略)
　なぜOpenOCDにこのバグが組み込まれてしまったか考えてみてください。
　↑(原文ママ)
A:ねむいさんこの質問風八つ当たりにうっかりｸｿ真面目に答えてしまいました。
　ウブなねむいさんはこのバグの部分とは無関係だったにもかかわらずソースコードの
　更新履歴を丹念に調べエンバグされた経緯と対策まで連絡してあげました。もちろん
　質問された~~ｸｿ野郎~~方からその後どうなったか返事なぞまったくいただいて
　おりませんが、実はkinetis.cにある致命的な"このバグ"はまだ修正されておりません
　が、
　次に同じようなこと聞かれたら適切な返事を返してあげようと思います。
　バカめと。
　↑20160212追:
　kinetisドライバに真っ当にご助言いただいた方々にこれは俺の事かとお叱りの
　メールを幾つもいただいてしまいました。誤解を招きまことに申し訳ございません。

　致命的なバグはとあるぱちもんデバッガ使ったときに発動するのですが、
　ねむいさんに対してそういう情報隠して正規品使ってると秒速でバレる嘘ついて
　"動くようにしろ""対処してください"とかいって情報聞き出してくる奴は絶対に
　許さないのでそういった御仁たちは拙者尽く伊達にして返すでござる。

Q:ねむいさんってツイッターとかしてないんですか？
　所詮は批判を恐れ安全な場所から一方的に意見を言い放つことしか出来ない
　ﾃｨｷﾝなのですか？
A:それはイエスでもありノーでもありますのだわ･･･(第五ドール風に)
　ねむいさんはいろいろあってツイッターやめた代わりにこのねむいさんのぶろぐを
　立ち上げました。かれこれ7年位前のはなｓ･･･グハッ！！！！

Q:ねむいさんってLINEとかしてないんですか？
A:ま　だ　ガ　ラ　ケ　ー　使　っ　て　ま　す

Q:スマホでピッ！簡単電子工作★
A:ま　だ　ガ　ラ　ケ　ー　使　っ　て　ま　す
　っ　て　言　っ　て　る　で　し　ょ　ｺﾝﾁｸｼｮｰ

(以下ほぼ実際にあったやり取りですだいぶ前の話ですがもう時効だから書きます)
Qr:鶴岡工場(旧NECエレ系列工場)閉鎖ね
A:あっそ良かったねおめでたうございまｓ･･確かここって旧NECの･･･
Qr:ついで(?)にあんたのところのASIC生産中止だね
A:何ですって･･･!?
Qr:この前のが最終ロットね。今までご利用いただきありがとうございますを
A:あ”！？(CV柴田理恵)
Qr:代わりに弊社のSmar●tAnalogをご採用願います(営業スマイル)
A:カエレヤ！！
　(ここでルネサスと完全に手が切れPSoC5を採用しかけたが･･･)

Qp:gff...ねむいさんねむいさんそのセミカスタムのASIC、こちらでも
　起こせますよ･･･(はげたかのような目で)
A:オゥこれはありがたい･･･

Qrohm:ルネサスさんからのディスクリートデバイスの置き換え表ありますよ･･･
　　　･･･gff(はげたかのような目で)
A:オゥこれはありがたい･･･

ディスクリートデバイスは旧NECエレでがっちり固めてたからヤバかったです。
R○HMさん(○は伏字)ありがたう！！！
今は東芝半導体がチャレンジ()の成果もあってRenesasに合体しそうでやばそう
ですね･･･東芝さんのもかなり使ってるんですけぉ･･･

さぁそれはおいといて明日も早いから寝ましょう･･･Zzz･･･

↓としあきくんからのリクエスト↓
Q:カレンと金剛の声の区別が付かないﾃﾞｰｽ
A:ﾈﾑｲｻﾝも区別付かないﾃﾞｰｽ(CV:柴田理恵)
　･･･と言うのはおいといておすぎさん(悪堕ち)とピーコさん(純粋悪)に同時に襲われたら
　ピーコさんと間違えて悪堕ちした無罪のおすぎさんをうっかり攻撃してしまうくらい
　"うつけ"です･･･

Q:ねむいさんって雑誌に投稿したりしないの？
A:どのジャンルのこといってるのか分かりかねますができたらとっくにやってます。
　そいえば2014年初夏にC9出版のドメインのメアドで｢記事作成を手伝って
　みませんか？｣という何か目的をぼかした内容のしかも文語体と口語体が混じっておまけに
　芝まで生やしたメールを頂いたのですがちょっと怪しかったのでCQ出版の
　お問い合わせにメールで(差出人の方の名)さんはそちらに在籍されていますか？
　とたずねたのですが問い合わせをしてからはや約１年と８ヶ月、何の音沙汰も
　ありません。問い合わせついでにトラ技の誤植を指摘したのがいけなかったのでしょうか･･･
　やっぱし本当にフィッシング目的の偽装メールだったかも。

Q:ブラギガスを検索したら諸星きらりが何故かサジェストに出てきました。
　虹裏メイドのねむいさんはなにか知ってそうな顔してますが･･･洗いざらい吐け
A:にょわー(野太い無理やりな高い声で)
　↑もし隣からこんな絶叫きらり語聞こえたら速攻警察屋さん呼びますよぅ！！

2015.12.29 Tuesday
23:24
ネムイ・トリノミアス
MISC
-
-

STM32F7を使ってみる8 -CubeF7のHALライブラリにバグ-

クリスマス前に副業先で超F**Kな出来事が立て続けに起こったおかげで土日も
それの対応に追われホント超F**Kな気分でしたがやっと自体が収まりつつある
のでぶろぐ更新してみました。あと本業(虹裏メイド)のほうもステキなクリプレ
完成しましたからとしあき君たち替えのぱんつ用意して待ってなさい！！
以上業務連絡終り。

●STM32F7Cubeが更新
少し前にCubeF7ライブラリがV1.3.0に更新しておりました。前回指摘されていたHAL
ライブラリ中のSDカードの容量を正しく取得できないバグは直っておりました。
容量計算のための変数をuint32_tで取っていたので32GByte以上の容量のカードだと
値がおかしくなっちゃうという昨今の大容量化では良くある光景です。

どうやらCubeF7に収録されているデモとかでは影響が無かった為かユーザーに
指摘されるまで気付かなかったようです。Cube系ライブラリに移行してから
ずっとこんな調子ですがねむいさんも新たなバグを見つけてしまいました。

●おっと新バグ発見伝
今回の更新にあたり、fatfsのsdmmcドライバで今まで適当に作りこんでいた
SDカードの内部レジスタを読み出す部分のルーチンを見直して正しく取得できる
ようにし、更にCIDレジスタをパースする機能を追加してみたのですが何でか
いくつかの値がちゃんと読み出せず、ちょっと困っていました。
デバッガで追って調べるとなんとHALライブラリ側にバグがありました。

HAL_SD_GetCardStatus()という関数の冒頭でステータスレジスタを取得する
内部変数のバッファをuint32_tで宣言しているのですが、取得後pCardStatusの
各構造体要素に代入する際にuint8_tの配列と勘違いして処理して代入してました。

↑HAL_SD_SendSDStatus()の2つ目の引数がuint32_t*なのでそれに合わせて
　しまった模様

実は過去のSTM32F4などの標準ペリフェラルライブラリ(SPL)では
HAL_SD_GetCardStatus()に相当する関数内で最初からuint8_tとして宣言して
いたのでこの問題は出なかったのですが･･･完全にエンバグですね･･･
(SPLのほうも微妙にバグってますが)というわけで対策はSPLの真似して配列を
uint8_tで64バイト分宣言すれば終りです。

このバグはSDカード使う人は結構踏んでると思うのでSTマイクロの公式のフォーラム
にも報告しておきました。bugって文字が乱舞するようになったフォーラム
ですが新たなbugがまたひとつ。

そんなわけで上記のバグを潰してUARTから操作するChaN氏のFatFsのデモでds
コマンドを打った時のSDカードの各レジスタのダンプに加えてCIDレジスタを
パースする機能を無事追加できました。SandiskのExtremePRO microSDHC 8GBを読み出した
際の表示は↓こんな感じになりました。
してます★



>ds 0

rc=0

Drive size: 15523840 sectors

Erase block size: 8192 sectors

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 5B 59 00 00 3B 37 7F 80 0A 40 40 AF @..2[Y..;7...@@.

CID:

00000000  03 53 44 53 55 30 38 47 80 1B B8 C2 F6 00 C8 2F .SDSU08G......./



Parsing CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :SU08G

Product HwRev      :8

Product SwRev      :0

Serial Number      :0x1BB8C2F6

DateCode.Month     :8

DateCode.Year      :2012



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 03 00 00 00 04 00 90 00 14 05 1A 00 ................

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 80 03 00 00 00 00 .5......



Parsing SCR Register

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5

おきぱのF7向けFatFs動作サンプルには今回得られた成果を収録して更新しました。
ねむいさんからのくりぷれです！

STM32も進化を重ねF7になった今でもやってることは相変わらず、SDカードから
読み出した画像データや動画を表示せしめることしかできませんがねむいさんは
F10とかになってもきっと同じことしてるでしょう。いいか我々にはこれしか道はない！
~~私はロリ↓コン↑ではない！~~
↑ねむいさんの好きなゼEROのキャラはカーネルやジェネラルのレプリフォース勢

ついでに初期F4シリーズ向け、LPC1788そしてLPC4088のFatFsサンプルも
SDカードの内部レジスタを正しく表示/パースできるよう更新しました。
そいえば今回の改修の際に気付いたのですがSTM32F4向けのCubeF4以前の
SPLがなんと今年秋にアップデートしていました･･･しかもDSI使える最新の
STM32F469/479にも対応してます。こちらももちろん反映してあります！

さらにGitHUBにあるSTM32Primer2 GPSTr@ckerもプログラム中では直接使用
してはいませんが別のプロジェクトに流用した時すぐ使えるようにSDIO
ドライバを更新してます。
じわじわと外人さんからの需要が出てきているようでうれしい限りです★

CIDレジスタのパース機能を付けたおかげもあって他のSDカードだとどうなって
いるのかも興味が出てきましたのでいろいろ読み出して試してみようと思います。

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ライブラリに修正を加えておきましたｸｿｧ！

OpenOCD小ネタ19 -Nuvotonドライバの統合-

今をさかのぼること2年前、いろんな行き違いによって同じNuvotonのCortex-M0
向けフラッシュ書き込みドライバが同時にマージされる事態になってしまいました。

その間もいろいろあってなかなか更新できなかったのですが今秋に両者を統合
するドライバがマージされたのでようやく報告できた次第です。

さて、この統合されnumicroと名前を変えたこのフラッシュ書き込みドライバは
少しトリッキーな動きをします。それを少し解説します。

●Undocumented Registerの存在
NuvotonのARMマイコンのフラッシュ領域はユーザプログラム用のAPROMとブート
ローダ専用のLDROMの二つがあり、書き換えをするためにはそれぞれ別のフラッシュ
ブートモードから再起動する必要があります。つまりAPROMを書き換えたい場合は
LDROMのブートモードに切り替えコアリセットを掛けるという手間がかかります。
これが公式のマニュアルに記載されている手順です。

しかし！このような煩雑な手順を踏まなくてもどのモードでもAPROM,LDROM,
CONFIGの書き換えそしてチップ全消去コマンドが実行できる方法が解析により
見つかっています。
マニュアルに記載されていないレジスタ0x5000C01Cに1を書き込むとフラッシュ
に対する全てのアクションが出来てしまうようです。Nu-Linkのツールではこれを
自動で行っていることから気づき解析されたみたいですね。

そして上記の成果はOpenOCDに反映されましたがこのときはまだmini51シリーズのみ
だったため、私の手持ちの他のシリーズ(NUC120,NUC220,M051,NANOシリーズ等)で
この技が効くかどうか確認し、OpenOCDの更新が落ち着いたタイミングを見計らって
今回の統合をおこない、無事マージされました。長かった…!

上記の修正を掛けたドライバでNANO130に書いた時のログはこんな感じです。

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

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

Open On-Chip Debugger 0.10.0-dev-00036-g48787e1-dirty (2015-10-02-09:14)

Licensed under GNU GPL v2

For bug reports, read

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

Info : VSLLink SWD mode enabled

swd

adapter speed: 1000 kHz

none separate

cortex_m reset_config sysresetreq

Info : Versaloon(0x15)by Simon(compiled on Sep 16 2014)

Info : USB_TO_XXX abilities: 0x0000176E:0x010001EF:0xC0000007

Info : clock speed 1000 kHz

Info : SWD IDCODE 0x0bb11477

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

target state: halted

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

xPSR: 0x21000000 pc: 0x000002d6 msp: 0x20003ff0

auto erase enabled

Info : Device ID: 0x00113034

Info : Device Name: NANO130SE3BN

Info : bank base = 0x00000000, size = 0x0001ec00

Info : Nuvoton NuMicro: Sector Erase ... (0 to 40)

Info : Nuvoton NuMicro: Flash Write ...

wrote 20992 bytes from file main.elf in 4.078360s (5.027 KiB/s)

verified 20800 bytes in 0.281266s (72.218 KiB/s)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:05

一応デバッグもできますが今回の統合に至るまでにnuvotonのドライバの他にadi_v5や
cortex-mのコードにかなりの修正が掛かっており、リセット直後の状態が特殊な
nuvoton系のARMマイコンでは正攻法が通じなくなっていました。
そこで上手くデバッグできるようにcfg側も仕込んでトリッキーなことをしています。
gdbが接続した瞬間にresetとhaltを連続してかけ("reset halt"だと駄目)、さらに
プログラムカウンタを強制的に0にしておきます。

当然割り込みベクタの一番頭で停止しますがここでcontinueすると･･･

無事main関数の頭でブレークしました★
ちなみにOpenOCD側だけでは不完全でプロジェクト側も多少の修正は必要でした。
おきぱのNUC120,M0516のプロジェクトはすでに新しいOpenOCDに対応しています。

念のため他の品種も洗ってみたのですがnuvotonドライバだけではなくLPC4300系の
SPIFIの書き込みもおもいくそ影響を受けていて書き込みできてませんでしたorz

↑最後のほうでエラー出てますがコアリセットをソフト的に強制的に掛けてるので
　こうなります。動作としては問題ないです。
こちらも現行のOpenOCDで正しく動作するようにcfgファイルに修正をかけておきました
ので皆さん安心して使い倒すことができると思います。

根幹に近い文字通りコアな部分をひっそり変えられると思わぬところで上手く動か
なくなるのはよくある事なので私の目の黒いうちはしっかり注視していこうと思います。

STM32F4シリーズを使ってみる14 - FatFsとSDカード再考その3(SDIOでDMAした時の不具合対策編) -

サブタイトルがどんどん長くなる･･･それはおいといて
前回の解説でまぐろ様と言う方より最初に4Byteの倍数以外の数のデータを
書き込んだ際に書いたデータがずれると言う不具合報告をいただきました。
結局原因はDMAする際にメモリアドレスがWORD(4バイト)のアライメントの境界に
そろっておらずずれた状態でDMAしていたことだったのですが、私自身も勘違い
したまま使っていたのでこの場で情報を整理して根本的にどう対処すれば
よいのかを記しておきます。
その前にどうでもいいですが"Alignment"はアラインメントでもアライメント
でも発音は正しいそうですが以後はアライメントで統一します。

●ズレる
たとえばファイル"mankoi.txt"を書き込みモードで開き、ヘッダとデータの塊を
f_sync()を挟んで書き込むコードを実行するとします。ここで"sakisan","gff"は
共に書き込む予定のバイト数を満たす十分な大きさをもち4バイトの境界に揃った
const charの配列のポインタとします。
またf_系の返り値のチェックは下では解説のために省略していますが
実コードでは付与しております。

f_open(&File[0], "mankoi.txt", FA_OPEN_ALWAYS | FA_WRITE);

f_write(&File[0], sakisan, 37, &s2);	/* 4の倍数でないバイト数 */

f_sync(&File[0]);

f_write(&File[0], gff, 4096, &s2);		/* マルチブロックで一気に書き込む予定 */

f_sync(&File[0]);

f_close(&File[0]);

期待される動作はsakisanで示された37バイトのデータを書き込んだ後gffで
示された4096バイトデータを書き込みファイルをクローズして無事終了
…のはずです。

SDIOでDMAを使用しないFIFOポーリングによる書き込みではちゃんと期待
される動作となります。しかしDMAを使用した場合最初のブロック(=512バイト)を
書き込んだ次のブロックの最初の書き込もうとするデータが1～3バイトずれて
しまいます。
このずれ方は転送予定だった最初のバイト数を4で割った余りと等しくなります。

STM32F4のマニュアルではDMAをする際のメモリアドレスの境界はFIFOバースト
長さ/INC値に合わせよと明記があります。STのサンプルでは送り元メモリ及び
送り先ペリフェラルはそれぞれ4バイトとしていたのでそれに倣って4バイトの
境界にメモリアドレスを合わせる必要があります(私のサンプルのSPI版の
場合はDMAの転送サイズはByteのため今回の影響はありません)。
ねむいさんはてっきりFatFsのデータのやり取りに使用する為に静的に確保した
バッファの配列を4バイトアライメントにしておけばそれで問題なかろう･･･
という致命的な勘違いをしておりました。

上記f_writeからはSDIOドライバと結合したdisk_writeが呼ばれますがこのとき
渡される内部バッファのポインタアドレスが4バイトの境界にそろっているとは
限りません。しかしながらdisk_write内のSD_WriteBlock及びSD_WriteMultiBlock
はDMAで転送する際は送付元メモリアドレスが4バイト境界(4で割り切れる数)に
なっている必要があります。ズレる状況で実際にどういうことが起こっているか
デバッガで追いかけてみましょう。

最初にシングルブロック転送で37バイト分書き込む時です。最初なので
当然メモリのアドレスも4バイトの境界にいます。

f_sync()の処理を終えてから次の4096バイト(実際は最初の512-37バイトを
引かれた値)をマルチブロック転送で書き込んだ時です。ご覧のように渡された
ポインタbuffのアドレス値が4で割り切れない数になってます。

当然のことながらmankoi.txtに書き込まれた文字列はズレます。

●対策
前回も述べましたがSTM32F2/F4は対策はとても容易でDMAの設定でメモリ側の
データサイズを1バイトの"Byte",FIFOバッファのメモリ側バースト長をSingleにすれば
1バイトごとの転送となり効率は落ちますがアライメントは関係なくなり問題は
解決します。

しかしSTM32F1系はSDIOはF2/F4系と違いAHBバスにぶら下がっていてなおかつ
AHBバスに直接ぶら下がったペリフェラルへのDMA転送は常にWORD(4Byte)単位
でなければならないという制約があり、F2/F4みたいな技が不可能です。
したがって下記に示す根本的な対策を行う必要性があります。

/* If unligned memory address situation,copy dmabuf to aligned by 4-Byte. */

/* SECTOR_SIZE = 512 (Byte) */

uint8_t dmabuf[SECTOR_SIZE] __attribute__ ((aligned (4)));

if((uint32_t)buff & 3)	/* Check 4-Byte Alignment */

{	/* Unaligned Buffer Address Case (Slower) */

	for (unsigned int secNum = 0; secNum < count && Status == SD_OK; secNum++){

		/* Use optimized memcpy for ARMv7-M, std memcpy was override by optimized one. */

		memcpy(dmabuf, buff+SECTOR_SIZE*secNum, SECTOR_SIZE);

		Status = SD_WriteBlock(dmabuf,

					  (uint64_t)(sector+secNum)*SECTOR_SIZE, 

					  (uint8_t)SECTOR_SIZE);

	}

} else {

	/* Aligned Buffer Address Case (Faster) */

	if(count==1){

		Status = SD_WriteBlock((uint8_t*)(buff), 

							  ((uint64_t)(sector)*SECTOR_SIZE),

							  SECTOR_SIZE);

	}

	else{

		Status = SD_WriteMultiBlocks((uint8_t*)(buff), 

									((uint64_t)(sector)*SECTOR_SIZE),

									SECTOR_SIZE

									,count);

	}

}

f_writeから渡されるbuffのアドレスの下位2ビットを比較して4Byteの境界に
ない物は整列された配列にコピーし直しシングルブロック転送を行うものです。
このアライメント補正したシングルブロック転送を行っていくとブロックサイズ
の境界(512Byte=128*4Byte)に揃い改めて高速なマルチブロック転送が可能と
なるので効率をなるべく落とさないような仕組みにしてあります。
勿論Readの際もﾁﾏﾁﾏ読み込みの際は同じような対策でズレを防止できます。

これの対策の元ネタはSTマイクロのフォーラムにあったやり取りです。
かれこれ3年以上経ってましたがねむいさんずっと勘違いしてたせいでこの
対策の意味が今更分かったorzそれにしてもClive1...貴方は何者なんだ…！

そしてChaNさんのページでもズレるから各自対策してね★ってしっかりと
注意書きがしてありました…orz見落としてただけジャン私orz

で、でも現行のSTM32F4Cubeとかのサンプルって1.4.0になってもアライメントの事ガン無視
ですし、ま、まぁこれに気づく人のほうがたぶんす、少ないですってﾊﾊ♥

･･･と言うわけでおきぱにあるSTM32F2/F4のサンプルは上記の根本対策を
講じております。好みに合わせてDMAの設定だけで逃げるお手軽対策も
できるようにしてあります。

またF1系,LPC1788/LPC4088のFatFsでも根本対策を施していますので
ご利用ください。ちなみにLPC2388に関してはChaNさん謹製のMCIドライバを
使用していますがちゃんとアラインド/アンアラインド化をしているため
もともと大丈夫です。

●そういえばFatFsの設定で･･･
FatFsの設定のためのffconf.hには_WORD_ACCESSなる定義があり、1にすると
ポインタの参照が32bit単位になり高速化ができる･･･はずですが32bitマイコンの
場合はCPUコアのアライメントの制約で1にすると上で述べたDMAみたく
CPU例外が起こってしまいます。
しかしながらCortex-M3/M4ではアンアラインドなアクセスが一部の命令で可能なため
1にする事ができます。"一部"なのでChaNさんは0を推奨しています。

ねむいさんが試したところではff.cではまだDWORD(8Byte)やそれ以上の
マルチバイトにアクセスする状況が発生していないのでアンアラインド転送の
制約に引っかかるSTRD,STM,LDRD,LDMの命令は現状のコンパイラではff.c内
では一切使用されず例外も発生しないので1で問題はないと言い切れます！
もちろんアンアラインドなアクセスではペナルティが発生してその時の速度は
低下しますがそれでも全体的にはバイトアクセスの時より速度もコードサイズ
でも優れているので積極的に１にしていきましょう！
さらにGCCのコンパイラ・オプションで”-munaligned-access"を有効にすると
アンアラインドアクセスを承知でコードの効率化が図れます。

20160620追：
FatFs0.12ではこのオプションは廃止されました。
コンパイル時に必ずアラインド状態のアクセスになるようコードが変わっています。
20160620追：

ちなみにアンアラインドなアクセスが起こった事を知るための機能もあります。

SCB->CCR |= SCB_CCR_UNALIGN_TRP_Msk;

SCBのCCRレジスタにはアンアラインドなアクセスの発生をトラップするビットが
あります。これを立てるとアンアラインド転送が起こった時にHardFaultに
させることができます。

一方Cortex-M0,M0+ではコアのアーキテクチャが違うのでアンアラインドな
データアクセスは許されず、問答無用でHardFaultになりますので常にバイト
アクセスかもしくはアライメントがそろった転送をしましょう。

そういうわけで不具合もしっかりと修正されたので今度こそ実際に
パフォーマンス比較をやっていきたいと思います！

OpenOCD小ネタ7 -JTAGKey2でSWDできるじゃない！-

20140708追：
ついにSWDに正式対応しました！
20140708追：

ここ数日OpenOCDのgerritにVersaloonのSWDサポートの修正が盛んに
あげられていて、私もいろいろﾖｲｼｮしております。同時に汎用のSWDドライバも
見直されどんどん変化しております。
その矢先になんかすごいの来てました。FTDIデバイスのSWD対応です！
しかも結線がめっちゃ簡単でJTAGKey2(Compatible)系のバッファがついたもの
でも極めて簡単な回路の追加でSWDれます♥

本来FTDIデバイスのSWD対応については約一年前、libswdというのがコミットに
当たりかけていたのですが実装に関する思想をめぐりくだらない激論となり
スクラップ状態で放り投げられていました。今回の奴はそれとは別のアプローチ
で実装された物のようです。末端ユーザーの私たちとしましてはちゃんと
動作して恩恵が受けられるのかが大事です。

そんな訳で早速試してみました！コードレビューにはJTAGで言うTDIとTDOの
間にトライステートバッファをおいてnTRSTでOEを制御してターゲットの
SWDIOと接続すべしと書かれております。SWCLKに関してはそのまんまTCKに
つなげばOKです。さらに"トライステートバッファ噛ますのめどいんなら
220~470ohmくらいの抵抗でワイヤードORでもいけるかもね"とさえ書かれて
いました。

もちろん私はお気楽に510ohmのカーボン抵抗でワイヤードOR作戦です。
当たり前ですがTDIが直接ターゲットのSWDIOに来てショートしないように
抵抗を配置してください。
(私のJTAGKey2Compatibleの回路はそれでも素子の即死はしないように配慮してます)

今回の実験対象はSWDのみ接続可能なNuvotonのCortex-M0コアの
Nano130SE3です。このマイコンも以前からちらっとお見せしていますが
NuvotonネタはFM3の修正がコミットされたら一気に攻めるので今は
まだ脇役なのです。もう少しお待ちください。
JTAGkey2はVref必須故にVersaloonの+3.3Vを拝借してターゲットに
供給しております。使用するOpenOCDは現在の最新のコミットベースの
Versaloon-SWD対応版と、同じく最新のコミットベースで
上記のコードレビューからCheckoutしてきたFTDI-SWD対応版＋αの
OpenOCDバイナリをそれぞれビルドし、VersaloonとJTAGKey2で
同一のelfファイルの書き込みとベリファイ速度を比較します。

↓んでこんなん出ました。
*JTAGKey2-SWD



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

openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -c "transport select swd" -f target/nano130se_swd_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.8.0-dev-00358-g5b3885f-dirty (2014-02-19-17:22)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : Init SWD

swd

none separate

Info : add flash_bank nuc1x nano130se3.flash

adapter speed: 1000 kHz

cortex_m reset_config sysresetreq

Info : JTAG->SWD

Info : clock speed 1000 kHz

Info : SWD IDCODE 0x0bb11477

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

target state: halted

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

xPSR: 0xc1000000 pc: 0x000006ec msp: 0x20004000

auto erase enabled

Info : DeviceID : 0x00113034

Info : Detect NANO130SE3AN!

Info : Nuvoton NUC: Sector Erase ... (0 to 39)

Info : Nuvoton NUC: FLASH Write ...

wrote 20480 bytes from file main.elf in 2.452780s (8.154 KiB/s)

verified 20240 bytes in 0.203096s (97.322 KiB/s)

target state: halted

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

xPSR: 0xc1000000 pc: 0x000006ec msp: 0x20004000

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:04

*Versaloon-SWD



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

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

Open On-Chip Debugger 0.8.0-dev-00350-g6c74255-dirty (2014-02-19-11:18)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : OpenOCD runs in SWD mode

none separate

Info : add flash_bank nuc1x nano130se3.flash

adapter speed: 1000 kHz

cortex_m reset_config sysresetreq

Info : Versaloon(0x15)by Simon(compiled on Sep  5 2013)

Info : USB_TO_XXX abilities: 0x0000176E:0x010001EF:0xC0000007

Info : clock speed 1000 kHz

Info : SW-DP IDCODE: 0x0bb11477

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

target state: halted

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

xPSR: 0xc1000000 pc: 0x000006ec msp: 0x20004000

auto erase enabled

Info : DeviceID : 0x00113034

Info : Detect NANO130SE3AN!

Info : Nuvoton NUC: Sector Erase ... (0 to 39)

Info : Nuvoton NUC: FLASH Write ...

wrote 20480 bytes from file main.elf in 1.905981s (10.493 KiB/s)

verified 20240 bytes in 0.203097s (97.321 KiB/s)

target state: halted

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

xPSR: 0xc1000000 pc: 0x000006ec msp: 0x20004000

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:02

ログも微妙に違いますが書き込みベリファイの速度に注目すると…
JTAGKey2-SWDが
wrote 20480 bytes from file main.elf in 2.452780s (8.154 KiB/s)
verified 20240 bytes in 0.203096s (97.322 KiB/s)
Versaloon-SWDは
wrote 20480 bytes from file main.elf in 1.905981s (10.493 KiB/s)
verified 20240 bytes in 0.203097s (97.321 KiB/s)
となり、JTAGKey2-SWDの方は書き込みでは2割ほどパフォーマンスが
落ちますがまだコードが練られてない段階ながらも十分実用レベルで
使用可能なことが分かりました♥
ついでにトライステートバッファによる制御がなくても抵抗一本でお手軽に
既存のFT2232系のJTAGデバッガがSWDにも対応できるのでなんというか
CMSIS-DAPとは一体何だったのか感すらあります。

というわけでまだまだコードの手直しが必要な段階ですがFTDIデバイスの
SWD対応はシンプルかつ強力なポテンシャルを秘めていると言えるでしょう！

OpenOCD小ネタ6 -kinetisドライバの修正その他-

世間様ではトラ技ライタの話でもちきりですが私は毎年恒例の2/9のいないさんの
聖誕生日に向けたブツをずっとこもりっきりで作っていたのでOpenOCDの
ネタが溜りまくっております。
周りに流されず粛々と消化していきますよぅ～

●エンバグようやく直る(誰も気づかんかったんかい！)
少し前の話ですがkinetisドライバに作りこまれてしまったバグの修正をgerritに投げ、
マージされております。私もgerritにだいぶ慣れてきました♥

Kinetis-Kシリーズは同じ号数(たとえばK20、K60等)でも動作周波数の
上限の違いでフラッシュのセクタ構成が大幅に違いますのでソフトに落とす
際は厳重な注意が必要ですね。私もユーザーマニュアルを首っ引きで現時点で
分かりうる範囲で全てのセクタ構成のパタンを書き倒してやりましたよ！

尤も私が去年Lシリーズへの対応を試みた時は元のコードはもう少しスマートに
セクタ構成を判別する仕組みをとっていました。"guranuarity"と呼ばれる
その値は上で述べたセクタ構成を示し、RDIDレジスタの特定のビットに反映されて
おりました。しかし、その明確な定義についてマニュアルには一切書かれて
おらず、いわゆる裏ワザ的コーディング扱いされていました。
そういうわけでマニュアルを斜め読みした別の人にこういうのよくないよー
(地獄のミサワみたいな顔で)と言わんばかりに中途半端にハードコードされた値が
いいかげんに設定されてしまいエンバグになってしまったわけです。

私もkinetisから離れて居たので気づかず別の外人さんの"K20で
書き込めない!1!1!!!"という質問メールで漸くエンバグされたのに
気づいて冒頭のとおりぱっちをgerritにブン投げたわけですよF**K!
私は悪くねぇ！
なお、上記問題はKL25等のKinetis-Lシリーズには全く影響がなかった
のでご安心を。
あなたがKL25Zに急に書き込め無くなったのは100%これが原因です。

これから先は従来のFMCとはコマンド体系がガラッと変わったKinetis-Eシリーズ
等も控えていますのでさらに複雑化と混乱が予想されます…。それに入手が
容易で人気があるマイコンは修正が他の人とバッティングする状況が
よくありますので他のコントリビューターの人とも綿密に意思疎通を
行うことも非常に重要です。
疎通ができなかった場合nuvotonドライバが2つ出来てしまうことになりますorz
(↑nuvotonの件に関しては次回にでも詳しく…)

●libusbxがlibusb-1.0に
私はlibusb-1.0準拠のlibusbxを従来から使用しておりました。libusb-1.0の
オリジナルにはない機能や修正がたくさんあたっております。
ところが1月下旬にlibusbxが1.0.18でファイナルリリースになり、以後は
libusb-1.0の本流として修正が続けられることになりました。

そうなったいざこざがここにありました。もめごとの陰にはあの男ありです。
私も変な突っ込み喰らわないようにOpenOCDのパッチを投げる際は
細心の注意を払っています。

それはさておき現在私がぶろぐ上で配布しているlibusb-1.0を使用するバイナリ
は全てlibusbxから"x"が取れたlibusb-1.0.18の自前ビルドしたdllをバインド
しております。
もちろんAsmediaのxHCI対策のパッチも適用済ですのでUSB3.0でも問題なしです♥

●libftdiも1.1に
libftdiの1.x系もバージョンアップし、めでたくlibftdi1.1になりました。
こちらに関しては特に記すべきことはないのですが無理やり話題を作りますと…
libftdiは1.0に上がったころから(0系のファイナルは0.20)ライブラリや
プログラムのビルドにCMAKEとかいうのの使用を強制するようになっています。
従来のconfigure->makeのお手軽コンボとは全く違う概念だったのでブツを
作り出せるようになるまで苦労しました。

しかも1.0に切り替わった直後はMSYS向けにはコンフィグがまともに整備
されていなくてあーでもないこーでもないを繰り返してやっとlibftdi1.dllを
ビルドできた涙ぐましい記憶があります…(しみじみ。
現在ではMsys/MinGWのコンフィグ周りも見直されて手直し無しに一発ビルドアウト
出来るようになっております♥もちろんこちらもバインド済です♥

●OpenOCDにバインドされているDLLのまとめ
現在私が配布しているOpenOCDのバイナリは上記を含めた各種dllを
バインドしております。
どれ一つ欠けてもOpenOCDが起動しませんのでご注意ください。また、他の方が
ビルドしたOpenOCDバイナリに差し替えてもそのまま動かすことができますが、
一方でその逆の行為はおそらく一切できませんので理解したうえでご使用
願います！！

libusb0.dll
->libusb-win32-bin-1.2.6.0から抽出
libusb-1.0.dll
->libusb1.0.xxを自前ビルド(+AsmediaのUSB3.0(xHCI)対策済)
libftdi1.dll
->libftdi1.xを自前ビルド
(以前はlibftdi1.dllをlibftdi.dllにリネームしていました)
libhidapi-0.dll
->hidapiを自前ビルド

各ライブラリのライセンスもOpenOCDの"licenses"にありますのでご参考に。

libusb-1.0.dllはAsmedia対策をしてるのでOpenOCDと全く関係ない方からも
需要があるようです。おそらくUSB3.0ホストの問題、この先もわらわら出て
きそうです…

●罪なき人の平和な日曜日を破壊するねむいさん
ごめんなさいごめんなさい！！！…まさか使ってくれてる人がいたとは…
20140210現在はちゃんと内部RCから144MHzに上げるようにスクリプト変えてます
のでご安心を…あと128kByte以下のフラッシュ容量のFM3マイコンではクロックを
叩き上げるのはあんましうま味が無く逆にデメリットしかないので無理に
クロックは上げないでノーマルで書き込んだ方が効率がいいです。

●ついに日本人で私以外の犠牲者が…
oh...my...
これの問題ですが、MSC経由でKL25Zとかに書き込むときにsrecじゃなくてelfを
D&Dで放り込んじゃうとどうやらelfファイルをパースせずにそのままbinファイル扱い
で書き込みやがるからみたいですね…#
まさにクラウドの落とし穴です！

これelfファイルのFSEC番地が0xFFならまだ救済措置はありますが0xEFなら
完全終了
ですね…私からのアドバイスですがKL25Zをmbed版CMSIS-DAPにしてOpenOCDから
MDM-APのmass-eraseをやってみてください。
もしかしてまだ回復できる可能性があります。また、SRSTの操作がmass-eraseに
必須なので必ず繋げてくださいね(Kinetisのハード的な仕様です)。

東海自然歩道を徃く22(草薙-興津/興津-富士川)

今年の夏は暑かったですねマジで･･･屈強な高校球児すら熱中症で痙攣するレベルの
猛暑でしたが、やきう場より過酷な場所に果敢に挑んでいきました。

●2013.07.13 草薙->興津

この山行(というか今回は海行)に挑む少し前に富士山が世界文化遺産に登録されました。
同時に今回通過する予定の三保の松原も登録されたようですがはてさて･･･

今回のルートは正規ルートは三保の真崎灯台の手前で終了ですが私はそのまま
次なる戦場となる興津へ向かいます。灼熱の太陽が照りつける海岸線のルートが
勝負の鍵となるでしょう･･･いざ出発！(右端の変な仏像から目線をそらしながら)

南幹線を通過し住宅街をかいくぐると草薙神社に着きます。

こんなところにも龍勢のステマがー！？
立派なトイレがあったのでここで体制を建て直し新たに出発！

静岡バイパスコースは比較的難易度低いですね～舗装路ばっかで楽チン
･･といいたいところですが夏場は地獄です･･･

虹裏メイドなのに第二のふたばがあるなんて知らなかったそんなの･･･

さて、ぐんぐん舗装路の坂道を越えるといったん下りの道に転じて
日本平への車道とクロスします。ここから山道がはぢまります！

し　ゅ　ん　た

これはいい感じのトレイルですね～♥

とおもいきやあっという間にそれは終わる。
ここを少しあがると再び舗装路に･･･

日本平ホテルです。

蝉兄貴も夏を満喫していますね…

日本平山頂公園に到着です。ここで水分補給をかねた小休止です♥

(XX高原ミルクってありがちやな･･･)

でもまんまと買ってしまう私･･･

この日は7月上旬にもかかわらずぎらぎらの猛暑でしたがツーリングの人たちも
沢山こられていました。11年前は私もよくドライブにつれてってもらｔｔ
ぶ　わ　っ　


ずびっ･･･失礼しました･･･静岡の海岸線ルートはどうも私の青春時代を刺激
してしまって･･･ぇーっと日本平の山頂です。ここから久能山東照宮に降ります。

日本平山頂から久能山東照宮は山道は一切なく、ロープウェイで移動せざるを
得ません。しかし立派なこれも正規ルートなのでまぁ良いでしょう。

で、ロープウェイ待ちでベンチに座ってると猫ちゃんが2匹ねむいさんの元に･･･
日向をさけで私の足の下に来ましたが･･･

何故かその子の内の一匹が急にベンチを離れ、割れたコンクリの隙間に
頭を突っ込みお尻がはみ出た姿勢で固まっていました･･･そしてそれを
醒めた目でベンチ下から見つめる相方の猫･･･どうやら暑さで頭が･･･

そうこうしてる内にロープウェイがやってきました。
静岡なのでいたるところに世界遺産アピールがありますね！

ロープウェイの到着点は久能山東照宮の入り口になっています。
でも鳳来山のときと違ってお金結構掛かるのでスルー
(私の親父用にお守りだけ買ってきました)

ここからは海岸線に向けてひたすら階段を下ります。
11年前と同じ景色が眼下に広がる･･･(じわわ

上りはかなり辛そうですね～

ぬふぅ！

ｹﾞﾌﾝ失礼、ここから先は久能街道こと国道150号線(の端っこ)を爆走します。
山道とは違った平坦な道ですが今は灼熱の太陽が容赦なく照りつける極めて
過酷なロードとなります！いざ勝負！

久能海岸は外海なので凪いでるときでも非常に荒々しいです。
JDの頃は良くここにもドライ(ry
眼から鼻水出てきました･･･ずびびびびびび


♪日射しの熱さに思わず目を閉じた　蜃気楼と過ぎてゆく夏の匂いあの日


♪荷物の重さで膝付き傾く背中にそっと触れたから　動きだした



150号線と離れ三保の松原をさらに目指します。ねむいさん作のスペシャル
ドリンクのおかげでこの過酷な天候下でも足の調子は抜群です！

実はこのルートは太平洋自転車道と道を同じくしています。
ここはホントは道に沿って左折せざるを得ないのですが、ぢつは矢印の方向に秘密の
近道があります♥なんで京都の人間が静岡の地元の人間レベルのこと知ってる
のかですって？うふふ


さて、近道の松林を抜けるともうそこは三保の松原"羽衣の松"です。
世界遺産効果か観光客もめちゃくちゃいます。私はここでも
11年前に立ち寄った茶屋で休憩を取りました･･･注文するのは
もちろんいちごみるくちゃん♥♥♥♥♥

やべ･･･一気食いしすぎて頭痛くなってきました･･･
しばしの間羽衣の松とかを見物しました･･･しかし、前日の7/12に先代の
羽衣の松が老朽化により切り倒されてしまい無残な姿に･･･
11年前は(ryこれ松の前で一緒に写した写真もまだのこしてｔぶわっつ


すみません取り乱しました･･･ちょっと眼から鼻水がまた出てきちゃったもんで･･
さて、松の先には三保の荒々しい外海が広がります！松側を振り向くと石でメッセー
ジが砂浜に刻まれてるのに気づきました。消えかかってましたがまだ･･･
オメデトウ2013世界いさん(下に富士山の絵)

メインの先代羽衣の松が切り倒されてしまいだんだん曇ってきたおかげで富士山も
見えませんorzせっかく世界遺産になったのにちょっとしょぼいです。
説明員の人がやってきた観光客相手に孤軍奮闘で解説の大立ち回りをされていました。

さて、たっぷり水分と休憩も摂ったので再出発です。
海岸線を縫うようにひた走ります。

三保灯台です。

こちらは三保飛行場です。

猫ちゃんも夏バテです。死んでるかとおもったら生きてましたよ。
自転車に轢かれないように安全な日影の場所に移して上げました。

三保海水浴場です。たしか11年前はここにシュモクザメ沸いてて遊泳禁止になってたはず･･･
でしたが･･･時代は変わった


真崎灯台です。東海自然歩道はここでいったん終了ですが私はこのまま先に進みます。
ここから先のルートは私の記憶が興津まで再び誘導してくれます(眼から鼻(ry

a>
三保の内海側です。静大ヨット部は健在ですね～

海岸線を抜けると後は興津までひたすら車道を走り続けます。
この道も何もかも(ry

三保車庫です。ここから先はゴールの興津までひたすら車道！

さっきの三保車庫からJR清水駅はかつて国鉄三保線が走っていたそうです。
現在は自転車道になっているこのルートですが私も折戸駅跡からここに合流しました。

結構長くてきつい･･･湿度も100%あるんじゃないかという気候です。
曇ってこなかったら干上がって死んでたかも･･･
画像は清水といえば鈴与

oh...途中で国鉄三保線が私有地に吸収されてました･･
仕方ないので車道に戻ります･･･

静鉄清水駅周辺です。エスパルスドリームプラザが見えますね･･･。
右端に見てはいけない物体が･･･

杉山君総受け本
ねむいさんはさくらももこより岡田あーみんが好きでしたよぅ！！

というくだらない主張はおいといてJR清水駅に到着です。
旧三保線はこの場所で終了ですが太平洋自転車道はまだまだ続きます。

国道一号線とくっついたり離れたり。
11年前はここもねむいさんドライブで(ry

道はやがて旧東海道と再び合流します。

ここはすでに宿場町興津です。
それっぽい道標や案内板も目立ってきます。

うぉぉもうすこし！！！

ようやくJR興津駅に到着です。
久能海岸以後の舗装路延々走りはかなり効きました･･･三保の松原以降は曇ってきて
日射もかなり低減されたので超糞熱くて汗もダラダラでしたが精神的にだいぶ楽でした。
でも清水駅以降でふくらはぎがまたつりかけたのは反省ポインツです。
この程度で躓いてたら次回の過酷なルートは越えられません！

ねむいさんは次なる戦いに向け新たな決意を元に新幹線の中で爆睡するのでした･･･！

●2013.08.24 興津->富士川
今回は真夏の真っただ中に40km超の過酷なコースを巡ることになります。
ゆえに超激戦が予想されたので7月末くらいから特訓をしておりました。

仕事が終わったら西院から出発して東海自然歩道のルートでもある嵯峨の
六丁峠まで行って帰ってくる走り込みをほぼ毎日行い、特に六丁峠の登坂は
ダッシュで駆け上がり駆け下りてくるといったトレーニングでスタミナと
脚力を強化して挑みました！

出発地点のJR興津駅です。

旧東海道を少しの間手繰ります。
この興津郵便局の手前の交差点は身延道の出発点でもあります。

興津川を越えて薩た峠への旧道へと向かいます。

薩た峠への道標はいたるところにあって安心です。

そこまでやらんでええちゅうに！

この激坂を超えると休憩所とお墓がありその中をさらに通過します。

薩た峠です。
私はこの下を通る国道とかはよく来てたのですがこの峠自身を通過したのは
初めてでした。11(ry

目下には駿河湾の荒々しい海が今日もうねりを上げていました。
それにしても暑い…汗がﾎﾞﾀﾎﾞﾀたれまくってます…。雲は多少ありますが
その隙間から太陽さんはギンギラギンに直射日光を提供してくれます…
写真がちょっと暗いですが露光のせいでこんな風になってます。

薩た峠第二ビューポイントに来ました。
ここは有名な場所ですね～。しかし肝心の富士山は雲と熱気による霞で
さえぎられてほとんど見えずorz
…おや…国道の立体交差の真ん中にあるあの建物は…？

あのうどん屋まだあった！
11年前ドライブで伊豆に連れてってもら(ry
猛烈な熱気のせいか目から大粒の汗が出てきました…貴重な水分が…

それはともかく灼熱のアスファルト道を超えて浜石岳の登山口にたどり着きました。
この日の静岡の最高気温は34.4度、持参したスペシャルドリンクとSAVASピットイン
リキッドで本日の最難関に挑みます！

浜石岳の山道は蜘蛛の巣だらけの上道が藪の上痩せてて非常に
危険です…ていうか蜘蛛の巣やめて！！１１！

ようやく走れるトレイルにでられた～

と思ったらすぐに蜘蛛の巣ゾーン！！

藪藪藪藪藪藪
ちょっとでも止まると藪蚊が襲ってくる藪ゾーン

但沼分岐までようやくやってきました…持参した水分もあと500mlと少し…
しかし汗は滝のように出てズボンも発汗でおもらししたようになってます////

最後の急登…ここを登れば終わりだっ…！

予定時間より10分ほど遅れてようやく浜石岳頂上に到着です…
頂上に付いたころには雲が空を覆っていましたがそれを貫く勢いで
お日様光線が…とりあえずちょっと休憩…ぇどっこいしょ
…
……

…
…？
はぅあ！！
私としたことがベンチの上で仰向けで5分ほど意識失ってたようです…

このまま眼覚めなかったら熱中症でまぢで死んでたところですよぅ
長居は無用なので頂上を後にしました。

浜石岳を下りるとその先から静清庵自然歩道と何度も道を同じくします。
東海自然歩道のルートがわかりづらい箇所もありますのでご注意を
東海自然歩道は山道ではなく林道を下ります。

林道をひたすらくだってくだってくだってくだってくだって･･･
やっと民家がちらほら見えてきましたがやばいっす･･･水が切れてきました･･･

浜石岳がもうあんなに遠く･･･ボーっとしつつ間違えて入った道に
なんと共同墓地と水道水とトイレがー！ﾋﾔｯﾊｰみずだ！！１
ｺﾞｸｺﾞｸｺﾞｸｺﾞｸ･･･生き返った･･･

特訓の成果がああってか夏場で猛烈な下りの連続でも全く足が攣ってません。
ぐんぐん下ります！

銚子口の滝にも立ち寄りました。
もちろんここも蜘蛛の巣だらけ！ぬぎゃー


ようやく開けた場所まで降りてきました･･･はぁはぁ･･･。今度は県道76号線にそって
北上しますが、途中に商店と自販機があったので改めて水分を取りなおし
SAVASピットインリキッドも流し込んで２機目のエンジンをかける準備をして
再出発です。

このあたりは水が非常に綺麗で天然のわさびも道路の脇の小川にふつーに自生してます
でも私有地にあるので採っちゃ駄目ですよ！

"かぎあな"で県道とはなれ見晴観音へと向かいます。
勾配のきつい登坂でしたがようやく第２エンジンがかかったのでぐんぐん上ります！

道はやがて山道になります。しかし天候も完全に曇りになって気温も下がり始め
道も比較的歩きやすい山道なので浜石岳よりもさくさく進めます♥

見晴観音とやらにつきましたが･･･？？？観音さまは？
しかも木が邪魔で視界ゼロだし･･･さぁ次です次！

見晴観音から先は山々の縦走になりますがアップダウンもすくなく
走るテンポを上げることができました。まずは大丸山。

お次は大久保山です。

そして大平山･･･ここから野田山公園に向かって下ります！

が･･･ここで猛烈な藪藪藪･･･
下りの藪は足元が分からず非常に危険なので慎重に降ります。

無事に車道まで降りてこられました。
ここは次回行う新蒲原からのルートの合流点です。

警察屋さんがこんな山の頂上まで来てましたが･･･どうやら不法投棄監視の
パトロールされてるみたいですね。こういうとこって絶好の捨て場所ですからね･･･。

さて、エスケープルートはそのまま富士川方面にまっすぐ降りていく車道
なのですがねむいさんはもちろん東海自然歩道をさらに進みます。
ルート上の林道でついに夏富士を拝むことができました････！

さらに進んでいくと南松野の芝川コースと富士川コースの分岐点に着きます。
ここで富士川駅への進路をとります。次回のルートは結構このルートと
被りますね。

ぐんぐん車道を下っていくと新東名が見えてきました。この下をくぐります。

富士山もくっきり見えるようになってきました！

さらに下り、血流川を縫うように進むとこの東海自然トイレに突き当たります。
写真では見えてませんが手前のT字路で右折してください。

富士川の手前で身延道にそって登ります･･･だめだそろそろガス欠･･･

風の宮公園より富士宮方面と熱海方面の新東名高速を望みます。

少しのトレイルを抜け、道の駅富士川楽座をめざします。

視界が開けると富士川が一瞥できていい景色です♥

ねむいさんはもちろん川の風コースを選択！
もう暗くなってきましたし～

道の駅富士川楽座です。
ここは富士川ICでもあります。

さらに下って富士川橋です。
11年前富士山のふもｔ･･･ぶわわっ

もはや水分は出尽くした･･･
えっと暗いですが両脇に見えるのが岩淵一里塚です。

あたりがすっかり真っ暗になった頃についにJR富士川駅に到着です･･･
足には豆ができまくりましたが懸念された足の痙攣は全行程42kmとおして全く起こらず
特訓の成果が十分に得られたと確信しております。
また午後になって曇りになり急激に気温も下がってきたのが幸いしたと思われます。

夜の帳の下りたホームは風もあって少し肌寒いくらい。
夏の終わりを感じる一日でした････。

なお、この日の夕飯は鯛めしでした♥
飲み物はもちろんゑ・び・す♥
いいんですよぅこの日超がんばったしビールは入るところ別ですし！

というわけで記録的猛暑となった過酷なこの時期に逃げ場なしの直射日光が
照り付けてさらに過酷になる海沿いの2コースをわざわざ進みました。

しかし運良くどちらも途中から曇りになり熱中症になることもなく危なげなく
ゴールに到達できました！いやもちろん適切なアイテムしっかりそろえて挑んだ
のと地元京都で特訓しまくった成果が出ちゃっただけなんですけどね～
うふふ(地獄のミサワみたいな顔で)

次回は野田山周辺のルートをもう一度なぞりさらに芝川まで抜け、そして静岡
バイパスコースの終点であり本線とのエントリポイントでもある田貫湖をめざす
2013年度の東海自然歩道夏の陣のラストとなります。
草薙->興津　 GPSログ

興津->富士川　 GPSログ

FM3が富士通からスパンションになりましたよ記念

20161123追：
富士通のFM3を喰ったSPANSIONはCypressに喰われました。

富士通のFM3マイコンに関する記事はもう更新しないでクローズにしようと
思っていましたが、国産マイコンだったFM3シリーズが大人の事情でSPANSIONという
メモリ中心のチップベンダに移譲されたので記念に小ネタを更新します。

前回まではFM3マイコンにFatFsやTFT-LCDドライバなりを積だのを紹介して
ましたが今回はOpenOCDのFM3フラッシュ書き込みドライバの改良についてです。

いつも参考にさせてもらっているjujurouさんによると小規模のRAM物理量が少ない
品種で書き込みが出来ないとのことで、Kinetis-LシリーズやNuvotonのフラッシュ
書き込みドライバを実装して実力をつけた私も調査してみました。

上の二つの図はFM3マイコンに収納されたフラッシュ書き込みのバイトコード
(書き込みアルゴリズム)と書き込むべきデータを簡略化した物の修正前と
後の比較です。

フラッシュ書き込みはJTAG/SWDから内蔵SRAMに流し込んでおいたバイト
コードをOpenOCD側の"run_algorithm"にて実行させることにより行われて
いますが、その中でSRAM上にある"u32DummyRead"と"u32FlashResult"の値を
参照しています。この二つの変数は、アルゴリズムを確保したメモリの先頭に
置かれるため、アルゴリズム開始アドレスは、本来は基底アドレス
(BaseAddress)から+8ずれることになります。

おそらく最初にドライバを作った時のデバイスがMB9BF506Nだけだったようで
SRAMの基底となるアドレスが0x1FFF8000に固定化されていました。
しかしFM3シリーズの内蔵SRAMの構造は、0x20000000をベースとして上下に
伸びていく仕組みなので安全牌で動かすためには本来なら基底を0x20000000に
しなければなりません。現状ではSRAM量が物理的に少ない品種ではOpenOCDの
cfgファイル内でSRAM量とSRAM開始アドレスを"正しく"指定すると、
jujurouさんの指摘通りSRAMが存在しないアドレスを参照することになり、
書き込みが必ずコケる羽目になってしまいます。

というわけで私も私なりに修正してなおかつ書き込みパフォーマンスを上げる
修正を盛り込んでパッチを作成しました。先ず以前使っていたMB9BF618Tで
当然のように書き込みを確認しました。さらに今回の問題が修正されてるのを確認
するためにebayで小規模のFM3マイコンMB9AF112K(Flash:128kB/SRAM:16kB)
を仕入れて動作確認を行いました。
↓やっけつ基板

ログはこんな感じです。ばっちり書き込み出来てますね♥

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

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

Open On-Chip Debugger 0.8.0-dev-00117-gf7fed92-dirty (2013-08-12-20:01)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : OpenOCD runs in SWD mode

adapter_nsrst_delay: 100

jtag_ntrst_delay: 100

trst_only separate trst_push_pull

adapter speed: 500 kHz

cortex_m reset_config sysresetreq

verify Capture-IR is disabled

Info : Versaloon(0x15)by Simon(compiled on May 22 2013)

Info : USB_TO_XXX abilities: 0x0000076E:0x010001EF:0xC0000007

Info : clock speed 500 kHz

Info : Found SWD-DP id:0x2BA01477

Info : mb9bfxx2.cpu: hardware has 6 breakpoints, 4 watchpoints

target state: halted

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

xPSR: 0x01000000 pc: 0x00000114 msp: 0x20002000

auto erase enabled

Info : Fujitsu MB9[A/B]FXXX: Sector Erase ... (0 to 2)

Info : Fujitsu MB9[A/B]FXXX: FLASH Write ...

wrote 131072 bytes from file main.elf in 4.344639s (29.462 KiB/s)

verified 33456 bytes in 0.109398s (298.651 KiB/s)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:05

さて、上記FM3の修正のほかにkinetisドライバとNuvotonドライバのブラッシュアップ
も行い、8月11日時点のOpenOCDのコミットに適用したパッチ群も更新しました。
もちろんOpenOCDのバイナリも修正していますので奇しくも時を同じくして一般販売と
なった｢FM3-USBSTICK｣を購入された方は試してみてください(私はMB9AF112Kで試し
ましたがメモリ構造が同様のMB9AF312Kでもまったく同様に使用できます)。

･･･
本来はこの程度の小ネタはブログトップのサブタイ欄にちょっと書いて終わる
はずなのですがVersaloonのBBSにKinetis-LドライバやNuvotonドライバのパッチを
紹介したことでntfreakﾘﾝｻﾝの目に留まり、OpenOCDのgerritにFM3の修正を含めた
いくつかのパッチを叩き上げられることにめでたく相成りました。
しかし、そのFM3ドライバのパッチはまだバグが修正仕切れてなかった欠陥版
だったのがつい最近判明したので、汚名返上のために私自身もOpenOCDのコード
レビューシステムに電撃参戦する意を決めました！！

とはいえパッチを提供するまでに覚える事柄が非常に多く英語による意思の
疎通も非常に重要になります。なんにせよひとつずつ目的達成までの課題を
あせらずクリアしていくほかありませんが汚名挽回をしてしまわないように
気をつけます･･･。

LPC-Link2(という名のLPC4370評価ボード)を使ってみる

前回は2013/06中旬現在も謎に包まれたNxPのLPC4370が搭載されたLPC-Link2を
OSSで動かし、さらにLPC4370がトリプルコアであることまで突き止めました!
今回はまず安定してLPCLink2として動かすところから切り込みたいと思います。
もちろん今回もメーカ製のツールの事はスルーです！そもそも私のぶろぐに基本的な
使い方なんて期待して見に来ている人なんて誰ひとりいませんから…

●LPCLink2をJ-Linkとして"安定して"動かそう
さて、購入時にNxPが提供するdfutoolからJ-Linkファームウエアをダウンロード
するところからはぢめますがちょっとUSBの認識がおかしいのに気づきました。

↑たぶん正しいときのPOR

↑ちょっと変なPOR
気になってリセット波形を見るとLPCLink2上のLPC4370のreset信号のPORの波形が
微妙に違うときがありました。まさかPORの幅が短い時があるせいですか？と思い、
外付けのリセットSWを付けましたがやっぱり認識しない時は駄目。

それでVCC周りから回路をオシロでずーっと調べていたのですがそんな折にNxP
公式のconfiguration-toolがアップデートされ旧J-LinkファームのUSBがコケる問題が
あったことが判明!!つまりファームの問題！Tooooooo S**K!!
2013/05/31付けのファームと入れ替えることによりUSBの認識は安定するように
なりましためでたしめでたし♥J-Linkエミュとして使用されている方は早急にファームの
変更を行ってください。

つぎに本来の目的だったOpenOCDから使うことを目指しました。前回お見せした
通りJ-LinkファームでOpenOCDから書き込みデバッグできるのですが、たまにchain
読めずその時点でコケて上手くいかない状態が出てきました。
以下、STM32F407ZGT6に書き込みしようとした時のログです。
↓上手くいくとき

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

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

Open On-Chip Debugger 0.8.0-dev-00024-g08d4411-dirty (2013-06-06-10:12)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'jtag'

adapter speed: 1000 kHz

adapter_nsrst_delay: 100

jtag_ntrst_delay: 100

cortex_m3 reset_config sysresetreq

verify Capture-IR is disabled

Info : J-Link initialization started / target CPU reset initiated

Error: J-Link command EMU_CMD_VERSION impossible return length 0x7008

Error: J-Link command EMU_CMD_VERSION failed (0)

Info : J-Link JTAG Interface ready

Info : clock speed 1000 kHz

Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)

Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints

Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)

target state: halted

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

xPSR: 0x01000000 pc: 0x080450cc msp: 0x10010000

Info : reduce speed request: 21000kHz to 12000kHz maximum

adapter speed: 21000 kHz

auto erase enabled

Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE

Info : device id = 0x10006413

Info : flash size = 1024kbytes

wrote 655360 bytes from file main.elf in 16.062500s (39.844 KiB/s)

verified 555708 bytes in 0.656250s (826.946 KiB/s)

adapter speed: 1000 kHz

Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:19

↓いかないとき

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

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

Open On-Chip Debugger 0.8.0-dev-00024-g08d4411-dirty (2013-06-06-10:12)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'jtag'

adapter speed: 1000 kHz

adapter_nsrst_delay: 100

jtag_ntrst_delay: 100

cortex_m3 reset_config sysresetreq

verify Capture-IR is disabled

Info : J-Link initialization started / target CPU reset initiated

Info : J-Link LPC-Link 2 compiled May 31 2013 17:31:46

Info : J-Link caps 0xb9ff7bbf

Info : J-Link hw version 18010000

Info : J-Link hw type uknown 0x12

Info : J-Link max mem block 38488

Info : J-Link configuration

Info : USB-Address: 0x0

Info : Kickstart power on JTAG-pin 19: 0xffffffff

Info : Vref = 58.368 TCK = 12 TDI = 1 TDO = 0 TMS = 1 SRST = 0 TRST = 1

Info : J-Link JTAG Interface ready

Info : clock speed 1000 kHz

Info : TAP stm32f4x.cpu does not have IDCODE

Warn : JTAG tap: stm32f4x.cpu       UNEXPECTED: 0x00000000 (mfg: 0x000, part: 0x0000, ver: 0x0)

Error: JTAG tap: stm32f4x.cpu  expected 1 of 1: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

Info : JTAG tap: stm32f4x.bs tap/device found: 0xd0023bff (mfg: 0x5ff, part: 0x0023, ver: 0xd)

Warn : JTAG tap: stm32f4x.bs       UNEXPECTED: 0xd0023bff (mfg: 0x5ff, part: 0x0023, ver: 0xd)

Error: JTAG tap: stm32f4x.bs  expected 1 of 1: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)

Warn : Unexpected idcode after end of chain: 33 0x209820a5

Warn : Unexpected idcode after end of chain: 65 0xffffff83

Error: double-check your JTAG setup (interface, speed, missing TAPs, ...)

Error: Trying to use configured scan chain anyway...

Error: stm32f4x.cpu: IR capture error; saw 0x0e not 0x01

Warn : Bypassing JTAG setup events due to errors

Warn : Invalid ACK 0 in JTAG-DP transaction

Polling target stm32f4x.cpu failed, GDB will be halted. Polling again in 100ms

Polling target stm32f4x.cpu failed, GDB will be halted. Polling again in 300ms

Info : TAP stm32f4x.cpu does not have IDCODE

Warn : JTAG tap: stm32f4x.cpu       UNEXPECTED: 0x00000000 (mfg: 0x000, part: 0x0000, ver: 0x0)

Error: JTAG tap: stm32f4x.cpu  expected 1 of 1: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

Info : JTAG tap: stm32f4x.bs tap/device found: 0xd0023bff (mfg: 0x5ff, part: 0x0023, ver: 0xd)

Warn : JTAG tap: stm32f4x.bs       UNEXPECTED: 0xd0023bff (mfg: 0x5ff, part: 0x0023, ver: 0xd)

Error: JTAG tap: stm32f4x.bs  expected 1 of 1: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)

Warn : Unexpected idcode after end of chain: 33 0x209820a5

Warn : Unexpected idcode after end of chain: 65 0xffffff83

Error: double-check your JTAG setup (interface, speed, missing TAPs, ...)

Error: Trying to use configured scan chain anyway...

Error: stm32f4x.cpu: IR capture error; saw 0x0e not 0x01

Warn : Bypassing JTAG setup events due to errors

Warn : Invalid ACK 0 in JTAG-DP transaction

Error: Target not examined yet





Runtime Error: C:/Devz/ARM/OCD/tcl/target/stm32f4x_flash.cfg:85: 

in procedure 'script' 

at file "embedded:startup.tcl", line 58

in procedure 'reset' called at file "C:/Devz/ARM/OCD/tcl/target/stm32f4x_flash.cfg", line 85

make: *** [program] エラー 1



> Process Exit Code: 2

> Time Taken: 00:02

J-Linkハードウエアのイニシャライズでコケているような感じはしましたが、コケ
るときとうまくいくときに規則性があるのを見つけてOpenOCDコード内のjlink.cに
切り込みました。

ソースコードを読んだ限りではinit関数の中でJ-LinkハードウエアのI/O設定を通過
する部分があり、LPCLink2によるエミュの場合はそこを通過してしまうと逆にまずい
ことが判明。
というわけでHW-Versionを読み取りJ-LinkのハードがLPCLink2エミュの場合はその
場でinit関数を抜けるようにバイパスしたところうまい具合に動作は安定化してchain
を読みに行くときにコケることは一切なくなりました！

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

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

Open On-Chip Debugger 0.8.0-dev-00037-gc60deb5-dirty (2013-06-14-23:02)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'jtag'

adapter speed: 1000 kHz

adapter_nsrst_delay: 100

jtag_ntrst_delay: 100

cortex_m3 reset_config sysresetreq

verify Capture-IR is disabled

Info : J-Link initialization started / target CPU reset initiated

Info : J-Link LPC-Link 2 compiled May 31 2013 17:31:46

Info : J-Link caps 0xb9ff7bbf

Info : J-Link hw version 18010000

Info : J-Link hw type J-Link on LPC-Link2

Info : Vref = 3.300 TCK = 1 TDI = 1 TDO = 1 TMS = 1 SRST = 1 TRST = 1

Info : J-Link JTAG Interface ready

Info : clock speed 1000 kHz

Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)

Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints

Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)

target state: halted

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

xPSR: 0x01000000 pc: 0x080449f4 msp: 0x10010000

Info : reduce speed request: 21000kHz to 12000kHz maximum

adapter speed: 21000 kHz

auto erase enabled

Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE

Info : device id = 0x10006413

Info : flash size = 1024kbytes

wrote 655360 bytes from file main.elf in 15.531250s (41.207 KiB/s)

verified 555708 bytes in 0.640625s (847.116 KiB/s)

adapter speed: 1000 kHz

Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:17

こちらの修正はすでにOpenOCDバイナリに反映しているのでLPCLink2のJ-Link
エミュでも安心してお使いいただけます。自前でビルドされる方向けにパッチ群も
更新しておきました。
UrJTAGも類似した箇所でコケているのでこちらも調査/修正を~~行う予定です。~~
20130620追：
UrJTAGも修正掛けました！

所でLPCLink2をJ-Linkとして動かすとNxPのチップにしか使えないはずなのですが
STM32やFM3とかにもOpenOCDからバリバリ書き込み/デバッグが出来てます。"NxP
のチップしか使ってはならない"っていう規約的に使用不可であることを示す文面は
どこにも見当たらないのでねむいさんみたいな使い方しても全く問題ないでしょう。
問題あったら6月上旬の時点でNxPFanﾘﾝｻﾝに〆られてますし。
20130709追:
ライセンス制限が追加され、NxPのデバイス以外で使用を禁ずると明記されました。
OpenOCDからSTM32やKinetisやFujitsuやAtmelのARMマイコンに無制限に書き込み/
デバッグできますが、もう絶対にやってはいけません！やるなよ！絶対にやるなよ！

●LPCLink2をLPC4370評価ボードとして使う
こっからが本懐です！たった2000円と少しでトリプルコアLPC4370が搭載された
マイコン評価ボードが使えるのですから…！

前回のUrJTAGによりコアが3つあるMPUということが判明しています。同時に
LPCLink無印の時みたいにMCUのセキュリティは全くかかっていないのが分かった
のでJTAGkey2でやりたい放題にできちゃいます♥

LPC4370がLPC4350の機能拡張版なのを推定し、LPC4330-Explorerの時に使った
サンプルをLPC4370向けに作り変えてみました。ひとまずM4のみのシングルコア
動作です。

ビルドしたバイナリはボード上にあるSPIFI-SPIROMにプログラムを書き込みます。
ここら辺の操作はLPC4330の時と同じですがspifiブートはリセット2回でコケる
errataは無いのでへんてこなOpenOCDのcfgは書かずに済みます
…しかしLPCLink2上のSPIROMは、openOCDのSPIFIドライバに対応していなかった
のでこちらも対応させました…と言っても単にSPIROMのIDとセクタ/容量を追加
しただけです。

↓OpenOCDのログはこんな感じです。もちろんOpenOCDバイナリ・cfgファイル
　は上記の修正を反映済です。M0コアが2つ、M4コア1つが見えますね。

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

openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -f target/lpc4370_lpclink2_spifi.cfg -c "mt_flash_bin main.bin 0x14000000"

Open On-Chip Debugger 0.8.0-dev-00037-gc60deb5-dirty (2013-06-14-23:02)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'jtag'

cortex_m3 reset_config vectreset

none separate

adapter speed: 2000 kHz

Info : clock speed 2000 kHz

Info : JTAG tap: lpc4370.m4 tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

Info : JTAG tap: lpc4370.m0_0 tap/device found: 0x0ba01477 (mfg: 0x23b, part: 0xba01, ver: 0x0)

Info : JTAG tap: lpc4370.m0_1 tap/device found: 0x0ba01477 (mfg: 0x23b, part: 0xba01, ver: 0x0)

Info : lpc4370.m4: hardware has 6 breakpoints, 4 watchpoints

Info : lpc4370.m0_0: hardware has 2 breakpoints, 1 watchpoints

Info : lpc4370.m0_1: hardware has 2 breakpoints, 1 watchpoints

target state: halted

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

xPSR: 0x01000000 pc: 0x1400350a msp: 0x200029a0

background polling: on

TAP: lpc4370.m4 (enabled)

target state: halted

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

xPSR: 0x01000000 pc: 0x1400350a msp: 0x200029a0

Info : Found flash device 'win w25q80bv' (ID 0x001440ef)

cleared protection for sectors 0 through 15 on flash bank 0

auto erase enabled

wrote 65536 bytes from file main.bin in 0.953125s (67.148 KiB/s)

Warn : Invalid ACK 0x7 in JTAG-DP transaction

Polling target lpc4370.m4 failed, GDB will be halted. Polling again in 100ms

Polling target lpc4370.m4 succeeded again

target state: halted

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

xPSR: 0x01000000 pc: 0x1400350a msp: 0x200029a0

cleared protection for sectors 0 through 15 on flash bank 0

verified 4656 bytes in 0.031250s (145.500 KiB/s)

Warn : Invalid ACK 0x7 in JTAG-DP transaction

Polling target lpc4370.m4 failed, GDB will be halted. Polling again in 100ms

Polling target lpc4370.m4 succeeded again

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:03

上記のログで"Warn : Invalid ACK 0x7 in JTAG-DP transaction"が
出ていますが、これはOpenOCDから直接レジスタを叩きcoreresetを掛けて
いるために発生しているので実害は全くありません。

↑いつものデバッグも自由自在です(LPC4370の素性がわかる範囲で)

ひとまず問題なく動くと思われるLPC4370のプログラムをこちらに置いておきますので
物好きな方は試してみてください。最初に述べた通りLPCLink2は余計な
プロテクトは全くないので失敗を恐れずいろいろ試すことが出来るので、
なかなかいじりがいがあるボードだと思います！

いろいろ試す14

●余ったAT90USBKeyをPDI接続のXMEGAライタとして使う
AT90USBKeyは(元)主人の遺品の一つでしたが引き継いだ私がSTM32をはじめとした
32bitマイコンに完全移行した今、もう必要ないかと捨てるつもりでした。
しかしLUFAの成果物の一つにAVRISPmk2の実装があったことを今更知り、
XMEGA専用のフラッシュロムライタとして再生することにしました。

XMEGAにあるPDIインターフェースはCortex-M系のマイコンにあるSWDとよく似ていて
2線式で書き込み・デバッグを行うことができます。しかもXMEGAの場合はJTAG接続よ
りも書き込みスピードが速い(ATMEL曰く)のです！！

ATUSBKey上のAVRISPmk2の実装はPD2&PD3(PDIDATA),PD5(PDICLK)として引き出
されます。AT90USBKey上では上記図の様に配線します。またポートの出力バッファの
破損を防ぐためPDIDATA・PDICLKとも各自100～220ohmの抵抗を直列に付ける
べきです。本当は電圧トランスレータをかます必要がありますが、私は3.3V使い
しかするつもりがないのでこれで十分です。

PDIインターフェースはXmegaのReset信号を通信に使用します。外部リセット用の
メカニカルスイッチを実装している際にチャタリング防止のキャパシタを
ぶら下げてる場合は必ず外してください。

ドライバはおなじみのLibUSBを使い、書き込みはAVRDudeから行います。
メッセージはこんな感じです↓

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

avrdude -p atxmega128a1 -P usb -c avrisp2    -U flash:w:main.hex 



avrdude: AVR device initialized and ready to accept instructions



Reading | ################################################## | 100% 0.00s



avrdude: Device signature = 0x1e974c

avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed

         To disable this feature, specify the -D option.

avrdude: erasing chip

avrdude: reading input file "main.hex"

avrdude: input file main.hex auto detected as Intel Hex

avrdude: writing flash (118286 bytes):



Writing | ################################################## | 100% 9.27s



avrdude: 118286 bytes of flash written

avrdude: verifying flash memory against main.hex:

avrdude: load data flash data from input file main.hex:

avrdude: input file main.hex auto detected as Intel Hex

avrdude: input file main.hex contains 118286 bytes

avrdude: reading on-chip flash data:



Reading | ################################################## | 100% 7.77s



avrdude: verifying ...

avrdude: 118286 bytes of flash verified



avrdude done.  Thank you.





> Process Exit Code: 0

> Time Taken: 00:17

ついでなのでXMEGAのFatFs+TFTLCDの実装サンプルも新しくしました。
しかしこのXMEGA、A1シリーズの384kByte版や4bit-EBIの完全版とかがATMEL本家
からことごとく無かったことにされ、素直にARM使った方が良い昨今は存在意義が
ほんとにわかりません…まさに~~好き者~~物好きなあなたへ。
※もともと所持していた図体がでかいAVR-JTAGICEmk2は副業先に提供しました。

●ついでですがWinAVRからAVRToolchainに乗り換えるときの諸注意など
さすがにWinAVR使う人激減してますが、ねむいさんのようなコマンドラインビルド
主体の人がAVRToolchainに乗り換えるためのtipsを紹介します。

①PROGMEMの定義
　これもう海外ではavr-gcc4.7系が出てすぐにFAQと化した事柄ですがたまに質問
　もらいますので日本でも既に他の方々が言及してますが私もお伝えします。
　
　prog_****系の(prog_char)等の宣言が4.7系で廃止になったのでテーブル等の定数
　をフラッシュメモリ置くときは以下のように定義し直せばOKです。

　旧 :const prog_char unk[] ="inachang!";
　新 :const char unk PROGMEM[] = "inachang!";

　私が公開してるXMEGAのサンプルはすでに修正入れています。

②utilsが無い！
　AVRToolchainはAVRStudio6で使用するのが大前提なのでunixライクツールがあった
　utilsフォルダが存在しません。ですがAVR-GCCのバイナリがあるフォルダに同等の
　物が一緒にほぼ全部ぶち込まれてるので大抵は困りません。
　(sh.exeだけは無いです)
　シェル(sh.exe)に依存するmakeの書き方をしてるとエラーで止まるのでご注意
　ください。…LUFAっていまだWinAVR20101110が前提なんですよね…めどい…。
　因みに私が公開してるXMEGAのサンプルはもちろんこのビルド手順準拠です。
　ARM-GCCの代わりにAVRToolchainをGCCコンパイラとして指定するだけです♥

●デジカメ買い換えました

2010年の8月に購入後数日で比叡山の登山道の石の上におっとこして以来だましだまし
使用していたねむいさんのIXYDIGITAL220Fちゃんが湯の山温泉のバトルで力尽き
とうとう縦向きでしか撮影できなくなりE32エラーも連発するようになったので
最新のIXY3に買い換える運びとなりました…

2年たつと全然性能が違いますね…まぢて…マクロ撮影が1cmまでできるので
TFT-LCDのCOGの解析に役立つかもしれません！

●今まで普通に使えてたSDカードが急に書き込み禁止になったんですけぉ！！１！！
物がよくつぶれる(人も)ようになりました。ねむいさんが使ってるPCも上記の症状が
出るようになってしまいました…。SDカードは認識するがライトプロテクトが解除
出来ず書き込み禁止になるパターンはいくつかの原因が考えられます。

①SDカード本体のライトプロテクトキーがLOCKになっている
　->SDカードについているLOCKキーは物理的なものでSDカード内部と
　　電気的なつながりはありません。もしこれがLOCKの位置になってたら
　　ずらすと直ります。しかし大抵は…④に続く

②SDカードリーダ・ライタのドライバ側がライトプロテクト設定にしてある
　->ちょっとインテリジェンスなカードリーダ・ライタはたまにソフトウエアで
　　プロテクト設定可能な機能があります。違うカードリーダ・ライタだと普通に
　　読み書きができる手合いの奴ですね。マニュアルを見て解除してください。

③Windowsを使ってる場合限定でレジストリの設定でライトプロテクトにしている
->google先生に聞いてください…

④SDカードリーダ・ライトのソケットに問題があり、常にLOCK状態になっている
　->使い込んだリーダライタやノートPC付属の奴ではよくありがちです。
　　ではなんでこんなことになるのかを説明します。

SDカードの挿入検知(INS)とライトプロテクト(WP)検知はメカニカルスイッチで
行われ、カードリーダ側でその電圧レベルを読み取って状態を判断します。
INSとWPのポートは大抵は3.3Vでプルアップされています。

カード未挿入状態ではINSは解放されているので3.3Vになり、なおかつWPも上写真
ように解放されているので3.3Vとなり、ロジックレベルではどちらもHIになります。

このときSDカードのLOCKスイッチをLOCKにしないで挿入するとINSはSD
カードリーダ側のソケットと電気的に接触し信号レベルがGNDに落ちます。

同じくWPも挿入するとSDカード側のLOCKスイッチに物理的に押されてGNDに
落ちます。この状態ではカードリーダ側は読み書き可能と判断します。

一方SDカードのLOCKスイッチをLOCKの位置にスライドして挿入した場合、同じく
WPの接点とソケットのGNDが一時的に押されるわけですが深くまで挿すと位置的に
再び解放されてロジックレベルがHIに戻ります。
この状態ではカードリーダ側は書き込みのみ可能と判断します。

まとめると3つの状態があることがわかります。

・カード未挿入
　INS　:HI(3.3V)
　WP　 :HI(3.3v)
・カード挿入(LOCKの位置ではない)
　INS　:LOW(0V)
　WP　 :LOW(0v)
・カード挿入(LOCKの位置)
　INS　:LOW(0V)
　WP　 :HI(3.3v)

そしてWPの接点はINSよりも構造が脆弱で長期間使用で接点の弾性の劣化・酸化による
接触不良を非常に起こしやすく、ある日突然常にHIレベル(WP有効)と認識されるように
なってしまいライトプロテクト状態となってしまうわけです。

これについての対処方法ですが、つまりは接点を復活させればいいわけですが、USBの
カードリーダ使ってて起こった人は買い換えた方が手間暇も喰わず安上がりです。
しかしノートPC等で基板にソケットが備え付けられてるタイプの奴は一苦労です。大抵
修理保証期間を過ぎたころに上記の接触不良が発生するので上記の箇所の修理でも多額
のお金がかかるケースもあります。
ねむいさんの場合、購入後5年以上経過していたのとPCの裏蓋を外すとカードリーダー
のソケットが手の届く位置にあったので、WPの端子を導電性布テープで詰めて固定し
GNDに強制的に落としてLOCKスイッチの位置にかかわらず常にWP解除状態としました。

接触不良の初期段階の書き込み禁止になったりならなかったりの時は接点復活王なども
有効かもしれません。いずれにしてもソケットが手が届く位置にある場合限定です。

●STM32F4DiscoveryでMP3プレーヤーを構築する

ｸｸｸ…(by鍵最高)もうほぼ完成状態です…♥
こちらについては月末あたりに別枠でまたお知らせしますね～

OpenOCDの新MPSSEドライバを試す

20130403追追:
こちらのページにてOpenOCDとInsightを用いた効率的なデバッグ方法を
紹介しております。合わせてご参考願います。

20130403追:
私のおきぱで公開しているOpenOCDバイナリはWinUSB/LibUSB両対応と
なっております。
Zadigでインストールする際にLibUSBKを選択するとドライバの入れ変え無しに
どちらの方法からでもアクセス可能でさらに便利になっております。

MLを追いかけてる人ならご存知と思いますが少し前のOpenOCDのコミットで
新MPSSEプロトコルによるJTAGkey2をはじめとしたFTDI系デバイスでアクセス速度が
さらに向上するサポートが追加されました。
Windows環境下ではLPC17xx系でフラッシュ書き込みの速度不足を感じていたので私も
すぐに飛びつきました。

さて従来のものとどう違うかなのですが、新MPSSEは使用するドライバが
LibUSB(libftdi)やFTD2XX(libftd2xx)ではなくMicrosoftの汎用USBドライバで
あるWinUSBを使用する(実際はlibusb-1.0 async API のバックエンド)ようになります。

ねむいさん今までWindows環境上ではかたくなにFTDI純正ドライバ使用して
きましたが速度的に大幅に優勢になったのとlibusbがWin7系でも十分安定した
ので今回の変更を機にFTD2XXを捨てて乗り換えることにしました。

以下いくつかのMCUで実際に書き込みの比較を行います。
FT2232系デバイスとしてJTAGKey2を使用しています。

●RCLKを効かせたLPC2388の場合
*FTD2XX

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

openocd -s C:/Devz/ARM/ftdiOCD/tcl -f interface//jtagkey2.cfg -f target/lpc2388_rclk_flash.cfg  -c "mt_flash	main.elf"

Open On-Chip Debugger 0.6.0-dev-00624-gaf9918d-dirty (2012-07-17-22:29)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'jtag'

adapter_nsrst_delay: 100

jtag_ntrst_delay: 100

trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain

RCLK - adaptive

Info : device: 6 "2232H"

Info : deviceID: 67358712

Info : SerialNumber: 22222222A

Info : Description: Amontec JTAGkey-2 A

Info : max TCK change to: 30000 kHz

Info : RCLK (adaptive clock speed)

Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)

Info : Embedded ICE version 7

Error: EmbeddedICE v7 handling might be broken

Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units

fast memory access is enabled

dcc downloads are enabled

target state: halted

target halted in Thumb state due to debug-request, current mode: User

cpsr: 0x00000070 pc: 0x0002b5ae

auto erase enabled

wrote 491520 bytes from file main.elf in 7.796974s (61.562 KiB/s)

verified 465140 bytes in 0.515632s (880.935 KiB/s)

requesting target halt and executing a soft reset

target state: halted

target halted in ARM state due to breakpoint, current mode: Supervisor

cpsr: 0x000000d3 pc: 0x00000000

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:09

*WinUSB

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

openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -f target/lpc2388_rclk_flash.cfg  -c "mt_flash	main.elf"

Open On-Chip Debugger 0.6.0-dev-00626-g10fd274-dirty (2012-07-23-11:26)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'jtag'

adapter_nsrst_delay: 100

jtag_ntrst_delay: 100

trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain

RCLK - adaptive

Info : RCLK (adaptive clock speed)

Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)

Info : Embedded ICE version 7

Error: EmbeddedICE v7 handling might be broken

Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units

fast memory access is enabled

dcc downloads are enabled

target state: halted

target halted in Thumb state due to debug-request, current mode: User

cpsr: 0x00000070 pc: 0x0002b5a8

auto erase enabled

wrote 491520 bytes from file main.elf in 4.859437s (98.777 KiB/s)

verified 465140 bytes in 0.437505s (1038.247 KiB/s)

requesting target halt and executing a soft reset

target state: halted

target halted in ARM state due to breakpoint, current mode: Supervisor

cpsr: 0x000000d3 pc: 0x00000000

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:06

もう全然威力が違うのがわかりますね♥

●STM32F4の場合
*FTD2XX

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

openocd -s C:/Devz/ARM/ftdiOCD/tcl -f interface//jtagkey2.cfg -f target/stm32f4x_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.6.0-dev-00624-gaf9918d-dirty (2012-07-17-22:29)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'jtag'

1000 kHz

adapter_nsrst_delay: 100

jtag_ntrst_delay: 100

cortex_m3 reset_config sysresetreq

verify Capture-IR is disabled

Info : device: 6 "2232H"

Info : deviceID: 67358712

Info : SerialNumber: 22222222A

Info : Description: Amontec JTAGkey-2 A

Info : max TCK change to: 30000 kHz

Info : clock speed 1000 kHz

Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)

Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints

Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)

target state: halted

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

xPSR: 0x01000000 pc: 0x080451a0 msp: 0x10010000

15000 kHz

Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE

Info : device id = 0x10006413

Info : flash size = 1024kbytes

stm32x mass erase complete

wrote 550968 bytes from file main.elf in 4.093803s (131.432 KiB/s)

verified 550968 bytes in 0.781260s (688.701 KiB/s)

Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:20

*WinUSB

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

openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -f target/stm32f4x_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.6.0-dev-00626-g10fd274-dirty (2012-07-23-11:26)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'jtag'

1000 kHz

adapter_nsrst_delay: 100

jtag_ntrst_delay: 100

cortex_m3 reset_config sysresetreq

verify Capture-IR is disabled

Info : clock speed 1000 kHz

Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)

Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints

Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)

target state: halted

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

xPSR: 0x01000000 pc: 0x08045c28 msp: 0x10010000

21000 kHz

Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE

Info : device id = 0x10006413

Info : flash size = 1024kbytes

stm32x mass erase complete

wrote 550968 bytes from file main.elf in 3.937550s (136.647 KiB/s)

verified 550968 bytes in 0.546882s (983.859 KiB/s)

Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:21

残念ながらSTM32系はフラッシュの消去が遅いので(autoeraseだとさらに遅くなるので
"stm32f2x mass_erase 0"の使用を推奨)そっちに足が引っ張られます。実際のテンポは
あまりよろしくないです。それでも100kiB/Sec越え(どっちも越えてますがー！）
また同じスクリプトファイルでも新MPSSE版はJTAGのクロックが細かく設定できるよう
になり若干JTAGのクロックも早くなります♥
20130507追:
…と思いきや実際にオシロで波形を測定してみると15MHzのままでしたorz
FT2232Hの仕様上MPSSEの最高が30MHzでその一つ下は15MHzとづづきますからLibftdiの
時はOpenOCDの周波数の表示が計算上の値を正直に出してるだけで実際にFT2232Hに
設定されるTCKの周波数とは全く違うということですねorzorz

ちなみにSTM32F1系はもっと悲惨でフラッシュの書き込み速度も遅いため
35~7kiB/Secで一律頭打ちになってしまいます。
*FTD2XX

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

openocd -s C:/Devz/ARM/ftdiOCD/tcl -f interface//jtagkey2.cfg -f target/stm32f107.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.6.0-dev-00624-gaf9918d-dirty (2012-07-17-22:29)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'jtag'

1000 kHz

adapter_nsrst_delay: 100

jtag_ntrst_delay: 100

cortex_m3 reset_config sysresetreq

verify Capture-IR is disabled

Info : device: 6 "2232H"

Info : deviceID: 67358712

Info : SerialNumber: 22222222A

Info : Description: Amontec JTAGkey-2 A

Info : max TCK change to: 30000 kHz

Info : clock speed 1000 kHz

Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)

Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)

Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints

Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)

Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)

target state: halted

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

xPSR: 0x01000000 pc: 0x0802bb00 msp: 0x20010000

7500 kHz

Info : device id = 0x10016414

Info : flash size = 512kbytes

stm32x mass erase complete

wrote 434240 bytes from file main.elf in 11.765700s (36.042 KiB/s)

verified 434240 bytes in 1.015631s (417.536 KiB/s)

Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)

Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:13

*WinUSB

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

openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -f target/stm32f107.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.6.0-dev-00626-g10fd274-dirty (2012-07-23-11:26)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'jtag'

1000 kHz

adapter_nsrst_delay: 100

jtag_ntrst_delay: 100

cortex_m3 reset_config sysresetreq

verify Capture-IR is disabled

Info : clock speed 1000 kHz

Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)

Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)

Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints

Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)

Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)

target state: halted

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

xPSR: 0x01000000 pc: 0x0802bbe0 msp: 0x20010000

9000 kHz

Info : device id = 0x10016414

Info : flash size = 512kbytes

stm32x mass erase complete

wrote 434240 bytes from file main.elf in 11.640700s (36.429 KiB/s)

verified 434240 bytes in 0.765629s (553.875 KiB/s)

Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)

Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:13

●FM3の場合
*FTD2XX

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

openocd -s C:/Devz/ARM/ftdiOCD/tcl -f interface//jtagkey2.cfg -f target/mb9bf618t_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.6.0-dev-00624-gaf9918d-dirty (2012-07-17-22:29)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'jtag'

adapter_nsrst_delay: 100

jtag_ntrst_delay: 100

trst_only separate trst_push_pull

500 kHz

cortex_m3 reset_config sysresetreq

verify Capture-IR is disabled

Info : device: 6 "2232H"

Info : deviceID: 67358712

Info : SerialNumber: 22222222A

Info : Description: Amontec JTAGkey-2 A

Info : max TCK change to: 30000 kHz

Info : clock speed 500 kHz

Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

Info : mb9bfxx8.cpu: hardware has 6 breakpoints, 4 watchpoints

Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

target state: halted

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

xPSR: 0x01000000 pc: 0x00000114 msp: 0x20010000

Rize up to Internal PLLed Clock!

15000 kHz

auto erase enabled

Info : Fujitsu MB9Bxxx: Sector Erase ... (0 to 5)

Info : Fujitsu MB9B500: FLASH Write ...

wrote 524288 bytes from file main.elf in 9.312559s (54.980 KiB/s)

verified 505904 bytes in 0.578129s (854.562 KiB/s)

Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:12

*WinUSB

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

openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -f target/mb9bf618t_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.6.0-dev-00626-g10fd274-dirty (2012-07-23-11:26)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'jtag'

adapter_nsrst_delay: 100

jtag_ntrst_delay: 100

trst_only separate trst_push_pull

500 kHz

cortex_m3 reset_config sysresetreq

verify Capture-IR is disabled

Info : clock speed 500 kHz

Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

Info : mb9bfxx8.cpu: hardware has 6 breakpoints, 4 watchpoints

Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

target state: halted

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

xPSR: 0x01000000 pc: 0x00000114 msp: 0x20010000

Rize up to Internal PLLed Clock!

18000 kHz

auto erase enabled

Info : Fujitsu MB9Bxxx: Sector Erase ... (0 to 5)

Info : Fujitsu MB9B500: FLASH Write ...

wrote 524288 bytes from file main.elf in 6.984419s (73.306 KiB/s)

verified 505904 bytes in 0.343753s (1437.215 KiB/s)

Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:09

FM3の場合はフラッシュの読み書きが非常に速いためRCLKを効かせたLPC2388
並みに速くなっています！
(でもCQ出版系の雑誌記事では大人の事情でわざわざこの性能を殺し、
さらにわざわざめんどくさい使い方やデバッグ方法しか紹介してませんね…)

上記3つの検証ではねむいさん特製の各マイコンに合わせたOpenOCDのスクリプトで
あらかじめCPUの最高速度まで叩き上げてこの数値を出しています。
(最高速にするために動作電圧も+3.3Vを想定しています)。

ということで今回の変更によって益々デバッグの回転力が上がることが期待されます。
また、付加的な利点としてFTD2XXを排したことによりプロプライエタリなライブラリが
なくなるのでOpenOCDのバイナリがおおっぴらに配布できるようになるという私のよう
な教える側の人にとってはARMマイコンのビルド・デバッグ手順の整備が大幅に短縮・
簡略化されることにもなり非常に手間が省けます♥　こっこれで"ねむいさんという
人のページみたけどやり方がさっぱり"って後ろ指挿されることなくなったんじゃ！！

中途半端に尺が余ったので、今までにOpenOCDの操作に関していただいた問い合わせの
中で私が｢初めて触った人が陥り易く、かつ致命的になる｣と感じた問題たちについての
回避策やtipsをご紹介したいと思います。

●STLinkでOpenOCD使ってみたいのですがLibUSBやWinUSBのドライバの
　インストール方法が面倒そうででわかりません＞＜;
->zadigれ

●あんたのところの記事をもとに基板作って自作のプログラム書き込んだらJTAGで
　一切アクセスできなくなってフラッシュが書き換えできなくなってしまった。責任とっ
　てこさえた基板言い値で全部買い取れ。
　~~->ｶｴﾚや!!1!~~
->STM32ではWFI命令を含むプログラムを実行した後ペリフェラルのクロックが停止し
　　ますが同時にコアにあるデバッグユニットに供給されるクロックも仲良く停止し
　　てしまい、JTAG/SWD等で一切アクセスできなくなってしまいます。

　　回避策はWFIが実行される前に速攻HALTをかけてフラッシュを全消去して電源再投
　　入してやれば再びアクセスできるようになります。しかしこの方法はタイミングが
　　シビアすぎるのでお勧めできません。
　　
　　確実な方法は、システムメモリからブートするモードにしておき、リセットかけ
　　ても常にブートローダーに飛ぶようにしておくとJTAG/SWDでアクセスできるよう
　　になってとにかくフラッシュを消去できるようになります。ブートローダーから
　　そのままFlashLoader等のツールでUART経由で消去しても構いません。

　　ここ最近で"元に戻せなくなった"と↑の質問をいただくケースが激増してます。
　　戻す方法はちゃんとあるのであきらめないでください。

●LPCXpresso基板のLPCLinkの部分を分離してJTAGkey+OpenOCDをデバッガにして
　開発を始めてみました。でも何故かmbedやLPCXpresso(ねむいさん注：IDEの方)
　で動いていたLチカのプログラムが全く動きません＞＜;
->NxPの内蔵フラッシュ付きのARMマイコンは伝統的にCheckSumValidationを持って
　　います。これはリセット直後にフラッシュのとある番地にあるリセットベクタの
　　チェックサムの値を確認し正しくなければISPに飛んでいく機構です
　　(ユーザーマニュアル参照)。
　
　　mbedやLPCLinkのライタは書き込む際にリセットベクタのチェックサムを計算し、
　　その番地の値だけ計算済みの値に改変して書き込むのでCheckSumValidation
　　を通過しユーザープログラムを実行することができます。もちろんOpenOCDでも
　　同じことが可能ですが、ベリファイの際は改変前のバイナリと比較してしまう
　　ため、必ずエラーになってしまいます(=ゆえにベリファイだけできない)。

　　ベリファイまで通したい場合は、あらかじめ計算した値をリセットベクタの指定
　　のアドレスに書き込んでおくことで可能となります。私が公開しているLPC系の
　　マイコンのプロジェクトは、すべて計算済みの値を記してあるので参考にしてく
　　ださい(スタートアップのアセンブラファイルに直値を記述)。

●フリーのEclipseを使った開発をしているのですが(ry
->(全身から血をふきだして死んだ)
　　※しかしねむいさんは有償のEclipseベースの開発環境では死にません。
　　　死ぬのはあくまでも設定が死ぬほど面倒な素のEclipseで攻撃された時です。
　　　あといないさんのおぱんつ画像でも一発で死にますので絶対に見せたりしな
　　　いでください絶対ですよ絶対！！１！１

●ねむいさんの手順の通りにしているけどOpenOCDがビルドできません＞＜;
->ビルド済のバイナリを用意したのでこれからはおきぱのOpenOCDのバイナリを使っ
　　てください。FTD2XXのライブラリは使用していないのでGPLに引っかからずバイ
　　ナリを自由に利用できるようにしました!…あとご忠告ですが、最初のうちは変
　　な自分流のアレンジをしたりせずにあくまでも手順に沿ってやりましょうね…。

●mt_flashとかいうのがよくわかりません&見つかりません＞＜;
->大昔はtelnetでOpenOCDとコマンドのやり取りをし、マイコン内蔵のフラッシュに
　　プログラムを書き込む方法しかありませんでした。現在はその方法はスマート
　　では無く、ARMコアなルーターのフラッシュ書き換えの際の動作確認程度にしか
　　利用されていません。
　　デバッグでカットアンドトライをしてる時はとても効率が悪いです。

　　しかしながら上記のような"現在は不適切なor廃止された"とされる数年以上も
　　前のOpenOCDに関する情報が｢最新のOpenOCDを～｣という見出しで検索の
　　トップを占めているのが現状で、何も知らない人がこれらの情報をもとに"最新"
　　のOpenOCDを使おうとしても当然うまくいくはずもなく、"使えない"、
　　"敷居が高い"という印象を持って離れてしまっています。

　　2012年7月現在"最新"の0.6.0ではWindowsはバッチファイルで、Linux系なら
　　シェルスクリプトでJim-Tclのスクリプトをコマンドの引数として一括で呼び出す
　　ことにより簡単に書き込み動作ができるようになります。mt_flashってのはその
　　スクリプトの名前のことで、それが記述されているスクリプトもしくはコンフィグ
　　ファイルがないと当然使用できません。私が公開しているOpenOCDのバイナリ
　　にはそれらが仕込まれたコンフィグファイルがありますので安心してお使い
　　ください。

　　ちなみにmakeと組み合わせることによりさらに効率よく開発が可能です。
　　長々と書きましたがここ見てくれれば間違いないのですがそうだね宣伝だね。

●"Remote 'g' packet reply is too long"というエラーが(ry
->去年の年末に｢次それ聞いたら頭にJTAGKeyぶっ挿して一ビットずつ対策方法焼き
　　こんでくから｣…って私言いましたよね！？

FM3マイコンを使ってみる4 -もう、誰も...-

もう触る気力がゼロになってしまったのでいつも見に来てくださってるFujitsuの方々
には真に申し訳ないのですがここで打ち切っていつものの公開をさせていただきます。

●勝てなかったよ…
当初実装予定だった以下のコードは私の力不足もあって盛り込めませんでした。
・外部SRAMアクセス
　->基板に半田付けまではしたけど配線めどい。
・松浦氏のmp3プレーヤー(libmad)の移植
　->STM32F4でhelixの方を移植しリベンジ完了。

●いつもの
私のぶろぐにおいていつものとはChaN氏謹製FatFsの移植例を指します。
もちろん単に移植しただけではなくTFT-LCDと組み合わせた(同じくChaN氏の)
ファイラにより視覚的に操作が可能になっています。どのMPUにかかわらず
いつものは基本的に下記の機能を網羅するようにしており他の用途にも
簡単に応用できる仕組みとなっています。

・FatFs
・UART(TFT-LCDドライバ/FatFsテストルーチンの動作に必ず必要)
・TFT-LCDドライバ
・SPI転送(TFT-LCDドライバに使う)
・外部バス(TFT-LCDドライバ・SRAMに使う)
・タッチパネル入力(TFT-LCDドライバに使う・BlueScreenのものを汎用化して移植)
・タッチパネル入力用のデータ保持(FRK-FM3ではFRAMを使用)
・DMA転送(TFT-LCDドライバに使う)
・FONTX2ドライバ

●動かすためのハードウエアの準備

FRK-FM3にのっかっているレギュレータはデフォルトではLDO側の出力が使用
されています。これを600mA引き出せるDCDCコンバータ側に切り替えました。
基板単体で通電した時の立ちあがりとたち下がりの波形は以下の通り。

まぁ特に問題もないですね。(あったら困りますけど…)

基板から外の配線は、GNDとVCCの配線がものすごく簡単になるアイテムラボ
さんのパワーメッシュユニバーサル基板を使用しました。

裏にはebayで大量に購入したmicroSDカードスロットを設けました。
安価で引き回しもやりやすいです♥

アナログ出力はローパスフィルタを通じて単電源オペアンプで構成されたボルテージ・
フォロワ経由で行います。3.5φのジャックをつけるコネクタの上に見えるヘッダピンは
ボリ松基板(LPC2388用)をつけるためのものです。

TFT-LCDモジュールはパラレル/シリアル用のポートを引き出してます。中央のICは
くっつけただけで配線で挫折した1MBのSRAM...

いつものを動かしてみたところです。もはやここまでは基本の"き"ですね～。

8bit-i8080と8bitSPIのRGBデータのブロック転送はDMAに対応しています。
ところで外部バスを使用した場合のDMAはメモリ間転送扱いなのでまだ簡単
なのですがMFSを用いたSPIでDMAする場合の具体的な手順がいまいちわからず
難儀しました。資料を探してFM3の英文の方のサイトの別品種のサンプル例に
UARTでの転送手順があったのでこれをもとにDMA転送ルーチンを作りました。
転送に関しては以下の要素が必要です。

・MFSのDMAはハードウエアのデマンド転送とする
・MFSの送信/受信割り込みをDMA要求として使用する
・DMACBxレジスタのEBビットは立てるのを忘れずに
・送信/受信割り込み許可ビット立てて転送開始

ぇっと詳しい手順はソースを見てください(丸投げ!)
XMEGAのMSPIでDMA転送できるようになった経験が生きました。

ちなみに速度は遅いですがソフトウエアSPIも出来るようにしてます。
尤もFM3の場合は9bitSPIが可能なので出番は無いと思います。

今回は表示系もちょっとだけパワーアップしてます。ロングファイルネーム(LFN)も
表示が出来るようになってます♥

これはWAVEファイルを再生してる画面ですがLFNの日本語ファイル名にももちろん
対応です。ちなみに私もf_stat()で取得したFILEINFO構造体のデータがLFNだけ
拾ってこられない罠にはまった一人ですorzSFNからLFNを引っ張ってくる
関数を一つ設けて実現しています。

というわけでFM3にかなり寄り道してしまいましたがこの経験をSTM32F4に
反映していこうと思います。
せっかくSTM32F427超格安全部載せ基板買ってしまってもったいないですし！

FM3マイコンを使ってみる3 -FatFsとTFT液晶表示の実装-

今月(2012年7月号)のInterface誌は予想に反して私のようなホビイストには
とてもありがたい内容となっておりました。
ねむいさんは正直Windowsネイティブな環境でもGCCでビルドや
デバッグできるのになぜか面倒なcygwinを使わせた上糞の役にも立たないLED
点滅で終わらせて実用的な作例はIARとかKEILのIDEのみで行って｢んんんｎ～～！！！
GCCは面倒ですぞ～！CQ出版がお勧めするIARやKEILを使ってくだされ～！１！｣って
販促するパタンで畳み掛けると思ったのですがどうせなら開き直ってDS-5とか
推せよとかいつも思っていたのですが今回は全然そういう事は全くなく、
オープンソースなソフトウェア(OSS)をフルに活用した記事が満載でした。
もちろんOSSにもメリットデメリットがあって邑中雅樹氏の講演のスライド13p目に
それが集約されていると思います。タダより高くつくものはないです。
しかしながら趣味でやる場合は互いに情報を出し惜しみすることなく情報を
やり取りすることによって敷居を低くできるので横のつながりを大切にして
いきましょうね。

私も"ねむいさんのページ見てもわかりづらくてOpenOCD動かせられなかったけど
他の人のページに書いてあるやり方だったら一発で出来た"と言われないような
記事作りを心がけて行きます(←まだ根に持ってる)

…さて戯言はこの辺にしといてFM3マイコンはFatFsとシリアル&i8080バス
接続タイプのTFT-LCDドライバを使ったいつものの実装を目標と
しています。FM3のデータシートや
アプリケーションノートは情報散らばりすぎでいまいち組み方がわかりづら
かったのですが、上記IF誌に収録されていた作例にわかり易いサンプル例が
多数収録されておりそれを最大限に活用させていただきました。

●UARTとFatFs
UARTは前回行ったのと同じですが、前回jujurou氏よりコメントいただいた通り
SRAMの割りあてはSTM32F4の時のように目くじら立てるほどのことではないことが
判明しふつーに128kByteの内蔵SRAMとして使うことにしました。私が試した限りでは
すべてのSRAM領域でDMA可能でなおかつコード実行も可能でした。

というわけでChaN氏の作例にならってMFSを使ったMMC用のドライバも作り、
危なげなくFatFsも動作確認しました。ちなみにChaN氏はDMAを使用せずFIFOを
使用していますがSCKを18MHzにしたリード速度は下画像のようになりました。

STM32F107(DMA転送)の時とほぼ同じですね～。SPIモードの場合の理論上の
転送スピードは18MHzの時約2.2MByte/Secになりますから無理してDMA化する必要が
なかったようですね。尤もFM3においては内部の遅延により+3.3V駆動の際に保証
されるSCLKの最高速度は7.2MHzにしかならないそうです。
STM32F4とかはSPIでも42MHzまで叩き出せるのにs**kです。

●シリアル接続タイプのTFT-LCD
扱いも容易でaitendoさんで手軽に購入できるようになったシリアル接続タイプの
TFTLCDも、FatFsの時と同じくMFSを利用してHALを作りました。もちろんGPIOによる
ソフトウェアSPIにも対応していますが…FM3のGPIOはAPBバスにぶら下がっていて
なおかつ1HCLK分ウエイトが掛かっているようでGPIOの出力レジスタに8bitのデータ
投げるような単純にstr命令だけが連続するような操作でもMAX12MHz、ビットバンド
領域の単純なビット操作はその半分のMAX6MHzしか出ないことが判明し、あまりお勧め
できません。

↑0xFFと0x00を交互にPDORFxに全速力でﾌﾞﾝ投げた時のI/Oトグル波形…
　STM32F1(18MHz)以下ですかorz

↑ビットバンドなアクセスの場合はCortexの仕様上最短2クロックサイクル
　かかるのでさらにその半分orz
　TFT-LCDのRES線制御等の1ビット分だけの制御の場合はリードモディファイ
　ライトが行われないビットバンド領域のアクセスの方が早いです。
　ちなみにFM3にはSTやNxP系ARMマイコンにあるGPIO出力ポートのビット
　セット/リセットレジスタなぞありませんorz

また、上のFatFsの話の時は7.2MHzしかSPIの速度が出せないと述べていますが
リードのことは考えずただLCDにシリアル信号をﾌﾞﾝ投げるだけなら18MHzでも
全く問題ないのでどしどし使いましょう。とくにFM3では9bitシリアルもハード
ウエアで設定可能であり、9bitシリアルにしかI/Fが対応していないTFT-LCD
モジュールなどでは速度面で重宝します。

↑ということで9bitシリアルにしか対応してないHX8340B(N)なTFT-LCDモジュールを
　ハードウエア9bitSPIで動かしてみました。表示が早くなって感激です！
　これでNokia6070その他9bitシリアルな液晶さんたちが救われます！ちなみに…、

　いないさんの大事な部分が見切れていますがこれはPNG表示ルーチンの仕様です。

●外部バスとi8080バス接続タイプのTFT-LCD
今回のFM3基板に乗っかっているチップはA24までExternalBusInterfaceとして
アドレスバスが出せられます。
とはいえLCDを駆動するだけならアドレス線は一本だけで十分ですが…

こちらに関しては7月号の付録に収録されている松浦氏のMP3プレーヤーのLCD/SRAM
アクセス初期化部をかなり参考にさせていただき、さらにSTM32/LPC2388のように
柔軟性を上げて作り込みました。
今回の松浦氏の紹介にあるMP3プレーヤーの基板の回路に互換性をもたせてあります
ので他の方も再現できると思います(タッチパネル制御はADCを使用せず、ADS7843に
任せていますので非互換です)

↑この写真ではすでにタッチパネル制御も入れてます。

●タッチパネル制御
タッチパネルによる座標情報はタッチパネルコントローラICであるADS7843を
使用して得ています。AD7843はSPI通信の信号はかなり遅めにする必要があるので
簡素なGPIOによるソフトSPIでも十分間に合います。

さて、タッチパネルはキャリブレーションが必須ですが、キャリブレーションした
後のデータはこのFM3基板上実装されたFRAM(MB85RC16)にストアしました。
こちらに関してもChaN氏がFRAM向けのI2Cドライバとして実装されていたので
こちらを活用し、ストア・リストアするルーチンを作り込みました。
使用していて気付きましたが、やはりFRAMであってもWRITEを行った後は少し
ウェイトを挿入しないと次のWRITE操作に影響が出ることが分かり、なるべく
一つのデータにまとめて一つのWRITE操作で書き込むようにしています。

…ということでChaN氏のFatFsとファイラを実装して動かすという当初の目的が
達成されたわけですが、PWM出力と外部SRAM、あと外部SRAMとのDMA転送も試して
みたいのでもう少しコードは練った上での公開とさせていただき~~ます。~~
公開しています。

STM32F0とXMEGAのFatFsのDMA化とTIのStellarisと東海自然歩道のネタが次に控えて
いて書くことがたくさんあり過ぎますがもう少しだけFM3です。

おまけ：FM3マイコンの性能やデバッグ効率を上げる小ネタです。

●FM3のパフォーマンスをアップする
HCLKが72MHz以上の時、FM3はプリフェッチバッファが有効になるそうですが
(元から有効化されてるみたいですが)この時さらに先読みした命令をストアできる
トレースバッファを有効化することもできます。FUJITSU提供のテンプレートでは
有効化するルーチンは無いので自分で挿入する必要があります。
消費電流は100mAオーバー(HCLK=144MHz時)で結構発熱しますがそれを厭わない方は
ｶﾞｼｶﾞｼ使って行きましょう。

●OpenOCD経由のフラッシュ書き込み速度を増加してデバッグ効率のアップ
現在のOpenOCDのFM3のフラッシュ書き込みルーチンは、I/Dコードバスに
ぶら下がった内蔵SRAM領域にフラッシュ書き込み操作とフラッシュに書き込む
データをJTAG/SWDで転送・実行していますが、ワークメモリの容量はハード
コーディングされています。128kByteもあるMB9BF618Tではもっと大容量の
メモリを確保可能なのでこの部分をデバイスID別に可変にするようにしました
(MB9BF618Tの場合は32768Byteにしました)。

ワークエリア増やしてもあんまし変らんだろと思っていましたがなんと
驚くべき結果が！！！！！

> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program

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

Open On-Chip Debugger 0.6.0-dev-00595-g445a54a-dirty (2012-05-26-12:03)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'jtag'

adapter_nsrst_delay: 100

jtag_ntrst_delay: 100

trst_only separate trst_push_pull

500 kHz

cortex_m3 reset_config sysresetreq

verify Capture-IR is disabled

Info : device: 6 "2232H"

Info : deviceID: 67358712

Info : SerialNumber: 22222222A

Info : Description: Amontec JTAGkey-2 A

Info : max TCK change to: 30000 kHz

Info : clock speed 500 kHz

Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

Info : mb9bfxx8.cpu: hardware has 6 breakpoints, 4 watchpoints

Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

target state: halted

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

xPSR: 0x01000000 pc: 0x00000114 msp: 0x20010000

Rize up to Internal PLLed Clock!

15000 kHz

auto erase enabled

Info : Fujitsu MB9Bxxx: Sector Erase ... (0 to 9)

Info : Fujitsu MB9B500: FLASH Write ...

wrote 1048576 bytes from file main.elf in 18.625118s (54.980 KiB/s)

verified 941740 bytes in 0.828131s (1110.534 KiB/s)

Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:21

なんと
wrote 1048576 bytes from file main.elf in 18.625118s (54.980 KiB/s)
となって、前々回と比べると5倍以上高速化出来るようになりました！
なんというか新生青銅聖衣を装着して敵の本拠地にカチ込まんとする
星矢さんのような"よぉしこれで全力で戦える！！！"な気分です。

一通り検証も終わったのでOpenOCDビルド時のFM3向けパッチとして公開しています。
今回のパッチはiruka氏とjujurou氏の物を合わせたのをベースにしてます。
また、OpenOCDのFM3向けコンフィグファイルと組み合わせないと性能が
出ないので上のOpenOCDのビルド&デバッグ方法をよく読み試してください。

東海自然歩道を徃く16(田口～四谷/四谷～三河大野)

うｎ、今このページ開いた君が今がっかりしてる理由はわかる。FM3マイコン基板関連
の記事が更新されてると思ったらいつもの写真ベタベタ貼り付けてる東海自然歩道の
ｸｯｿ重い記事なんだから。でもこれ単なるハイキングではなくて、れっきとしたGPSロ
ガーの実践動作検証なのは分かる人には分かってくれていると思う(逆切れ)。

そして中部地方ステージ前半の最終区間の記録なのでじっくりと見てほしい。

●2012.03.25 田口～四谷

さて、今期最終区間の田口～三河大野を往くわけですが、この区間は一般的に東海
自然歩道の三大難所の一つと呼ばれています。残り二つは丹沢縦走と鍋倉山です。
尤も鍋倉山が難所だった理由は前世紀までは鍋倉山<->池田山の連登ルートだった
からで、野原谷が整備難によって廃され池田山の麓を迂回するルートになってから
は格段に難易度が低下してます。ねむいさん的にはアクセスが非常に悪くなり道も
ガタガタになってしまった鈴鹿峠周辺を新たな難所に推したいと思います。

すみません前置き長すぎましたが名古屋駅から本長篠までは格安で新幹線を利用で
きる新城・本長篠往復切符(新幹線版)を利用しました。新幹線は早いのですがすれ
違い待ちがやたらと多い飯田線が苦痛です...

やっとこ飯田線から解放されたら今度はバスで40分ほど…もうケツが痛いです…
この写真はバスの車窓から取った鳳来寺山門です。かつてはここは田口線の線路
でした。

そして終点の田口バス停に着いたころには雪が！！
三月下旬の忘れ雪ですか…

今回は先にちょっと寄り道をしてきました。以前田口に行きついた時にはスルー
していましたが田口線で使用されていた車両が保存されている奥三河郷土資料館
です。いわばもう一つの三河田口駅です。

車両内は田口線のちょっとした資料館となっています。

郷土資料本館内を見てる時間はさすがに無いので車両だけ見てこの場を去りました。
こんどこそさらば。今回もやはりタイムアタックな山行なのです。

エントリポイントの福田寺に。雪がやむどころかさらに勢いを増してきやがりました。

ルートは田口の街の外周をぐるっと回って和市へと向かいます。
なんか通行止めの橋がありましたが下を通過しクリア。

設楽ダムの"縄張り"が多数ある集落を抜けて和市へ向かう山道へ…！

雪は止みましたが標高が高まってくると今度は積雪が目立ってきます。
ルート上で一番高くなる地点で池葉守護神社に。ここからまた下って
いきます。

和市のバス停の分岐に。ここから先は岩古谷山への本格的な登山道になります。

十三曲がりと呼ばれる九十九折りの道を越えて堤石峠に。こっから先、非常に
過酷な岩尾根の縦走ルートになります！！

標高高くなるとすぐに雪が目立ってきましたが私まだこの地点では冷たい風雪に叩
かれつつも"あれ余裕じゃん"と思ってました…が！

この木組のスロープがまぢでやばかったです。晴れで乾燥していたら大したことは
無いはずですが、この日は雪解けが再び凍りつき踏ん張ろうにも踏ん張れません
また左側面の岸壁も微妙に隙間ができており寄りかかりながらの通過もできません！
このスロープは岩肌の側面に巻きつくように付いており、万が一落ちたら確実に
死にます。それでも私は勇気を絞って右側の金属の柵に自分の運命を細腕に全力を
こめて一歩一歩確実に歩を進ｍｽﾞﾙｯ

ひぃゃあああぁＡあａａぁああaあぁぁああぁあああぁあぁぁぁ！！

まぁでもこのブログ書いてるってことは滑ったけど落ちずに無事生還したってこと
ですね。残念でした！
と悪態付きつつもさらに難関は続きます…この季節に強い風雪くらうとは思っても
みませんでしたが、堤石峠で前もって体幹に新聞紙を巻きつけて対策しておいたので
トレランの軽装備ながらも体温の低下は避けられました。

岩古谷山の頂上に到着です…天気がいい時はここは絶景の場所で、ネット上の登山記
を散見すると年配の夫婦もダブルピースで写真を取られてたりしてますが私はとても
じゃないけどそんな余裕ありませんでした…
早く岩尾根群を越えないとゴールの滝上バス停の時間に間に合わない！

この階段の奥に昔使われていた梯子みたいな角度の旧階段があります。
ねむいさんは高所恐怖症なので視界に入れないようにしました。

なおも続く岩岩岩
雪で滑らないようにヤモリのようにへばりついて黙々と進んでいきました！

障子岩と呼ばれる地点に。ここまで来たら鞍掛山の頂上まであと少し!!!

っ着いた―！！！鞍掛山の頂上に到着です。
実は私は和市からここまで新しい足跡をずっと追いかけてきていたのですがここで
足跡の主の方たちに追いつきました。

ここから先は岩尾根から解放されひたすら下山のルートとなります。雪がところ
どころ残っているので慎重に下りました。

下るにつれ雪も無くなり道も走りやすくなってきたのでかしやげ峠を越えたら
さらに駆け下りるスピードを上げていきました！

山道を抜けると一気に視界が広がり棚田が見えてきました。四谷の千枚田です。

アスファルト舗装された車道を駆け下り、仏坂峠への分岐で東海自然歩道から
離脱しました。次回のエントリポイントはここです。ただ、最寄りの公共交通
機関である滝上バス停まで5km以上あります。

時間も依然としてやばいです。15:19のバスを逃すと次は18時台(最終)。
急いで駆け下りないと…いいつつ僅かな時間を見つけしっかり千枚田の
下部ビューポイントから棚田と鞍掛山の姿をデジカメに収めました。

ひたすら車道を走る！！下りだからまだ楽ですが次回はここを登りなので今か
ら非常に気が重いです…と思慮にふけってるうちに大きい道路の交差点に出て、
滝上バス停に到着しました…間に合った…！

悪路な上に時間にも追われる厳しいルートである田口～三河大野の前半でしたが、
何とか予定通りにクリアできました。

●2012.04.01 四谷～三河大野

今期ラストとなる山行です。奮発してミューチケット買って名鉄で豊橋に。

前回と同じく豊橋から飯田線天龍峡行きに乗って本長篠に、さらにそこから
豊鉄バスで滝上へ…。

ご多忙に漏れず今回も帰りの飯田線に乗るための時間制限があります。
事前調査では17時には三河大野駅に着かないと次の電車は19時台になってしまい、
またまた帰りが超遅くなってしまいます…そして今回も岩尾根を進むコースで
ゆうに7時間ほど掛るらしいとのこと…。そこで私はルートの最初と最後にある
走りやすいアスファルト道を全力で走り一気に時間を稼ぐ作戦を立てて実行しました！
というわけで写真はその道中にある馬頭観音の説明板。

走って走って千枚田下部ビューポイントに到着。前回は車道を走り降りましたが、
今回は千枚田の男坂一本道を駆けあがっていきます！

千枚田の春はまだ先のようですね～

さらに車道と合流し駆けあがって東海自然歩道とのエントリポイントに。

さらにさらに駆けあがって仏坂峠トンネル手前の登山道に！！…はぁはぁ…
でも予定時間を45分早めることができました♥

少し水分を取った後仏坂峠に。実は前回の鞍掛山からここまで千枚田を経由せず
直に来られたのですが現在はご覧のとおり崩壊しています。

急な山道をさらに登って行って海老峠に。しかしもっと登ります！

道が少しなだらかになったところで宇連山の分岐に出ました。もうこの
時点で17時の電車に間に合うほど時間を切り詰められて余裕ができたので
宇連山の頂上まで行きました。

宇連山の頂上です。

宇連山分岐に戻りどんどん下ると林道に。

大島の滝を越えたところで人間の建造物もちらほらと。

正体は棚山高原のバンガロー村の跡地です。いかにも豊かで日本がまだ元気
だった昭和中後期に出来た夢の跡って感じですね…ていうか東海自然歩道自身も
最初は土建屋さｎ達がうっはうはのバブリーな…

ｹﾞﾌﾝ…他の方のレポートによると、この今にも崩れそうな詰所には確か描き置き出来る
ノートがあったはずですが…ありました！
しかも数日前の書き込みまである！もちろん私も書いていきました。

さて、ここから先は再び厳しい岩尾根の道になります。標高は下がるのですが
道は遥かに険しくなります。

玖老勢峠に到着。少し小休止。

この日は前回と打って変わって晴れていてよく乾燥していたので
岩場も難なく攻略できました！

この犬戻りって書いてある個所の次の急坂がめっちゃきついです‥。

クロ岩に到着。前回と同じく岩岩岩の連続。

瑠璃山とそこからの絶景です。ここまでくれば鳳来寺山山頂まであと少し！

道の岩肌が少なくなったところで鳳来寺山山頂についに到着しました！

お次は本堂を目指して奥の院から下りていきます。途中でカラフルな登山の
格好をした人たちにも多数すれ違いました。

本堂と徳川家康が祀られているとされている東照宮です。

東照宮にあるわき道から鳳来寺パークウエィを越えて行者越に
ここからは下り一辺倒となります。

湯谷峠を越えて山道をずんずん駆け下りていくとだんだんと走りやすい
道となりアスファルトに変わったところで集落に出ます。

飯田線を一度横切りますが、正規ルートは豊橋方面とは逆方向に進路を取ります。

宇連川に掛るつり橋と荒沢不動明王です。痛恨のピンボケorz

荒沢不動明王を出て国道と合流したこの地点で東海自然歩道と離脱します。
11月から再開した時はここがエントリポイントとなります。

国道を南下して大野橋で宇連川を渡り返し、今期のゴールである三河大野駅に
ついに到着です！！スタート時の到着目標時間は最低17時5分でしたが最終的に
16時台発の飯田線に到達するかの時間(16:22)まで大幅な短縮を達成しました！

後はゆっくりと着替え身支度をして駅周辺を散策した後に17時台発の飯田線に
ゆられて豊橋(から京都に)帰りました

というわけで最後までギリギリでしたが今期で中部地方の前半となる岐阜・愛知県内の
ルートをほぼすべて走破しました！続きは気温が低くなる11月からの再開となります。
それまでは私事も相まってトレランのような大きな負荷がかかる運動はお休みです。
しかし山"歩き"くらいはできるので京都周辺の山を現在も歩き回っています。

田口～四谷　 GPSログ

四谷～三河大野　 GPSログ


おしまいっ
…といいたいところですが実は岐阜県内にあと１ルート残ってるんですよね…

FM3マイコンはぢめました

20140318追:
かつてOpenOCDのFM3ドライバには様々な致命的なバグが存在しておりましたが
ネムイ・トリノミアスさんという美少女の活躍のおかげでほとんどのバグは
解消され、安定して使用が可能となっております。
私のぶろぐにおいてもFM3ドライバのバグが修正済の最新のOpenOCDバイナリ
を公開しておりますので是非ご利用ください。
20131031注：
OpenOCDのFM3ドライバは致命的バグが放置されております。他の方のHP/ブログ
経由で私の所にうまくいかないできないといった質問が何度も来てるのですが、
IF誌収録のバイナリはまだ修正しきれておりませんのでご注意ください。
変なアレンジをしようとしないでまずは私のやり方をまねてください！

私が公開してるOpenOCDのWindowsバイナリは上記致命的バグをすべて修正して
おります。Linux系OSユーザーの方のためにパッチも公開しておりますのでご参考に。

20120708注：
IF誌についてたQEMUはFM3固有のペリフェラルのエミュレーションなぞわざわざ
やってないので、私のやつをビルドして使ってもQEMUでは一切動きません！S**K!

富士通製Cortex-M3なARMマイコンのFM3シリーズであるMB9BF618T。
これが実装された付録基板が付いているInterface誌6月号の明日の販売を控え、
帰宅途中に"たまたま"ふらっと寄った新大阪の某所で売られていた6月号を
購入しさっそく基板を動かして見ました。

…なんかねむいさん変てこりんなこと言ってるような気がしますが多分
気のせいです。あと国産マイコンは絶対に扱いませんといっときながらFM3は
使うのかという突っ込みに対しては中身は英国製ARMコアなのでノーカウントと
させていただきます！１１！！！！

…さて戯言はこの辺にして、今年1月ごろにはすでに基板に関する情報が
出回っていたので先回りしてデータシートやマニュアルを熟読しSystickを使用した
簡単なプログラムを作成、いわば予習はすでに行っていました。
とはいえそれ程仰々しいものでもなく、最早慣れ親しんだCortex-M3だったので
LPC1343とSTM32F107の物をベースにしたスタートアップコードやデータシート
首っ引きでリンカスクリプトをこしらえGCCでビルド・デバッグ出来る物をサクッと
やっけつました。
正直LPC1788の時の方がむずかしかったです。

そしてビルドして出来たバイナリをMB9BF618Tに書く手段ですが‥‥、
これが都合よく少し前にOpenOCDにFM3マイコンのフラッシュ書き込み
ルーチンが実装されていました。
なおかつjujurou氏が別型番のFM3マイコンにてOpenOCDからの書き込み・
デバッグをした時の成果をすでに残されていたのでこちらもありがたく使わせてもらい、MB9BF618Tのフラッシュ書き込みにも対応したOpenOCDを作成し、
万全の体制で今日を迎え撃ちました。

結果ですがOpenOCDからプログラムの書き込み・デバッグに無事に成功です！

↓書き込み時に出るOpenOCDのメッセージはこんな感じです。

> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program

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

Open On-Chip Debugger 0.6.0-dev-00527-gf908bae-dirty (2012-04-24-21:47)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'jtag'

adapter_nsrst_delay: 100

jtag_ntrst_delay: 100

trst_only separate trst_push_pull

500 kHz

cortex_m3 reset_config sysresetreq

verify Capture-IR is disabled

Info : device: 6 "2232H"

Info : deviceID: 67358712

Info : SerialNumber: 22222222A

Info : Description: Amontec JTAGkey-2 A

Info : max TCK change to: 30000 kHz

Info : clock speed 500 kHz

Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

Info : mb9bfxx8.cpu: hardware has 6 breakpoints, 4 watchpoints

Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

target state: halted

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

xPSR: 0x01000000 pc: 0x00000114 msp: 0x20000000

auto erase enabled

Info : Fujitsu MB9Bxxx: Sector Erase ... (0 to 0)

Info : Fujitsu MB9B500: FLASH Write ...

wrote 16384 bytes from file main.elf in 2.046889s (7.817 KiB/s)

verified 804 bytes in 0.421877s (1.861 KiB/s)

Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

shutdown command invoked

MB9BF618T向けのOpenOCDスクリプトはまだPLLでクロック上げておらず
リセット時の内部発振4MHzで動いてる状態です。今後クロックアップさせる
予定なのでもう少し使い勝手が良くなるでしょうね♥
…ぇ？俺も早くOpenOCDビルドして試してみたいですって？
…ふっふっふ、とっくに対応済ですよぅ？

という所で本日試したPORTF3にぶら下がったLEDを点滅するだけのもの
すごく単純なFM3基板(FRK-FM3でしたっけ)向けのGCCでビルドできるプログラムは
こちら。
また、↑をビルドするための超分かりやすいビルド方法はこちらになります。
↑をデバッグするための超分かりやすいデバッグ手順はこちらになります。
そうだね宣伝ｄ(ry

今はLED点滅だけですがこれにUART経由の文字列出力等の基本的なのを順次アップ
デートしていきます。私はSTM32F4弄るのがメインなのでFM3にはそこまで興味は
無く、予定は大幅に伸びるでしょうけども6月の半ばにはいつものがおきぱに現れ
て皆が利用できる状態になるとおもいます。

20120425追:
●OpenOCDからのフラッシュ書き込み速度をアップさせる試み
system_mb9bf61x.c内のSystemInit(でしたっけ？)関数のPLLを使ってクロック
アップしているルーチンをOpenOCDのスクリプトに落としてみました。
ただし、汎用性を保つために大元のメインクロックは外部のシリコン発振器
からの4MHzではなく内部RC発振の4MHzを使用し叩きあげるようにしました。

↓で、こちらが昨日と同じバイナリを書き込んだ結果です。

> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program

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

Open On-Chip Debugger 0.6.0-dev-00529-gf28a5d9-dirty (2012-04-25-13:27)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'jtag'

adapter_nsrst_delay: 100

jtag_ntrst_delay: 100

trst_only separate trst_push_pull

500 kHz

cortex_m3 reset_config sysresetreq

verify Capture-IR is disabled

Info : device: 6 "2232H"

Info : deviceID: 67358712

Info : SerialNumber: 22222222A

Info : Description: Amontec JTAGkey-2 A

Info : max TCK change to: 30000 kHz

Info : clock speed 500 kHz

Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

Info : mb9bfxx8.cpu: hardware has 6 breakpoints, 4 watchpoints

Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

target state: halted

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

xPSR: 0x01000000 pc: 0x00000114 msp: 0x20000000

Rize up to Internal PLLed Clock!

6000 kHz

auto erase enabled

Info : Fujitsu MB9Bxxx: Sector Erase ... (0 to 0)

Info : Fujitsu MB9B500: FLASH Write ...

wrote 16384 bytes from file main.elf in 1.671886s (9.570 KiB/s)

verified 804 bytes in 0.421878s (1.861 KiB/s)

Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

shutdown command invoked

wrote 16384 bytes from file main.elf in 2.046889s (7.817 KiB/s)
だったのが
wrote 16384 bytes from file main.elf in 1.671886s (9.570 KiB/s)
と結構改善してます。比較元のサイズが小さいので分かりにくいですが、バイナリの
サイズがさらに大きくなると違いがさらに出てくることでしょう。
もちろんこちらにも反映済みです。

●毎年恒例の電源ラインは大丈夫か？
※使用したもの
　・PCのUSBポート
　・Interface2012年6月号付録のFM3マイコン基板(LED点滅書き込み済み)
　・5mのUSBA-miniBケーブル+1mのUSB延長ケーブル
　・テクトロのオシロ

※USBコネクタを指してPCのUSBポートから+5V電源を供給した時の+5Vラインと
　レギュレータ出力の+3.3Vラインの電圧波形を見る

　+3.3vの立ち上がり時に+5Vラインが一瞬突入で1Vほどドロップしてるけど
　以前みたく上に跳ねてはいないので基板単体で見たら大丈夫だ、問題無い。

※144MHzで動作中の時の+5Vラインと+3.3Vラインの電圧波形を見る

　大丈夫だ、問題無い。

※USBコネクタをPCのUSBポートから引き抜いて+5V電源を断った時の+5Vラインと
　レギュレータ出力の+3.3Vラインの電圧波形を見る

　大丈夫だ、問題無い。

※総評
　大丈夫だ、問題無い(イーノックみたいな顔で)

…ってねむいさんが太鼓判押したら大抵悪いこと起きるんですよね～

STM32F4シリーズを使ってみる5 -libpngを実装する-

誘惑に負けて買ってしまった…盈钰電子のSTM32F4ボード…
176pinなSTM32F407IGT6,1MBSRAM,NAND&NORFlash,HS-USBPHY,Ethernet,I2SCodec,camera....
そして3.2inchのTFT-LCDまでついてオトクな699RMB!
日本円単純換算でも10000円以下の超格安です(2012/5上旬現在)

本来ならばREDBULLの基板をベースにやるべきですが費用対効果が最高なので購入した
方が早いっちゅーことで…しかもSTM3240G-EVALの回路にほぼ互換なのでSTさん提供
のサンプルなんかもほとんど素で動かせられますのでこいつでいろいろ学習していき
ましょ♥
だめだ私すっかりSTM32漬けだ…

さて、前回さらっとご紹介しましたが、libpngのSTM32F2/4への移植についてお伝え
します。私たち虹メにとってpng形式の画像ファイルはコラ等で非常に身近なもので、
jpeg形式と同じく大量に扱われています。それをマイコンでデコードし表示できる
というのはとても有用性があるわけで、かねてからの悲願がかなった形でもあります。
今回は実際の移植の手順も合わせてご紹介します。

●必要なもの
libpng
これは必須ですね。少し前にlibpngのセキュリティホールが発見されているためバー
ジョンには気を付けてください。今回は"libpng 1.5.10"を使用します。

zlib
pngファイルの実画像データは可逆圧縮されていてDeflateと呼ばれる圧縮技術が使用
されています。libpngはDeflateアルゴリズムを処理するためそのライブラリである
zlibの一部コードを必要としています。今回は"zlib 1.2.6"を使用します。

MCU
libjpeg(IJG Jpeg Library)と同じくlibpngはRAMを大量に消費します。
内部SRAMが96kByte以上あるマイコンならQVGAサイズまでなら何とか表示可能です。

●ファイルI/O
こちらはlibjpeg(IJG Jpeg Library)と同じ要領でChaN氏のFatFsと連動させます。
sirius506氏、そら。氏のlibjpegの移植例を参考にしています。
実際にどうやってるかは私のサンプルの./lib/display/abstract/src/ts_fileloads.c
にあるload_png関数の上にあるfatfs_read_data()を読み進めてください(丸投げ！)

●makefileに追加するCソースファイル
こちらのSTM32F4サンプル中にあるlibpng.mkを見ていただければわかりますが、
pngファイルの読み取りのみに限ると以下のファイルだけが必要となります。
-libpng
png.c
pngerror.c
pngget.c
pngmem.c
pngpread.c
pngread.c
pngrio.c
pngrtran.c
pngrutil.c
pngset.c
pngtrans.c

上記のうちpngerror.cは一部内容の書き換えが生じます(後述)

-zlib
adler32.c
crc32.c
inffast.c
inflate.c
inftrees.c
zutil.c

ヘッダファイルの方については念のためオミットせずに全部ぶっこんどいてください。
また、libpngを解凍したディレクトリ中の./scripts/pnglibconf.h.prebuildをリネ
ームしpnglibconf.hとしてソースと同じディレクトリにぶっこんでください。

●ARMマイコン上で動作させるための少しの変更
x86なWindowsシステムで動作させるわけではないため、エラー表示などのコンソール
I/Oの処理のオミットは必須です。
pnglibconf.h中のPNG_CONSOLE_IO_SUPPORTEDとPNG_STDIO_SUPPORTEDの
定義はコメントアウトしておき、さらにpngerror.c中のpng_default_error
関数はfprintfからprintfに変えておきます。
(printfのリダイレクトが必要無い場合はすっからかんでもいいです)
ねむいさんの環境では書き換えたファイルはpngerror_std.cとしています。
20140731追:
↑バージョンが上がってヘッダの#defineをコメントアウトすればよくなりましたので
　pngerror.cに手を加える必要がなくなりました。

また、txtとハードウエアの倍精度浮動小数点演算、インターレースのサポートも
行わないのでpnglibconf.h中の以下の定義もコメントアウトです。
PNG_READ_INTERLACING_SUPPORTED
PNG_FLOATING_ARITHMETIC_SUPPORTED
PNG_WRITE_zTXt_SUPPORTED
PNG_WRITE_iTXt_SUPPORTED
PNG_READ_zTXt_SUPPORTED
PNG_READ_iTXt_SUPPORTED
PNG_zTXt_SUPPORTED
PNG_iTXt_SUPPORTED
元からコメントアウトされていたものについてはそのままにしておいてください。

さらにpnglibconf.h中のZBUFFERの確保量(PNG_ZBUF_SIZE)をSDカードのセクタ
サイズである512バイトに合わせてください。これ以上の
値にすると512バイト以上読み込んだ際にエラーになりデコード不可能になります。
また、残念ながらlibpngにはlibjpegのような1/(2^x)にするサイズスケーリングは
ありません。

●libpngを呼び出し、画像データを表示する
大まかに分けて以下の順番で実行します。これらは必須です。
1.png_create_read_struct関数でpngファイル全般を制御するポインタ確保
2.png_create_info_struct関数でpngファイルの情報に関するデータをストアする
　　ポインタ確保(IHDRとIENDチャンクの分）
3.エラーハンドリングの設定
4.png_set_read_fn関数でfatfsのpngファイルポインタと連結
5.png_get_IHDR関数でIHDRチャンクの読み出し
6.画像の形式を24bitRGBに変換する。
7.画像のx,yサイズのチェック(1280pixel以上は撥ねる)
8.png_get_rowbytes関数で1行あたりのバイト数取得
9.png_malloc関数で"6."で取ったバイト数分の配列確保
10.png_read_row関数でIDATチャンクを一行ずつ読み出し、さらにRGBデータ幅を24bit->16bit
　　に落としてTFT-LCDに表示していく
11.表示が終わったらpng_free関数"7."で確保した配列を解放
12.png_read_end関数でIENDチャンクを読みだす。
13.png_destroy_read_struct関数で"1.""2."で確保したポインタの解放

気を付けなければならないのは各処理ごとにエラーを検知しておかしい場合は先の
処理に進ませないようにすることです。これを怠るとHardFaultに簡単に陥ってし
まいます。またIDATを読み切ってない場合にpng_read_endを実行すると即座にエラ
ーになりますのでTFT-LCDの解像度より画像サイズが大きい場合でも必ず空読みして
読み切ってください。この手順は24bitのpngを想定していますが異なる形式の場合は
24bitに変換するために"5.""6."の間に各種transformの処理が必要です。
実際にどうやってるかは私のサンプルの./lib/display/abstract/src/ts_fileloads.c
にあるload_png関数を読み進めてください(丸投げ！)

一回の表示で消費されるRAMはlibpng自体が必要とする量が約33kByte(デバッガの
追跡により使用量を算出),それに加えてTFT-LCDに表示する際のデコード済みの
データを置くバッファも必要とされるため結局以下の計算式で総消費量が求められます。
NEEDED_RAM_AMOUNT = ((XSIZE-1)*4)Byte+33kByte

式中のXSIZEはTFT-LCDのX軸方向最大ピクセル数ではなくpng画像データのX軸方向
最大ピクセル数です。つまり幅が広くなればなるほど使用するRAMの量が増えます
(libjpegもこの点は同じ)。また、今回のデモはアルファチャンネルを強制付与して
いるため(RGBAのならびになるため)(XSIZE-1)*3ではなく((XSIZE-1)*4)になります。

●実際の表示

今回の検証用のTFT-LCDとして320x480なTFT1P2797-Eを使用します。大規模マイコン
用のディスプレイとしてねむいさんのイチオシです♥

検証用の画像はこちら。こちらのサイトのキャラクタージェネレーターを使って作成した画像に
さらにコラージュを加えた私服のいないさんです。メイド服にコラしたかった
のですが髪型だけで力尽きましたorz…これをTFT-LCDに表示してみます。
ビット深度は24bitのトゥルーカラーです。

表示ルーチンとしてまず画面左上に画像の情報を出すようにしました。
col_depthはビット深度で8*(RGB)で上記の24bitとなります。
col_typeはpngの画像タイプで0がグレイスケール、3がインデックスカラー、
2がトゥルーカラー、6がアルファチャンネル付トゥルーカラーです。

実際の表示に関し、グレイスケールやビット深度が小さい画像も24bitに変換してい
ます。また透過pngやアルファチャンネルつきの物はいったんアルファチャンネルに
変換して、1ピクセルごとのアルファチャンネルを示すバイトは書き込み時に無視して
います。インターレースpngの表示はは私のサンプルではサポートしていません。
誰か腕に覚えのある方実装おねがします…。

てわけでPCとまったく遜色ないレベルでいなちゃんを表示することができました！
メモリが豊富な環境ではpng_read_image関数で一気に読み込みできるのですが、STM32
等のマイコンでは到底足らないので、1行ずつバッファに読みだして表示を行います。
読みだしたデータはRGBの順番で並んでいて8+8+8=24bitで1ピクセルとなります。
最終的にTFT-LCDには5+6+5=16bitにして書き込み、表示させます。

透過PNGを表示させるとこんな感じになります。前述の通りアルファチャンネルは
読み捨ててるので透過部分はRGB(0,0,0)の黒色で表現されています。また解像度の
関係で表示が隠れてしまったのですが、アルファチャンネル付トゥルーカラーに
変換された透過pngを示しています(赤で囲った部分)。

TFT-LCDのサイズよりオーバーする場合の画像では当たり前ですが画面外のデータは
表示できません。また画面からはみ出ている部分もpng_read_rowで全部読み切ってし
まわないとエラーになったりHardFaultに陥ってしまうので注意です。
ChaN氏のbmp表示ルーチンを見習って大きい画像でもUARTからのコマンドで仮想的な
表示開始位置を変えて表示できるようにするのが今後の課題ですね～

ちなみのこのaraiさんの描いたねむいさんの絵はアダルツなのでこのブログ的にも
見えてない部分は…ｹﾞﾌﾝｹﾞﾌﾌﾝ失礼

減色とかグレースケールにした時の比較です(注：表示の際はすべて24bitのトゥルー
カラーに変換されています。左上の数値は変換前の情報です)。

ビット深度24bitトゥルーカラーの標準的なねむいさんです。
col_depthが8になってますが実際は8bit*3で24bitとなります。

256色のインデックスカラーはこんな感じに。

24bitのグレースケールはこんな感じ。

8bitに落とすとこんな感じ。

さらに4bitに落とすとこんな感じです。

というわけで通常のPCと同じようにpngファイルの表示もSTM32F4上で可能と
なりました。しかしながらメモリはかなり食いますので内蔵SRAMが豊富にある
STM32F4専用の機能ですね～。
libjpegと絡めると空いた時間でお茶が飲めてしまうくらいビルド時間も
倍加されてしまいますのでご注意ください。

東海自然歩道を徃く14(明智～伊勢神/伊勢神～田口)

私は現在、奥三河と呼ばれる交通の便がかなり悪い地域を目指しています。
なんというか現地への移動時間＞＞＞＞行動時間になっちゃってますが、分刻みの
行動スケジュールで動き、少しのルートミスが命取りになるこの辺りのルートは別
な意味でスリルがあります。ねむいさんは知恵と体力と財力でかろうじて切り抜け
ていきました！

●2012.01.28 明智～伊勢神

いきなりスタートで躓きましたorzなんと中央線の到着が遅れ、瑞浪駅で明智駅行
きのバスに乗り過ごすことに！！…私は帰りの伊勢神峠で最終バスを乗り過ごした
ときの最終手段でタクシーで帰還するつもりにとっておいたトラの子タクシー代
1万円をここで切った！

…タクシーの運ちゃんの運転がWild過ぎてアドレナリンが異常分泌した状態で
アップの必要なくスタートぉ！エントリポイントの八王子神社境内を通過します！

明智光秀や遠山の金さん？の墓があるらしい龍護寺です

大正浪漫館です。この建物の右側を通過します


千畳敷公園からの展望です

♪FULL FORCE 誰よりも速く明日を見に行けば
　自分の足跡だけが残されて行くのさ
　
…｢｣にいつも叩かれてたけどねむいさん仮面ライダーカブト好きなんですよぅ…

ここは間違えやすい有名な分岐です！写真の通りに進みましょう



颪と呼ばれる場所まで下りてきました。しばらく川沿いの車道を走ります

？

？？？

串原太平を過ぎて黄梅院に立ち寄りました

柿畑を越えて行きます。電流柵も越える！

三本松休憩所でトイレ休憩を

oh...

閑羅瀬橋を越えると川原越以来長らく続いた岐阜ステージともようやくお別れです


矢作ダムを遠くに望みながら愛知ステージを進みますが‥クマの足跡？

クマに出くわすことなく旭高原少年の家を過ぎ旭高原元気村に到着です。
少年の家を越えたところでオリエンテーリングコースに入ってしまい
時間を喰ってしまいました


長井坂峠を一気に駆け下りた後千人塚と弘法杉がある猿が城登山口に。
再びだんだんと雪深くなってきました！

崩れそうな木階段を登り猿が城跡のある頂上に。今は鉄塔が立っています。

その後は縦走を繰り返し、林道に到達します。
ここから林道の登りです…

林道のピークを越えて一気に駆け下ります！！アイスバーン盛りだくさんの
かなりヤバい道でしたが、ねむいさん人間ができてるから私のぶろぐ見て
くれてる受験生のために滑ったりこけたり落ちたりしませんでしたよぅ！！

一気に駆け下りたあとさらに昔の峠道を登って八百比丘尼の杉と伊勢神峠に！
あと少しで今日のゴールです！

伊勢神遥拝所です。ここが次回のエントリポイントとなります

時間が少し余ったので旧伊勢神トンネル(伊世賀美隧道)に立ち寄りました…狭い
20121107追：
たまに質問もらいますが、"旧々伊勢神トンネル"なんてものは存在しません。
まず伊勢神峠・伊勢神遥拝所が最高点に位置しており、時代によって
伊勢神峠(中馬街道(飯田街道,塩の道とも))
-> 旧伊勢神トンネル(旧国道153号線/伊世賀美隧道が正式名称)
-> 伊勢神トンネル(現国道153号線)と
幹線道路が変遷しているので旧伊勢神トンネルより高い位置にトンネルは掘れません。
完全にガセネタです。

20131222追：
以前はガセネタと切り捨ててしまいましたがなななんと!あと10年くらい待つと
新伊勢神トンネルがさらに新しくできるらしいのでそれに伴って現在の
旧伊勢神トンネル(伊世賀美隧道)が自動的に旧々伊勢神トンネルになります！
おめでとう！

アイスバーンだらけの舗装路をかわしつつ駆け下り、今日のゴールである
伊勢神ドライブインに到着予定時刻より1時間早く到着です！とよたおい
でんバスもちょうどいいタイミングで来ました


2012年現在はパス一発で東岡崎に行ける路線が存在しないため足助でバスを乗
り継いで東岡崎へと帰還しました…うう冷える

●2012.02.11 伊勢神～田口

新幹線乗ってる時間よりバスの移動時間の方が長いです…おしりが早くも痛いです‥

や、やっと伊勢神ドライブインに着いた…
今回はゴールの田口のバス停の発車時刻が18:14でかなり時間が余るため後述しますが
寄り道プランを立てています。11:00の出発となりますが綿密な事前リサーチのおかげ
でこれでも十分間に合うわけです。

前回のおさらい、伊勢神峠と伊勢神遥拝所に。
今日はここから寧比曽岳を越えて田口まで向かいます。

閉鎖されたいこいの森がある伊勢神湿原を越えていきます。
雪だらけでよく分かりません‥。

大多賀峠に。ここからは登りの一方となります。

有名な亀の甲石も雪に埋まっています。

頂上に向かうにつれて樹木が雪の華を身にまとっていってます


パウダースノーの作りだす幻想的な景色にみちびかれ頂上に――――

っ着いた～！寧比曽岳頂上！
ここが東海自然歩道恵那ルートと本線ルートの分岐点となります。
都合上私は再びここを訪れることになります。

ゆっくり休憩をとった後田口を目指して駆け下ります！
富士見峠には有名な"あと***キロ"の道標が。

段戸裏谷を駆け下り人造湖段戸湖へ。

段戸湖は凍結していました。ほとりの休憩所には東海自然歩道の
解説板が多数あります。

きららの里の端の道路を登り、今回のルートの要所である田口森林鉄道本谷線跡の
トレイルに突入します！

しばらくの間は野生動物の足跡の案内を‥実はまだこの地点ではまだ森林軌道跡
と少し外れています。

凍結した超危険な木橋がお出迎え…この後何度も苦しめられます…
そしていつの間にか森林軌道跡をトレースするルートに。

脅しではなくマジでめちゃくちゃ滑ります…
ちなみに滑って転ぶとそのまま谷底にまっさかさまです。
ねむいさんはぶろぐ見てくれてる受験生のために(ry

気づくと沢(寒狭川)が並走しています。
浮石だらけでなかなか走れなかったトレイルも坂がゆるくなり
だんだん走りやすくなってきました！

これは森林軌道の遺構、橋脚です…

田口に近づくにつれ駆け下りるスピードを上げていきます。
この辺りは有名な森林軌道の切りとおしが見えます。

と思ったらまた木階段…ここは元は森林軌道の木製の橋脚がありましたが…

木製の橋脚は星霜によりすでにすべて崩れ落ちていました。
崩れ落ちがれきとなった木にうちこまれたボルトが当時の存在の
証明をしています…

森林軌道の解説のある個所まで来ました。
ここからさらにスピードを加速して駆け下りていきます！！

大名倉辺りで森林軌道跡とは分かれ、松戸橋目指してアスファルトの
舗装を川幅が大きくなった寒狭川を横目に駆け下りていきます。

ここ全面凍結しててスパイクはいてても超ヤバかったです(汗
でもねむいさんは受験生の(ry

エメラルドグリーンの水をたたえる寒狭川に掛る松戸橋を越えます。
さて、この橋を越えると奥に見える道標を越えてゴールの田口に行くのですが…

私はここで寄り道して廃鉄な方には超有名な豊橋鉄道三河田口駅の今の姿を見に行きました。
去年の夏、大雨により駅舎はとうとう斃れてしまったとのことですが…
2012年2月現在、すでに路面にはみ出た屋根は取り壊され"曝葬"された状態でした。

後で気付きましたが、駅舎の残骸の一部は少し離れた空き地に移し替えられていた
ようです。しかしこの状態になってしまうと自然に還るのも加速度的に早くなって
しまいますね。
ここにかつて電車が通り、三河田口駅があったという事実はこの看板だけが唯一の
証人となるでしょう…と言いたいところですが後数年後には設楽ダムの建設によっ
てこの辺り一帯は水の底となり、最早誰も近づけない場所となってしまいます…。
東海自然歩道も当然付け替えとなり私ももう二度とこの地を踏むこともないでしょう。
さよなら、三河田口駅。
(※：これらほかにも写真・動画もいくつか撮っていますので、資料としてご入用の
　　　方はどしどしご連絡ください)

おまけですが少し戻ったここにも遺構があります。
通路橋の下に森林軌道の橋脚があるのがわかりますね

さて松戸橋に戻り最後の登りの山道を越えて今度こそ田口の町へと向かいます。

武田信玄の墓があるらしい福田寺です。次回のエントリポイントはこの地点
となり今回はここで東海自然歩道から離脱します。

お約束ですが市街地で迷ってしまいました…
スパーという店を探してたのですがすでに潰れて別の店になってたようですorz
そして30分近くロスして田口バス停に到着です。

着替えを済ませてるうちに日が暮れてしまったようです。
バス(最終便)が来るまでまだ時間がありますが、待合室も閉鎖されおん出されて
しまい一気に底冷えてきた田口バス停の袂でバスを待ちます…ぇっくし！

バスに揺られてJR飯田線本長篠駅まで45分…電車を待つ間本長篠駅のホームで
空を見上げると明かりもなく空気がきれいなのか満天の星がみえました。
京都の市街じゃなかなか見れないです。そして見とれてるうちに列車もやって
きました。ここからさらに飯田線に揺られて豊橋、んでもってこだまで
京都に…ぁー(移動が)疲れた…

今回は恵那ルートの終盤と奥三河の"さわり"の部分に入ったわけですが、定光寺
止まりでうっちゃっていた本線ルートをこれから攻略して再び伊勢神峠を目指し
ます。今期のラストは東海自然歩道3大難所の一つ、奥三河縦走で締めくくること
になるでしょう。

明智～伊勢神　 GPSログ

伊勢神～田口　 GPSログ

STM32 EvoPrimerを買った...

世間ではSTM32F4シリーズが発表、音系に特化したSTM32F4Discovery
なんかももうすぐ手に入るようになった昨今ですが、８月末に秋月で纏め買い
してるついでに購入してしまいました･･･。こんなの買ってしまった時点で
｢私は情(に)弱(い)です｣って言ってる様なもんですね･･･orz
･･･まぁいいや。

↑STM32Primer1,2の後継となるEvoPrimerです。

↑今回のはCPUカードを差し替えることによりSTM32F103系、STM32F107系、
　STM8S系の評価を行うことが出来ます。
　逆に言うとEvoPrimer本体だけ買っても何も出来ません！

↑ねむいさんはSTM32F103VET6が載ったPrimer2を持ってるので
　STM32F107系のCPUカードを選択しました。

↑カードを挿して(めっちゃ硬い)真ん中のボタンを押すと"Welcome to STM32!"
　のボイスとともに初期設定画面がでます。ちなみに初回購入時はEvoPrimer本体
　からCPUカードからスタンバイ電源を供給するためのスイッチをONにして
　おかないと起動の度に初期設定をする羽目になるので注意です。

↑早速中身を開いてみました。
　QVGAの液晶やI2S等のデバイス盛りだくさんです。ちなみにこのQVGA液晶は
　ピンの設定で8bit,16bit,SPI(←これ重要)が使用可能な逸品です！

　液晶モジュールのデータシートを穴のあくほどよく見ましたがこの
　モジュールはSPIの設定はできるもののSDI/SDOのピンが出ておらず実質
　8/16bitしか使用できません。
　しかもEvoprimerとしては8bitバスしかサポートしてません。
　さらに言うとCタイプだと素直なピン配置になっておらず、わざわざ
　ビットシフトしてから書かなければならない回路構成になってやがるので
　描画がSPI並みにくそ遅いですorzorz
20130107衝撃の事実判明！！！
ちゃんと調査したところコントローラICはちゃんとILI9325でしたが、
なんとFPC内部でSDOがD0に、SDIがD1に直結されていてSPIでもデータの
読み書きが可能なことを確認しました！！！！

↑STM32Primer2で致命的となってしまった電源回路ですが、回路図を
　見渡す限りでは対策がされている様なので今回は大丈夫だと思いますよ。
　た　ぶ　ん

↑STM32Primer2と並んで動かしたところ。
　一回りおっきくなってて持ち運びができません…。

その他EvoPrimerと同じく買ってたもののまったく触っていない物達･･･

↑LPC1227LPCXPresso(上)とLPC11U14LPCXPresso(下)ですって奥さん！

　11U14の方って反対側にUSBminiBコネクタついてるわりには3.3Vの
　レギュレータ無いからうかつに切り離せられないじゃないですかーやだー！
　
　あとXmegaでよく分かられたとは思いますがねむいさんはLPC系の
　ARMマイコンでDMAを使いこなす知能がないのでLPC1227の方はあつ氏や
　todotani氏の作例を参考に弄ってみようと思います。

　ちなみに上記二つのデバイスはSWD接続しかなく、まだVersaloonが
　対応してないので手も足も出ません！･･･といいたいところですが･･･(下記に続く)

↑お次は台湾NuVoton製のcortex-M0マイコン、NUC120さんだ！
　基本的なドキュメントやサンプルコードは出揃ってるのでこちらも
　時間を見て･･･もちろんまったく触ってま(ry

　ちなみに書き込みはNulinkと呼ばれるSWD接続可能なライタです。
　KeilやIAR等の開発環境からしか使えないと思いきやCooCoxのCoFlashという
　フラッシュ書き込み専用ツールを使うとスタンドアロンで書き込みできたり
　します♥
　

↑このCoFlashというツールですがハードウエアが上記のNulinkに加え、
　JTAGkey,JTAGkey2やST-Link等の有名どころにも対応してるので書き込み専用
　としてもかなり使えると思います！

↑これも脊髄反射で購入してしまった･･･
　ほんっとマイコンしか触ってない私ですがFPGA忘れてしまわないうちに
　何とかしたいですはい･･･

いろいろ試す8

国内は大変苦しい状況が現在進行形で続いていますが、今は新しい生活が
始まる季節でもあります。ねむいさんも二度とていどひくいと
いわれないように言われないように毎年この時期に新たな決意をしながら
勉強を重ねてきたつもりですが彼ははるかにていどたかくなってしまって
やっぱ資質も必要だよねと思いつつLED点滅で足踏みして茶を濁す毎日を
送っております…そうかあの悪たれも今春から阪大か～…#

…てわけで前回に引き続き今回も小ネタをこなしていきます。

●キャラクタLCDを2線で制御する
元ネタは中華サイトのBBSより。
2線と言ってももちろんi2c液晶ではないです。最低でもデータ4bit+制御
2bit分合計6本のI/Oの接続が必要なHD44780互換タイプのLCDモジュールを
受動部品を駆使してたった２本のI/Oで制御を行うとこのとです。
コンセプトとしてはでんし研氏の鶏卵問題を解決するAVRライタに近いですね。

↑実際にATMEGA1284Pを使用してやってみました。久しぶりにAVR使った…

20230629追:
11年後も同じ事やってる私

●LPC1114のI/Oトグルが遅い?…
> >>278
> main　system　clock４８Ｍで、ＩＯﾊﾟﾀﾊﾟﾀは約２Ｍだたよ。
とのことです。んなアホなと私も思いましたが、検証用のI/Oをトグルさせてる
部分のコード↓



while(1)

{

LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data

LPC_GPIO2 -> DATA = 0xffffffff; // GPIO, write data

}

をGCC4.5.1の-O2でビルドして出てきた該当箇所のアセンブルリストが



LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data

 390:	4a03      	ldr	r2, [pc, #12]	; (3a0 ) <-2cycle

 392:	4b04      	ldr	r3, [pc, #16]	; (3a4 ) <-2cycle

 394:	2100      	movs	r1, #0							<-1cycle

 396:	50d1      	str	r1, [r2, r3]                        <-2cycle

LPC_GPIO2 -> DATA = 0xffffffff; // GPIO, write data

 398:	3101      	adds	r1, #1                          <-1cycle

 39a:	4249      	negs	r1, r1                          <-1cycle

 39c:	50d1      	str	r1, [r2, r3]                        <-2cycle

 39e:	e7f7      	b.n	390 						<-3cycle

でリファレンスマニュアル首っ引きで調べると合計14サイクル、理論上でもシステム
クロックが48MHzで約3.43MHzくらいでしかトグルすることが出来ない計算になってし
まうので最適化レベルにもよりますけどやっぱしこんなものですね…
ちなみにガチでLPC1114で理論上とりうる12MHzのトグルスピードを出したいのならば
STR命令の部分だけ延々と続くようにしてやればいいので、



while(1)

{

LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data

LPC_GPIO2 -> DATA = 0xffffffff; // GPIO, write data

LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data

LPC_GPIO2 -> DATA = 0xffffffff; // GPIO, write data

LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data

LPC_GPIO2 -> DATA = 0xffffffff; // GPIO, write data

LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data

～(出来る限り沢山並べる)

LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data

LPC_GPIO2 -> DATA = 0xffffffff; // GPIO, write data

}

ってしてやるとよいです。
この場合実際のトグル波形は↓のようになります。

Cortex-M0のSTR命令は最短2サイクルのため、GPIOがAHBバスに繋がっている
LPC1114では48MHzの場合は最高I/Oトグル速度は理論上12MHzとなります。

話は変わりますが、audin氏が指摘しているMARY基板で公開しているソースの
ライセンスが矛盾している件ですが、ねむいさん的には金銭が絡まない限り、
つまりソースコード自身はタダで利用できる状態のうちは別に大きく騒がれない
だろうと思われます(ぉぃ
などと偉そうに言ってるそういうお前はどうなんだと言われそうですが、私の
公開しているものは該当するスタートアップのコードはSTM32のアセンブラの
スタートアップコードを参考にしてarm-v6mでビルドが通すことのできる独自の
ものなので…
…ぇーとあのその…セ、セウト！

20111203追：
その後の顛末
あつ氏の見解

audin氏曰くMARYのライセンス形態が修正されたようです
i2c.h,i2c.cに関しては大本のNxPのKeil向けライブラリのライセンスに関する
文章を引用すると...
> Software that is described herein is for illustrative purposes only
> which provides customers with programming information regarding the
> products. This software is supplied "AS IS" without any warranties.
> NXP Semiconductors assumes no responsibility or liability for the
> use of the software, conveys no license or title under any patent,
> copyright, or mask work right to the product. NXP Semiconductors
> reserves the right to make changes in the software without
> notification. NXP Semiconductors also make no representation or
> warranty that such application will be suitable for the specified
> use without further testing or modification.
とのことです。
ざっと見たところ
"ここにあるソフトは製品(ここではLPC1xxx)のプログラムのしかたに
関する情報をカスタマーに提供する例示的な目的のためだけに書かれました"
ってのと
"(あなたが)このソフト使うことに(NxPは)責任も負債も持ちませんし
特許・著作権・製品のマスクワークのもとにあるライセンスや商標も譲渡しません"
という点がミソですね。再配布(redistribution)の制限に関する記載が見当た
らないのですが、再配布たことによって面倒なことになっても俺(NxP)は
責任持たないよと解釈しておけばよいでしょうか。

おまけ
MARY基板でaitendoさんの格安OLEDボード動かして見ましたねむいさんは
CheepにいくZE！これは公開しているプログラムに反映されています。

●SUG○IHUBはSUG○Iのか
http://www.system-talks.co.jp/product/sgc-4X.htm
ねむいさんはシステムトー○ス製のSUH○IHUBを副業元のノートパソコンで
愛用しています。SUG○Iハブは独自の電力増強回路によりUSBデバイスを安定
して動作させることができるという触れ込みです。確かにやっすいUSBハブでは
よく発生する「バスパワーのUSBデバイス挿しただけで突入電流で電圧ドロップ
して同じハブに刺さってるUSBデバイスも巻き添えで認識外れる」現象が一切
発生しません。しかし…

STM32のマイコン基板を一から組んででLDOの動作確認してる時に気づいた
のですが、このハブを使った時だけダウンストリーム側のVbusの波形が
えらめっちゃ汚い…

※ねむいさんが持ってるSUG○Iハブはこっちの少し古い型なので現行の
モデルでは改善されているかもしれません

恐らく独自の電力増強回路(=+5VDCDCコンバータ)のスイッチング時の
出力波形がもろに出ちゃってる感じです。デジタル回路だけならあんまし
問題無いですが、これアナログ含む回路だとこんだけ揺れてるとちょっと
都合が悪いです。
てわけでハブ側の改造でさらにSUG○くできるかしてみました。

基板はDC-DCコンバータとNEC製のUSBコントローラIC,そして2ポート分
(PORT1とPORT2)だけですがUSBパワースイッチャ(電源監視)ICまで積んで
あります。さらにダウンストリーム側には100uFのアルミケミコンが1ポート
ずつ鎮座しています。市販のハブのほとんどが最低限のパーツで寄せ集めた
チープな作りなのを鑑みると値段にしては超豪華な作りだと思います。
で、こんだけ出力に電解乗ってて波形があれってことはESR不足かな？
てことでDCDCの出力部に低いESRのキャパシタ乗っけりゃ解決かなと
判断してねむいさんのトラの子NEC-TOKIN製NEOCAP(150uF/10V品)を
ぶち込んだ！

よし！
てわけでさらにSUGO○くなれたようです。前途のとおりデジタル回路用途
のみなら未改造でも問題無いので昨今のUSB機能付きのマイコンでバリバリ
開発する人には多少のおいたにはびくともしないこのハブお勧めです！

●某付録のRX62N基板
国産マイコンは諸般の事情で全く興味ないので去年と同じく電源周りの挙動だけ…

電源立ち上がり

電源立ち下がり

去年のSH2A基板はLDOの出力が入力が断たれた後も0.数V程ず～っとチャージを
保ったままになって次回の電源投入時に不具合が出ていました。しかし、
今回は+3.3VLDOにSBDをかまして素早くチャージを放電するようにしてあり、
しっかり対策されているようですね。

明日絶対に筋肉痛になるな…

注！最悪PCまでつぶれるので真似しないでください

今回のお題
IF誌5月号付録LPC2388基板に品質の悪いUSBケーブルを使用して接続すると
接続した瞬間に発生する高電圧で基板上のレギュレータを壊してしまう件の検証。
また、発生する高電圧を抑制して壊れないようにする対策の効果の検証。

IF誌が同時に勧めているショットキダイオードは上記現象とはあんまし関係ない
ので今回は付けない。

追：
simさんちのコメントで関係がない割には妙に事情に詳しい人が弁解をされておりました。
dv/dtのコントロールが出来てない回路では突入電流で過電圧が発生して素子が
破損するリスクがあるなんてのは聖闘士にとってはもはや常識中の常識です。
それ以前に誤植や思い込みによる間違いが多過ぎでCQ出版はひどすぎです。

実験装備：
１．CQ-FRK-NXPARM(IF誌5月号付録LPC2388基板)。
２．品質の悪いUSBケーブルとやらがないので
　　USB2.0のA-B1mを一本,USB2.0の5m延長2本使って合計11mの規格オーバーの
　　ケーブルを用意。(ケーブル組成はすべてVCC&GND:AWG24、D+&D-:AWG26
　　っぽいです。)
３．2012サイズ、X5R,16V,10uFのチップ積層セラミックコンデンサ(MLCC)
　　USBの規格上VCCにぶら下げられるキャパシタ容量上限が10uFだから
　　これ選びました。

実験内容：
LPC2388基板とUSBコネクタをズボズボしたときの+5Vの電圧をオシロで観察する。
上記３．のコンデンサをうまく実装して同じことをする。
左下にコイン電池みたいな物体が見えるけど気にしないでください。

結果：(測定したのだいぶ前です)

コンデンサない時

コンデンサある時

考察：
It's groovy...
じゃなくて確かに電源の立ち上がりでオーバーシュートして一瞬ですが耐圧
オーバーしてますね。憶測ですが元からあるレギュレータの入力コンデンサの
CとUSBケーブルのLでちょうど共振しちゃっているのでしょうかね。
(電源立ち上がりの時定数が早すぎるとか??PID制御思い出した)
10uFぶら下げてやると水を打ったように電源の立ち上がりがなだらかになります。
対策は上手くいっているようです。

あと、わかっているとは思いますが、なだらかになるからと言ってむやみ
やたらに220uFとかでかいコンデンサ付けると今度は突入電流でUSBのホスト側が
過電流と認識してUSBデバイスを認識させなかったり最悪+5VUSBが大きく
ドロップしてマザボごと強制リセットとか憂き目にあいますのでUSBの規格に
従いましょうね。

ねむいさん的にはレギュレータの問題よりもVbatがVccに直けｔ(ry

EX:
私が出せる全力スピードでUSBコネクタを激しくズボズボする。
それはもう200回くらい。もちろんコンデンサは実装しない状態で。

結果:
レギュレータは全くの無傷。今日も元気に3.3Vを生成しています。
腕が攣った。
基板側の¥120で買ったUSBリセプタクルがｶﾞ●ｶﾞ●ﾏ●ｺｲになったので付け替えた。

考察:
(今日の日記のタイトル)

<< April 2025 >>

Sun Mon Tue Wed Thu Fri Sat

1 2 3 4 5

6 7 8 9 10 11 12

13 14 15 16 17 18 19

20 21 22 23 24 25 26

27 28 29 30
- ネムイ・トリノミアス
Foreign Visitors,See This First

免責・連絡先は↑のリンクを

ChaN's FatFs Projects and
OpenOCD Binary are Here.
おきぱはここ！

↓SNSもやってます↓
powered by まめわざ

- ARM/STM32 (117)
- OpenOCD (27)
- ARM/NxP (34)
- ARM/Cypress (5)
- ARM/Others (3)
- ARM/Raspi (1)
- AVR (13)
- FPGA (4)
- GPS/GNSS (19)
- MISC (84)
- STM8 (2)
- Wirelessなアレ (16)
- おきぱ (1)
- ブラウザベンチマーク (29)
- 日本の自然歩道 (27)
- 中部北陸自然歩道を往く -砺波平野の県境を駆け抜ける！-
  ⇒ ねむい (12/18)
- 中部北陸自然歩道を往く -砺波平野の県境を駆け抜ける！-
  ⇒ ひかわ (12/15)
- STM32U0はぢめました
  ⇒ ねむい (08/07)
- STM32U0はぢめました
  ⇒ ひかわ (07/28)
- STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
  ⇒ ねむい (05/17)
- STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
  ⇒ どじょりん (05/16)
- STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
  ⇒ どじょりん (05/16)
- いろいろ試す61(と今年の反省会)
  ⇒ ねむい (01/02)
- いろいろ試す61(と今年の反省会)
  ⇒ ひかわ (01/02)
- いろいろ試す61(と今年の反省会)
  ⇒ ひかわ (01/01)
- April 2025 (1)
- March 2025 (1)
- February 2025 (1)
- January 2025 (1)
- December 2024 (2)
- November 2024 (1)
- October 2024 (1)
- September 2024 (1)
- August 2024 (1)
- July 2024 (1)
- June 2024 (1)
- May 2024 (1)
- April 2024 (1)
- March 2024 (1)
- February 2024 (2)
- January 2024 (1)
- December 2023 (4)
- November 2023 (2)
- October 2023 (2)
- September 2023 (1)
- August 2023 (2)
- July 2023 (1)
- June 2023 (2)
- May 2023 (3)
- April 2023 (1)
- March 2023 (1)
- February 2023 (1)
- January 2023 (1)
- December 2022 (2)
- November 2022 (1)
- October 2022 (1)
- September 2022 (1)
- August 2022 (1)
- July 2022 (1)
- June 2022 (1)
- May 2022 (1)
- April 2022 (1)
- March 2022 (1)
- February 2022 (1)
- January 2022 (1)
- December 2021 (2)
- November 2021 (2)
- October 2021 (1)
- September 2021 (1)
- August 2021 (1)
- July 2021 (1)
- June 2021 (1)
- May 2021 (1)
- April 2021 (1)
- March 2021 (1)
- February 2021 (1)
- January 2021 (1)
- December 2020 (3)
- November 2020 (1)
- October 2020 (1)
- September 2020 (1)
- August 2020 (1)
- July 2020 (1)
- June 2020 (2)
- May 2020 (1)
- April 2020 (1)
- March 2020 (1)
- February 2020 (1)
- January 2020 (1)
- December 2019 (3)
- November 2019 (1)
- October 2019 (1)
- September 2019 (2)
- August 2019 (1)
- July 2019 (1)
- June 2019 (1)
- May 2019 (1)
- April 2019 (1)
- March 2019 (1)
- February 2019 (1)
- January 2019 (1)
- December 2018 (3)
- November 2018 (2)
- October 2018 (1)
- September 2018 (1)
- August 2018 (1)
- July 2018 (1)
- June 2018 (1)
- May 2018 (1)
- April 2018 (2)
- March 2018 (1)
- February 2018 (1)
- January 2018 (1)
- December 2017 (2)
- November 2017 (2)
- October 2017 (1)
- September 2017 (1)
- August 2017 (1)
- July 2017 (1)
- June 2017 (1)
- May 2017 (1)
- April 2017 (1)
- March 2017 (2)
- February 2017 (2)
- January 2017 (2)
- December 2016 (7)
- November 2016 (2)
- October 2016 (2)
- September 2016 (1)
- August 2016 (1)
- July 2016 (1)
- June 2016 (1)
- May 2016 (2)
- April 2016 (1)
- March 2016 (2)
- February 2016 (1)
- January 2016 (1)
- December 2015 (3)
- November 2015 (1)
- October 2015 (3)
- September 2015 (2)
- August 2015 (2)
- July 2015 (3)
- June 2015 (3)
- May 2015 (4)
- April 2015 (2)
- March 2015 (4)
- February 2015 (1)
- January 2015 (3)
- December 2014 (3)
- November 2014 (2)
- October 2014 (1)
- September 2014 (2)
- August 2014 (2)
- July 2014 (3)
- June 2014 (2)
- May 2014 (1)
- April 2014 (1)
- March 2014 (4)
- February 2014 (4)
- January 2014 (3)
- December 2013 (5)
- November 2013 (4)
- October 2013 (3)
- September 2013 (2)
- August 2013 (2)
- July 2013 (2)
- June 2013 (3)
- May 2013 (2)
- April 2013 (2)
- March 2013 (2)
- February 2013 (2)
- January 2013 (3)
- December 2012 (4)
- November 2012 (2)
- October 2012 (2)
- September 2012 (4)
- August 2012 (1)
- July 2012 (3)
- June 2012 (2)
- May 2012 (3)
- April 2012 (3)
- March 2012 (2)
- February 2012 (3)
- January 2012 (3)
- December 2011 (5)
- November 2011 (3)
- October 2011 (2)
- September 2011 (2)
- August 2011 (2)
- July 2011 (2)
- June 2011 (2)
- May 2011 (2)
- April 2011 (2)
- March 2011 (2)
- February 2011 (2)
- January 2011 (3)
- December 2010 (7)
- November 2010 (1)
- October 2010 (1)
- September 2010 (1)
- August 2010 (3)
- July 2010 (4)
- May 2010 (1)
- April 2010 (2)
- March 2010 (2)
- February 2010 (2)
- January 2010 (3)
- December 2009 (3)
- November 2009 (8)
- October 2009 (7)
- September 2009 (5)
- August 2009 (4)
- July 2009 (6)
- June 2009 (6)
- May 2009 (14)
- January 1970 (1)

<< April 2025 >>
Sun	Mon	Tue	Wed	Thu	Fri	Sat
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30