使い勝手

操作性はほとんど NanoVNA と変わらない。充電回路はついているが、バッテリ本体が付属しないので適当なのを選んでつけてやる必要がある。

ケース

- https://www.thingiverse.com/thing:4592730

これがいい感じだった

今まで使っていたもの

今まで使っていたのは2014年1月に買ったOWON SDS7102。安くて使えはするけど、ロータリーエンコーダーに不具合があったり、ノイズに弱いのを感じたり、全体的におもちゃっぽいので若干不満だった。

SDS7102 は帯域が100MHzな一方、MSO5074 は 70MHz なので若干スペックダウンしているが、実際 100MHz まで必要な測定はそれほどしてこなかったので、まぁいいかな。付属プローブや、ハードウェア的には MSO5074 は 350MHz モデルと全く同じらしく、ソフトウェアで制限がかかっているだけなので、最悪オプションでなんとかできる。

なぜ MSO5074 か

• 4ch (2ch だと足りないなと思うケースが何度かあった)
• I2C SPI RS232 がデコードできる (ロジアナも持ってるけど、出してきて接続するのが面倒くさい)
• カラーグレーディングできる
• メモリ長が非常に長い
• 表示が綺麗
• チャンネルごとに独立操作できる
• 25MHz までのシグナルジェネレータがついている

Rigol は手持ちに スペクトラムアナライザ DSA815-TGを持っているけど、ネットワーク関係が割と良かったり、比較的堅牢で使いやすかったので、そこそこ印象が良い。

MSO5000 シリーズは Rigol の中でもミドルレンジなのでそれほど安くはない。が、オシロは電子工作する上でどっちにしろ一番使う測定器には違いないので多少お金かけてもいいかなと思う。

ちなみに 16chロジックアナライザ機能もついてるけど、専用プローブが普通に高いのでたぶん買わない (5万円ぐらい)。I2C SPI RS232 ぐらいなら 4ch アナログで十分かな

最初の印象

まだあまり使ってないので細かいところはわからないが以下の点の印象が良い

• LAN 経由でブラウザから操作できたりキャプチャしたりできる
• タッチ液晶 (思ったより良い)
• ズーム機能

今のところよくないなと思う点

• 起動が遅い (1分ぐらい)
• レスポンスはそれほど良くない

経緯

プライムデーにあやかって？代理店が独自にキャンペーンしてたみたいで、バンド幅拡張以外のオプション全部付きで12万弱になっていた。すこしまえから気になってチェックしていたので、この機会にということで購入。

ハマったところ: CS (チップセレクト) がない

写真を見たらわかるが CS 信号がピンヘッダに出ていない。どうやら GND に接続されているらしい。この状態だと CPOL (極性) を 1、CPHA を 1 (いわゆる SPIMODE=3) にしないとダメなようだった。

そして CS の制御ができないと何が困るか、というとクロック信号を不要に発生させるとグリッチが発生してしまう。

今回はSPIデバイスのオン/オフを都度都度行っていた関係でどうしてもクロックに余計な信号が入っていたので、それをなくしたら動いた。

参考文献

• support the IPS 1.3" ST7789 with CS pin to ground? clock polarity の話や clock のグリッチが原因ではないか？ ということが書いてあって解決の参考になった

変更を加える箇所

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

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

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

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

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" 区切りであることを前提にタイムスタンプを追加してくれる。

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

ref

• Adding Trace support to ST-Link clones
• Completion of the Chinese ST-Link v2: add the SWO debug information output interface and foot reset