いろいろ試す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マイコンを使用しているか否かで判別しているようですね。

Go to top of page