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

秋の登山ラッシュに入ってしまったのでせっかく買ったのに全く
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のプロジェクト自体はすでに公開しておりますので
それまでに皆様予習をお願いいたします…ｚｚｚ

いろいろ試す60

いろいろ試してきてついに60回を迎えてしまいましたが
ほんっと大したことやってませんね…



●ぶろぐの画像の修正すべて完了の件
2016年からはや7年も経過してしまいましたがdropboxの仕様変更のあおりを
受けて表示できなくなっていた画像ですがすべて修正が完了致しました！！

長かった…一番しんどかったのは東海自然歩道や登山関連の超大量の
画像の差し替え作業でしたがなんとかすべてこなすことができました…
もう10年以上前になるものもあって本当に年月を感じ…
あああああああああああああああああああああ！！！！１１１！！！１



現在はEDGEで見た際に表示が崩れないようにレイアウトの修正を細々と
行っております。
ゆくゆくはwordpressに移行を考えておりますが…何年後かな…？


●Windows10以降対応の64bit版FONTX2コンバータ作りました
FONTX2は現在では電子工作で大人気のフォントフォーマットです。
詳しい解説はおなじみChaN師のサイトでもされており参考になります。

ところで現在Windowsで使われているTrueTypeフォントからFONTX2ファイルを
作成したい場合はかつてはWFONTXという非常に便利なツールが存在して
いたのですがこれはWindowsNT3.1用の代物で、64bitOSが全盛の現在では
動作させることができません。

そこでねむいさんが64bitOS対応のWFONTX64を作成いたしました！
これはオリジナルからXPに対応されたすん様のWFONTX32をベースとしております。
ねむいさんが見つけた細かいバグ等も修正し使い勝手を多少上げました。


☆使い方☆

まずはプログラムを開いたところです。
ここではねむいさんの最近のお気に入りの小夏フォントを12x12pixelの
FONTX2化する例を挙げます。

注:あらかじめ小夏フォントをインストールしているのが前提です！

ドロップダウンメニューから"小夏 等幅"を選択します。


次に高さと幅をピクセル数で指定します。ここで注意ですがたとえば12x12で
表示したい場合はHeightに12,WidthにHeightの半分の6を指定します。


Widthに12をしてしまうと横長になっちゃいます。
12の半分の6を指定してください。


"FontX2 Name"の欄にはFONTX2のヘッダを指定します。FONTX2の仕様上8文字
以上は指定できません(8文字以上入力できないようにしてます)。
ここではKONATHNとします。
また、FontX2Typeは半角の"Ank"を指定します。


Save Nameの欄は生成されるファイル名を指定します。
KONATHN12.FNTとします。

ここまで入力したら"RUN"と"NO STOP"が押せるようになります。
"RUN"はダイアログに1文字ずつ表示しながら変換(遅い)、"NO STOP"は表示
せずに一気に変換します(早い)。


変換が終わるとKONATHN12.FNTが生成されます。
生成されたのはFONTX2の中のAnkフォントで半角のAscii文字だけが
格納されてます。漢字などの2バイト文字は全角用の生成操作が
必要です。


お次は2バイトの全角です。ラジオボタンをAnkからKanjiに変え、
Save NameはKONATZN12.FNTとしましょう。


これで半角・全角のFONTX2ファイルが無事生成されました！


で、こいつをねむいさんのいつものに組み込んでSTM32H5使ってTFT-LCDに
FONTX2ドライバを使って表示できました。


こんなわけで30年の時を超えて現在でもお手軽にマイコンで好きな文字が
お手軽に表示できるようになっております。
また、生成したFONTX2ファイルを含むソースコードの再配布の際は元の
フォントのライセンスに注意し、それに従ってください。




●avrdudeがv7.2になっていた
亀のような更新速度だったころから比べると日々増殖する小宇宙状態と
なっているavrdudeですがいつのまにかv7.1->v7.2に進化しております。

紹介しきれないくらい機能がアップしておりますので特に細かい不具合が
つぶさに修正されておりますので特に理由がない場合以外はv7.2に乗り
変えましょう。

ねむいさんもVerupのスピードに振り落とされないようにしがみついており、
おきぱでも常に最新のavrdudeのwindowsバイナリを公開しておりますので

よろしくお願いします！！


●CMSISもv6になっていた
10年ほどの間CMSISはver5のままメンテが行われておりましたが今年の
春くらいからver6に移行しております。

大まかな構成は変わっておりませんのでそのまま置き換えてビルドが
可能になっております。

この記事を書いてる現在では修正されましたがGCCでコンパイルした際に
"#pragma clang system_header"が引っかかってワーニングが出まくる
事態となっておりましたが10月末にようやく修正されました。
おきぱで紹介しているいつものたちはその修正されたものを適用してますので
こちらもどしどしご利用ください！


●そのGCCも13になっていた
そしてGCCも12から13にバージョンアップしておりました。

arm-none-eabi-gcc (Arm GNU Toolchain 12.3.Rel1 (Build arm-12.35)) 12.3.1 20230626

->
arm-none-eabi-gcc (Arm GNU Toolchain 13.2.rel1 (Build arm-13.7)) 13.2.1 20231009



ねむいさんのSTM32H7-Discovery向けプロジェクト"いつもの"のバイナリサイズを
比較してみましょう。

GCC12
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	 709212	      0	 709212	  ad25c	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

 707324	   1888	2384060	3093272	 2f3318	main.elf

main.elf  :

section               size         addr

.text              0xac840    0x8000000

.ctors                 0x0    0x80ac840

.dtors                 0x0    0x80ac840

.eh_frame             0xb0    0x80ac840

.ARM.exidx            0x98    0x80ac8f0

.itcm                0x174          0x0

.data                0x760   0x24000000

.bss               0x11f2c   0x24000760

.heap                  0x0   0x2401268c

.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           0x233f80   0xd0000000

.qspirom               0x0   0x90000000

.comment              0x45          0x0

.debug_frame        0x1f7c          0x0

.ARM.attributes       0x30          0x0

.debug_line_str      0x1f4          0x0

Total             0x2f54fd

GCC13
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	 709868	      0	 709868	  ad4ec	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

 707980	   1888	2384060	3093928	 2f35a8	main.elf

main.elf  :

section               size         addr

.text              0xacad0    0x8000000

.ctors                 0x0    0x80acad0

.dtors                 0x0    0x80acad0

.eh_frame             0xb0    0x80acad0

.ARM.exidx            0x98    0x80acb80

.itcm                0x174          0x0

.data                0x760   0x24000000

.bss               0x11f2c   0x24000760

.heap                  0x0   0x2401268c

.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           0x233f80   0xd0000000

.qspirom               0x0   0x90000000

.comment              0x44          0x0

.debug_frame        0x1d1c          0x0

.ARM.attributes       0x30          0x0

.debug_line_str      0x1f4          0x0

Total             0x2f552c



あれ…なんかバイナリサイズが600Byte近くも増えてるような…


と、とりあえず速度比較もしてみましょう
jpegファイルのデコード速度を比較します。-O2でコンパイルしました。


GCC12:(236704uSec)


GCC13:(237486uSec)

…
あ…あれ…結構遅くなってる…！？

ま、まぁ多分何かの安定性が上がったかもなのでよしとしましょう…
(脂汗)

Go to top of page