SWD (Serial Wire Debug) やっててさらにトレース(printfみたいなこと)も行いたいことは多い。別途 USART を繋げて printf() デバッグしても良いが、正直めんどうくさい。

ITM とは?

Instrument Trace Macrocell の略で Cortex-M の Arm CoreSight (MCU 側のデバッグ機能) に含まれるトレース機能。トレース機能は雑にいうと printf() みたいなもので、実際 printf() を中継するのに使うこともできる。

SWO (Serial Wire Output) というトレース用のピンを使う。

semihosting との違い

セミホスティングとはが詳しいが、セミホスティングはホスト側でシステムコールの一部をホストするという仕組みで、bkpt (ブレークポイント) などで発生する例外を ARM プロセッサのデバッガインターフェイスが拾ってホスト側に中継する。

仕組み的にビルド・トレース環境とかを作るのがめんどい。

ITM の Pros. Cons.

  • ↑ 特殊なビルドが不要
  • ↓ 余計な配線が1つ必要 (SWO)

semihosting の Pros. Cons.

  • ↑ できることが多い
  • ↓ ビルドが複雑

中華 ST-Link V2 の改造

よく売ってる安い ST-Link V2 には SWO 用のピンが出ていない。機能自体はあるので配線してやる。5V と 3.3V はピンが2本ずつ重複しているので、片方を潰せば特にデメリットなく拡張できる。

↑ こういう感じでケース(カバー?)は外せる。USB コネクタ側にスライドする

↑ 31ピンが SWO 用のピン。一応親切?なのか若干配線が伸びてるので、カッターでレジストを剥してはんだづけするのが楽

↑ 今回は 5V のピンを1つ配線をカットして使うことにした。22Ωを介して外に出す。UEW 線でやってる。ちゃんとテスターで導通チェックしましょう

配線


MCU 側は SYS_JTDO_SWO の機能があるピンを設定する。STM32F401 の場合は PB3。Alternate function を設定しなければデフォルトで SWO のはず?モノによるかも

コード側

ここでは printf() を中継する前提で _write() を適当な位置に定義する

int _write(int file, char *ptr, int len) {
	for(int i = 0; i < len; i++) {
		ITM_SendChar(*ptr++);
	}
	return len;
}

あとは printf() を使うところで以下のように stdio.h を include すれば良い

#include <stdio.h> 

VSCode + Cortex-Debug の設定

Cortex-Debug は ITM のデコードをサポートしていて以下のような設定をできる。

launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "OpenOCD-Debug",
            "type": "cortex-debug",
            "request": "launch",
            "servertype": "openocd",
            "executable": "build/stm32f401-usbserial-host.elf",
            "configFiles": [
                "interface/stlink.cfg",
                "target/stm32f4x.cfg"
            ],
            "postLaunchCommands": [
                "monitor reset init",
                "monitor itm port 0 on"
            ],
            "cwd": "${workspaceRoot}",
            "svdFile": "STM32F4x1.svd",
            "device": "stm32f4x",
            "preLaunchTask": "build",
            "swoConfig": {
                "cpuFrequency": 64000000,
                "source": "probe",
                "swoFrequency": 1000000,
                "enabled": true,
                "decoders": [
                    {
                        "port": 0,
                        "label": "ITM",
                        "type": "console"
                    }
                ]
            }
        }
    ]
}

これで、VSCode の「出力」タブのドロップダウン「SWO: ITM [port: 0, type: console]」に ITM 経由のログが出るようになる。type: console の場合 "\n" 区切りであることを前提にタイムスタンプを追加してくれる。

postLaunchCommandsmonitor reset init はないほうがいいかも。cpuFrequency は HCLK にあわせるのが良い。

ref

  1. トップ
  2. tech
  3. Cortex-M の SWD/ITM を使った UART を使わない printf() デバッグ

現行の最新は V2 Plus (V2.3) または V2 Plus4 だけど、 これらが出る直前に V2.2 を買ってしまったのでちょっと残念な感じ。とはいえ V2.2 と V2.3 はハードウェア的には非常に差分が少ないようなので、改造してみた。Upgrade your NanoVNA v2 to v2 Plus を参考にしてやれば良い。

変更を加える箇所

  • R311 10 -> 68
  • C318 220nF -> 10nF
  • C321 10μ -> 100nF
  • L302 22μH (変更なし参考)




ファームウェアのバックアップ

bootloader も含めてファームウェアのすべてをバックアップしておく。

接続

よく売ってるやすい ST-Link V2 というやつを使う 参考

メインボード上にスルーホールがありシルクも印刷されているので普通に繋ぐだけ。

スルホール用テストワイヤを使うと楽

backup and restore 手順

まず一応書きこまれている内容をバックアップしておく

openocd を使う場合

読みこみ (ダウンロード)

openocd -f interface/stlink.cfg -f target/stm32f3x.cfg -c init -c "reset init"  -c "flash read_bank 0 backup.bin 0x0000000 0x40000" -c exit

書きこみ (アップロード)

openocd -f interface/stlink.cfg -f target/stm32f3x.cfg  -c "program backup.bin 0x08000000 verify reset exit"
st-flash を使う場合 (書けない)
$ st-flash read backup.bin 0x08000000 0x8040000
st-flash 1.4.0
2020-10-27T01:00:56 INFO common.c: Loading device parameters....
2020-10-27T01:00:56 INFO common.c: Device connected is: F1 High-density device, id 0x17010414
2020-10-27T01:00:56 INFO common.c: SRAM size: 0x10000 bytes (64 KiB), Flash: 0x40000 bytes (256 KiB) in pages of 2048 bytes

ただ、これを st-flash で書こうとすると失敗してしまう……

$ st-flash write backup.bin 0x08000000
st-flash 1.4.0
2020-10-27T01:02:39 INFO common.c: Loading device parameters....
2020-10-27T01:02:39 INFO common.c: Device connected is: F1 High-density device, id 0x17010414
2020-10-27T01:02:39 INFO common.c: SRAM size: 0x10000 bytes (64 KiB), Flash: 0x40000 bytes (256 KiB) in pages of 2048 bytes
2020-10-27T01:02:39 INFO common.c: Ignoring 864 bytes of 0xff at end of file
2020-10-27T01:02:39 INFO common.c: Attempting to write 261280 (0x3fca0) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x0803f800 erased
2020-10-27T01:02:41 INFO common.c: Finished erasing 128 pages of 2048 (0x800) bytes
2020-10-27T01:02:41 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2020-10-27T01:02:41 ERROR flash_loader.c: unknown coreid, not sure what flash loader to use, aborting! coreid: 2ba01477, chipid: 414
2020-10-27T01:02:41 WARN flash_loader.c: Failed to write flash loader to sram!
2020-10-27T01:02:41 ERROR common.c: stlink_flash_loader_init() == -1
stlink_fwrite_flash() == -1
exit 255

bootloader

bootloader は Serial Number によって何かが異なるらしく、実際間違った bootloader を書きこむと BBGAIN の値がおかしくなったり、起動しなくなったりする。とにかく現状をバックアップしておけば元には戻せるので、バックアップは大事。

レポジトリにある bootloader は V2_2 用で、最新版は事情があって今のところ公開されていないらしい。現時点では Discord で開発者にコンタクトをとってビルドしてもらう必要がある。が、そのうち SN を指定してビルド・ダウンロードできるページを作るらしいので急ぎじゃないのなら待ってればいいかも。

どういう変更点なのか

該当箇所の回路図

  • 前段の AD8342 はミキサ
  • GS8722C は2回路入りオペアンプ (11MHz)
  • MXD8641 は SP4T スイッチ。オペアンプの増幅率を決めている

なのでここの一連の回路はミキサ出力を ADC 前にフィルタ・増幅する回路になる。


R311, C318, L302 はローパスフィルタで、カットオフは変更前は約72kHz、変更後は34kHz。noise improvement はここのカットオフ変更によるものだと思う。

C321 は交流増幅のための直流カットキャパシタだと思うが、小さくすることで反応性を上げてスキャン速度を上げられるようにしたのだと思う。違うかも

メモ: ADCのサンプルレート

S-A-A-2 の場合 ADC は MCU のものを直接使っている。

  • V2.2 では 300kHz board_v2_1/board.cpp (v2_1 と v2_2 は同じ)
    • ADC のクロックは 6MHz
  • V2.3 では 1500kHz board_v2_plus/board.cpp
    • ADC のクロックは 30MHz
  1. トップ
  2. tech
  3. S-A-A-2 (NanoVNA V2) V2.2 から V2.3 への変更