メモ

自力で DNS Server を実装するとOSの違いに気付くことがある

• macOS は DNS response に QUERY が含まれていなくても (ANSWER だけで) 認識する
• Android は DNS response にQUERY が含まれていないと認識しない

トラブルシューティング

DMA ではない HAL_UART_Transmit は動くか試す。動かないなら UART の設定やピンを確認してみたほうが良い。

DMA すると何も動かんとき

generated code がうごかないじゃん…… となったら HAL_DMA_Init を最初にもってくると動くことがある。

とりあえず変更して試すなら適当に編集して試せば良い。が再生成するとき困るので、CubeMX 上でこの順番は変えておくのが良い。Project Manager → Advanced Settings にいくと順番を変更するUIがある。

最初の一回だけ成功するとき

UARTn global interrupt をオンにする。HAL_UART_IRQHandler あたりで送信の後処理とかをしているようで、この割込みが有効でないと最初の DMA 以降は HAL_BUSY となり成功しない。

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

変更を加える箇所

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

ハマったところ: 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 のグリッチが原因ではないか？ ということが書いてあって解決の参考になった