いろいろ試す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を使ったデバッグ方法を何とか安定させ正式に公開したいのですが
なかなか手ごわいです…
STM32H7を使ってみる7 -ティアリングを何とかしたい-
←前回
なんと4年ぶりのSTM32H7の記事です！
ちなみに最新のSTM32H7R/SシリーズについてはOpenOCDが正式対応して
いないため、当面の間はSTM32H747I-Discoveryを使用した記事となります…
お前アリアハンから全然脱出できてないじゃないか！１！！
さて、ねむいさんが公開しているFatFs移植サンプル通称"いつもの"に
ついてはChaN師のFatFsのほかに簡易ファイラーやtxt(S-JISのみ)ファイル、
さらに独自フォーマットの動画ファイルも対応しております。
それでSTM32H747I-DISCOはDSIインターフェースでLTDCを動作させて
映像を出力しているのですが、素早く画面切り替えた際や動画再生時などに
画面のティアリングが発生してしまっておりました。
例としてゼERO動画を再生しているところ
赤色で線引いて強調してみましたが横方向のティアリングの上に斜め方向
にもティアリングが発生してしまっている状態です。
横方向のティアリングはLTDCのVSYNCを待つようにしたら解消しました。
具体的なコードは下記のようなコードをDMA2Dでぶん投げる前に挿入すれば
解決です。
/**************************************************************************/
/*!
Wait VSYNC signal.
*/
/**************************************************************************/
void Display_WaitVSYNC(void)
{
/* reload shadow registers on vertical blanking period */
LTDC->SRCR = LTDC_SRCR_VBR;
/* wait for next frame */
while ((LTDC->CDSR & LTDC_CDSR_VSYNCS) == 0);
}コード詳細は./lib/display/mcu_depend/src/lcdc_if_basis.cと
./lib/display/abstract/src/ts_fileloads.cを参考にしてください。
しかし、斜め方向のティアリングはこれでだけは解消しませんでした…
画面切り替えたときとかの斜め方向のティアリングがどうしても
気になってしまう…
不思議なことに斜めティアリングはDSI接続のLCDモジュールを横方向
(LANDSCAPE)で使用した時だけ発生し、縦方向(PORTRAIT)なら一切発生
しないことに気づきました…いないさんかわいい…
STのフォーラムも調べてみましたが同じ現象に悩んでる方が結構いることが
わかりました
��STM32F769-DISCOを使ってる人
��STM32F469I-DISCOを使ってる人
��ねむいさんとおなじSTM32H747I-DISCOを使ってる人
��STM32F469I-DISCOを使ってる人その２
共通するのはDSIインターフェースのLCDモジュールを横方向で使った際に
斜めティアリングが出ちゃっているようです。
ちなみにねむいさんが所持しているSTM32F769N-Discoveryでも同じ現象が
発生しておりました。
�，里箸海蹐�ST社員の人が斜めティアリングが起こる仕組みと対策を示して
おりました。
ねむいさん所持のSTM32H747I-DISCOのTFT-LCDモジュールのコントローラは
OTM8009Aという480x800(MAX864)のWVGAの縦方向表示に特化したやつでした。
横方向にして使用すると原理通りスキャン方向の相違が起こって斜め方向に
ティアリングが発生してしまうということなのでしょうか…
で、原理は納得しましたが具体的な対策(フレームバッファを2分割せよ)
とやらを文字で示していますがソースは提示されておらずねむいさんは
肝心のソースコードを知りたかったので再び泥沼にはまってしまいました。
しかし…
最後の�い里箸海蹐�VerticalBackPorch(VBP)を増やしたら斜めティアリングを
画面の外に蹴りだせたとコメントを見つけ、ねむいさんも真似してやってみた
所確かに斜めティアリングが垂直方向に移動しました。
いろいろ試した結果、VBPの値を480追加すると丁度画面から消えるのが判明し
横方向表示の際の時だけVBPにVBP_OFSとして480を追加するようにしました。
/* Timing parameters for all Video modes
* Set Timing parameters of LTDC depending on its chosen orientation
*/
/* The following values are same for portrait and landscape orientations */
if(Orientation == LCD_ORIENTATION_PORTRAIT)
{
VSA = OTM8009A_480X800_VSYNC; /* 1 */
VBP = OTM8009A_480X800_VBP; /* 15 */
VFP = OTM8009A_480X800_VFP; /* 16 */
HSA = OTM8009A_480X800_HSYNC; /* 2 */
HBP = OTM8009A_480X800_HBP; /* 34 */
HFP = OTM8009A_480X800_HFP; /* 34 */
}
else
{
/* lcd_orientation == LCD_ORIENTATION_LANDSCAPE */
VSA = OTM8009A_800X480_VSYNC; /* 1 */
VBP = VBP_OFS + OTM8009A_800X480_VBP; /* 15(+480) */
VFP = OTM8009A_800X480_VFP; /* 16 */
HSA = OTM8009A_800X480_HSYNC; /* 2 */
HBP = OTM8009A_800X480_HBP; /* 34 */
HFP = OTM8009A_800X480_HFP; /* 34 */
} 
…コメント先ではNT35510のLCDモジュールではうまくいかなかったという
結果でしたがねむいさんがもってるOTM8009Aの奴は対策できたっぽいので
まぁワークアラウンドとしてはいいのかな…と思いまし、た！
DSI接続のLCDモジュールがあるDiscovery系ボードをお持ちで同じような
問題抱えてる方は追試していただけたら幸いです…！！
おきぱのSTM32H7,STM32F7のサンプルはワークアラウンド済です。
いろいろ試す62
●Picoscope7のソフトがバージョンアップ！今度こそ安定…か？
すぐフリーズしたり落ちたりでなかなか安定しないPicoscope7のソフトですが
Stable版が7.1.29にバージョンアップしておりました。
今度こそ本当にStableなんでしょうね…！？(どきどき
※会社で現役でバリバリ使用中のPicoscope3206Aで試してます
☝2画面で動かして放置すると固まったorz
…
ファ〇ッッック！！！！！
基本的な操作はだいぶ安定してきましたがちょっと複雑な操作はまだ
安定していないようですね…
というわけで安定して使用できるまでPicoscope6使っていきましょ…。
●arm-gccが久々の更新
Arm GNU-GCCが久々の更新です。
といってもGCC14ではなくまだGCC13のままです…。
13.2->13.3のマイナーチェンジですね。
また、今回はセキュリティ対策のアップデートしております。
同じプログラムをビルドしてバイナリサイズの比較です。
13.2Rel1(前のやつ)
arm-none-eabi-gcc (Arm GNU Toolchain 13.2.rel1 (Build arm-13.7)) 13.2.1 20231009
Copyright (C) 2023 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 479156 0 479156 74fb4 main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
477416 1740 39668 518824 7eaa8 main.elf
main.elf :
section size addr
.text 0x747fc 0x8000000
.ctors 0x0 0x80747fc
.dtors 0x0 0x80747fc
.eh_frame 0x54 0x80747fc
.ARM.exidx 0x98 0x8074850
.data 0x6cc 0x20000000
.bss 0x18a8 0x200006d0
.heap 0x0 0x20001f78
.ram2 0x0 0x20040000
.stack 0x0 0x20040000
.ram3 0x824c 0x20050000
.bkpram 0x0 0x40036400
.qspirom 0x0 0x90000000
.comment 0x44 0x0
.debug_frame 0x1e88 0x0
.ARM.attributes 0x38 0x0
.debug_line_str 0x1f2 0x0
Total 0x80b9e13.3Rel1(新しいほう)
arm-none-eabi-gcc (Arm GNU Toolchain 13.3.Rel1 (Build arm-13.24)) 13.3.1 20240614
Copyright (C) 2023 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 478396 0 478396 74cbc main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
476624 1772 39668 518064 7e7b0 main.elf
main.elf :
section size addr
.text 0x744e4 0x8000000
.ctors 0x0 0x80744e4
.dtors 0x0 0x80744e4
.eh_frame 0x54 0x80744e4
.ARM.exidx 0x98 0x8074538
.data 0x6ec 0x20000000
.bss 0x18a8 0x200006f0
.heap 0x0 0x20001f98
.ram2 0x0 0x20040000
.stack 0x0 0x20040000
.ram3 0x824c 0x20050000
.bkpram 0x0 0x40036400
.qspirom 0x0 0x90000000
.comment 0x45 0x0
.debug_frame 0x1d98 0x0
.ARM.attributes 0x38 0x0
.debug_line_str 0x1f2 0x0
Total 0x807b7Flash使用量は減りましたが…、
ううむ若干SRAM使用量増えてますね…。
mapファイルを比較してましたがnewlibでSRAMの使用量が32byteほど増えて
おりました。…まぁこの程度なら許容の範疇でしょう…。
一応STM32H5でlibpngのDecode速度のパフォーマンスを比較してみました。
13.2Rel1
13.3Rel1
あ…ありり…
ちょっとかなり遅くなってる…(脂汗
…
GCC14に期待しましょう〜！！
13.3Rel1のGDBはCortex-M33コアでbreakpointが効かなくてデバッグが
できないことが判明しました…(多分バグです)
ひとつ前の13.2Rel1のやつ使いましょう…
20240828追:
13.3Rel1のGDB(GDB14)はちょっと規模が大きいプロクラムになると
breakpointが効かなくなってデバッグが全くできなくなることが
判明しました…orzおそらくGDBのバグっぽい挙動ですがまだ情報が
出そろっていないので今は13.2Rel1のarm-gccを使ったほうが無難です…
どうしてこんなことにorzorz
●組み込み向けのLTO考察
リンク時最適化(LinkTimeOptimization)。ねむいさんは10年位前に使った際に
バグが多くて封印してそれっきりでした。ここ最近はどうなっているのか色々
調べてみましたが、あのころと比べてかなり様変わりしてるのがわかりました。
まずは公式のLTOの解説をしっかりと読みとおすこと。
そのうえでLTOのビルドを成功させるためには幾つかの障壁がありました。
*FONTX2のファイルを直接取り込むincbinと相性が悪い
LTOなしだとビルドできるのにLTOつけるとアセンブラでエラー吐いてこける。
LTOの場合はmakefileがあるところからのフルパスを指定しないといけない。
makefileが存在するディレクトリからの相対パスを指定しなおすことで
苦しみ紛れに屁をこいたような対策ですが何とか対処できました。
*引数も重要
ビルド時に与える引数も"-flto"だけじゃダメになっていて、試行錯誤した結果
以下のオプションを全部追加することでLTOビルドを達成できました。
-flto
-ffat-lto-objects
-fuse-linker-plugin
-flto-partition=noneSTM32H5のビルドサイズ比較をしてみましょう
LTOなし
Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 478260 0 478260 74c34 main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
476488 1772 39668 517928 7e728 main.elfLTOあり
Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 473372 0 473372 7391c main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
471608 1764 39672 513044 7d414 main.elf5kByte弱削減できました。SRAM消費量も微量ながら減ってますね。
もちろんLTOありでもちゃんとプログラムは機能します。
大規模プロジェクトなので効果は感じづらいですがSTM32C0とかの
小規模なプログラムなら削減効果をかなり実感できると思います。
あとリンク段階で変なワーニング出るんですけど対象方法知ってる人いたら
教えてくだち。
●mbedサ終
ついに来てしまいましたね…
ねむいさんもほとんど使用しないままここまで来てしまいましたが
時代の仇花として人々の記憶に残るでしょう…(2026年完全終了)。
ねむいさん的にはオンラインコンパイラは圧倒的に相性悪くてやっぱり
PCで普通にコンパイルするのが身の丈に合っていると感じました。
●STLinkV3はST製以外のマイコンを排斥する！実質STM32専用ｯ！
まぢですか…、OpenOCDからも使えないとは…！
秋月で売ってるやつ買わないでよかった…！
実質STM32以外の他社製のCortex-Mのマイコンのフラッシュ書き込みは
おろかコアにconnectすらできないようです…。
一方で手持ちのSTLink/V2系は大丈夫なのかどうか実際に確認してみました。
使用したのはおそロシアの力でSWIMに無理やり対応させたSTM32F0Discovery
付属のSTLink/V2です…相手は今は亡きLPC810です！
まずはHLAとして接続
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/stlink-v2.cfg -c "transport select hla_swd" -f target/lpc81x_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.12.0+dev-00682-gefe902219 (2024-08-12-08:52)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlink.cfg
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
DEPRECATED! use 'gdb target_description', not 'gdb_target_description'
Info : clock speed 1000 kHz
Info : STLINK V2J45S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 2.905861
Info : [lpc81x.cpu] Cortex-M0+ r0p0 processor detected
Info : [lpc81x.cpu] target has 4 breakpoints, 2 watchpoints
Info : [lpc81x.cpu] Examination succeed
Info : [lpc81x.cpu] starting gdb server on 3333
Info : Listening on port 3333 for gdb connections
[lpc81x.cpu] halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x1fff0008 msp: 0x10000ffc
Info : wrote 3072 bytes from file main.elf in 1.093837s (2.743 KiB/s)
Info : verified 3072 bytes in 0.055933s (53.636 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:01お次はDAPDirectで接続
> "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/lpc81x_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.12.0+dev-00682-gefe902219 (2024-08-12-08:52)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
DEPRECATED! use 'gdb target_description', not 'gdb_target_description'
Info : STLINK V2J45S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 2.882555
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x0bc11477
Info : [lpc81x.cpu] Cortex-M0+ r0p0 processor detected
Info : [lpc81x.cpu] target has 4 breakpoints, 2 watchpoints
Info : [lpc81x.cpu] Examination succeed
Info : [lpc81x.cpu] starting gdb server on 3333
Info : Listening on port 3333 for gdb connections
[lpc81x.cpu] halted due to breakpoint, current mode: Thread
xPSR: 0xf1000000 pc: 0x1fff0008 msp: 0x10000ffc
Info : wrote 3072 bytes from file main.elf in 1.219387s (2.460 KiB/s)
Info : verified 3072 bytes in 0.063133s (47.519 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:03
ファームのVerは20240821最新のV2J45S7を使用しておりますが、
STLink/V2のハードウエアなら他社製Cortex-Mマイコンでも大丈夫なようですね…
●そしてぱちもんSTLinkV2にもパチモン対策が
まぁこんなこったろうと思っていましたが、粗製乱造で広まっている中華製偽物
STLink/V2を検知したらシリアル番号を"C"にしてしまうファームウエアが発動
しているようです。
STM32CubeProgrammerではこのシリアルをもつぱちもんSTLink/V2が
使用できなくなります。
OpenOCDからはまだ大丈夫っぽいですがこちらも穴がふさがれそうですね。
ちなみにねむいさんがSTM8マイコンの読み書きするためにおそロシアの力を
使って改造したSTLink/V2はシリアル番号は"C"ではなかったのでセーフでした。
恐らく正規のSTM32マイコンを使用しているか否かで判別しているようですね。
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");
#endifOpenOCDでは上でも述べましたが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
endifGCC14でビルドする場合は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
STM32H5を使ってみる6 -秋月販売記念!SDMMCとFatFsでSDカードを使う-
秋月さんからついにNUCLEO-H563ZIが販売となりました！！！
これで皆様も気軽にSTM32H5をいじることができるでしょう〜！
ちなみにSTM32H5に対応したOpenOCDはねむいさんのぶろぐで公開
しておりますのでどしどしご利用ください！！！！
そうだね宣伝だね！！
あ、それと買った人チップリビジョンちゃんと確認してくださいね…
Zならはずれです…
●STM32H5のSDMMC
そんなわけで今回はSTM32H5のSDMMC機能を利用してFatFsを移植し
SDカードやMMC/eMMCからデータの読み書きを行うところまでを
紹介します。
STM32H5のSDMMCにはSTM32H7と同じくIDMAというGPDMAから独立した
DMAが存在しており、GPDMAと干渉することなく運用が可能です。
また、STM32H5は外部メモリ(FSMC/OCTO-SPI)にしかDキャッシュが
かかわってこないためキャッシュコントロールの面倒さもありません。
●STM32H5では公式にFatFsの移植例がないが…
STM32H5以降はMicrosoft Azure RTOSに入れ込んでおりFatFsではなく
FILEXなるソフトウエアライブラリに置き変わっておりました。
ねむいさんは慣れ親しんだFatFs以外の選択肢はないのでFILEXはガン
無視のザ・シカトで移植に挑みました。
移植についてですがSTM32F7のころから慣れ親しんだいわば"枯れた"
ペリフェラルなのでHALの構造も酷似しているためSTM32H7やSTM32L5の
移植例からI/Oとクロック設定以外はほぼスライド移植で簡単にできて
しまいました！
f_readの結合関数SD_read()はこんな感じです。
DRESULT SD_read(BYTE lun, BYTE *buff, DWORD sector, UINT count)
{
DRESULT res = RES_OK;
uint32_t timer = SysTick->VAL + SD_DATATIMEOUT;
/* first ensure the SDCard is ready for a new operation */
while((SD_GetCardState() == SD_TRANSFER_BUSY))
{
if(timer < SysTick->VAL)
return RES_NOTRDY;
}
#if defined(SD_DMA_MODE) && !defined(SD_POLLING_MODE)
if((uintptr_t)buff & 0x3) /* Check 4Byte Alignment */
{ /* Unaligned Buffer Address Case (Slower) */
for (unsigned int secNum = 0; secNum < count ; secNum++){
if(SD_ReadBlocks_DMA((uint32_t*)dmabuf, (uint32_t)(sector+secNum), 1)!= MSD_OK)
{
MSG_PRINTF("Read error on unaligned buffer¥n");
res = RES_ERROR;
}
memcpy(buff+secNum*SECTOR_SIZE, dmabuf, SECTOR_SIZE);
}
} else {
/* Aligned Buffer Address Case (Faster) */
if(SD_ReadBlocks_DMA((uint32_t*)buff, (uint32_t)sector, count) != MSD_OK)
{
MSG_PRINTF("Read error on DMA¥n");
res = RES_ERROR;
}
}
#else
if(SD_ReadBlocks((uint32_t*)buff, (uint32_t)sector, count) != MSD_OK)
{
MSG_PRINTF("Read error on polling¥n");
res = RES_ERROR;
}
#endif
return res;
}f_writeの結合関数SD_write()はこんな感じです。
DRESULT SD_write(BYTE lun, const BYTE *buff, DWORD sector, UINT count)
{
DRESULT res = RES_ERROR;
uint32_t timer;
#if defined(SD_DMA_MODE) && !defined(SD_POLLING_MODE)
if((uintptr_t)buff & 0x3) /* Check 4Byte Alignment */
{ /* Unaligned Buffer Address Case (Slower) */
for (unsigned int secNum = 0; secNum < count; secNum++){
memcpy(dmabuf, buff+(SECTOR_SIZE*secNum), SECTOR_SIZE);
if(SD_WriteBlocks_DMA((uint32_t*)dmabuf, (uint32_t)(sector+secNum), 1) != MSD_OK)
{
MSG_PRINTF("Write error on unaligned buffer¥n");
res = RES_ERROR;
}
}
} else {
if(SD_WriteBlocks_DMA((uint32_t*)buff, (uint32_t)sector, count) != MSD_OK)
{
MSG_PRINTF("Write error on DMA¥n");
res = RES_ERROR;
}
}
#else
if(SD_WriteBlocks((uint32_t*)buff, (uint32_t)sector, count) != MSD_OK)
{
MSG_PRINTF("Write error on polling¥n");
res = RES_ERROR;
}
#endif
/* ensure the SDCard is ready for a next operation */
timer = SysTick->VAL + SD_DATATIMEOUT;
res = RES_ERROR; /* Timeout */
/* block until SDIO IP is ready or a timeout occur */
while(timer > SysTick->VAL)
{
if(SD_GetCardState() == SD_TRANSFER_OK)
{
res = RES_OK;
break;
}
}
return res;
}キャッシュコントロールがないのですっきりですね。
全体的なソースの詳細についてはねむいさんのSTM32H5プロジェクト内の
下記ディレクトリのファイルを参照してください。
./lib/ff/sdmmc_stm32h5.c
./lib/ff/sdmmc_stm32h5.h
●直線リードのパフォーマンスはどんな感じか
STM32H5の最大クロックは250MHz取れるのでSDMMCのクロック周波数も
250/5=50MHzとハイスピードの規格いっぱいの50MHzでぶん回すことが
可能です。
直線の読み出しスピードは19MBytes/Sec出てますね。
こんだけあれば十分でしょう。
ちなみにeMMCでは3.3VでDDRモードに対応しており、STM32H5のSDMMCも
DDRに対応しているのでSDカードを超えた早い読み出しが可能です！！
●SMART取得機能も搭載
ねむいさんはSMARTが取れる産業用/工業用SDカードが大好きですが
STM32H5でももちろんSMARTの取得を可能としてます！
試される際は上記のコードをコメントアウトしてくださいね〜
SMART対応のSDカードについては下記記事もご参照ください！
・DELKIN製SDカード
・TRANSCEND製microSDカード
そんなわけでかなりやっけつ気味にSTM32H5へのSDMMCを使ったFatFs
の移植を紹介しましたがそれらを組み込んだ総合的な成果物は昨年
からすでにおきぱで公開しておりますのでどしどし参考にしてください！
免責・連絡先は↑のリンクを
↓SNSもやってます↓
powered by まめわざ
- ARM/STM32 (116)
- OpenOCD (27)
- ARM/NxP (34)
- ARM/Cypress (5)
- ARM/Others (3)
- ARM/Raspi (1)
- AVR (13)
- FPGA (4)
- GPS/GNSS (19)
- MISC (81)
- STM8 (2)
- Wirelessなアレ (16)
- おきぱ (1)
- ブラウザベンチマーク (28)
- 日本の自然歩道 (25)
- 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) - STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
⇒ ねむい (12/31) - STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
⇒ ひかわ (12/31)
- 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)
Copyright(C) B-Blog project All rights reserved.