いろいろ試す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 0x80b9e

13.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 0x807b7

Flash使用量は減りましたが…、
ううむ若干SRAM使用量増えてますね…。


mapファイルを比較してましたがnewlibでSRAMの使用量が32byteほど増えて
おりました。…まぁこの程度なら許容の範疇でしょう…。

一応STM32H5でlibpngのDecode速度のパフォーマンスを比較してみました。
13.2Rel1

13.3Rel1

あ…ありり…
ちょっとかなり遅くなってる…(脂汗

GCC14に期待しましょう〜!!

20240826追:
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=none



STM32H5のビルドサイズ比較をしてみましょう
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.elf

LTOあり
 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.elf


5kByte弱削減できました。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マイコンを使用しているか否かで判別しているようですね。

Comments

Post a Comment








Go to top of page