STBee F4mini CDC

　STM32F4のUSBでFull Speed/DeviceのCDCを試してみた。
　どーせ動かないんでしょ～、と思ってたけど、あっさり動いてしまって拍子抜け。

　STM32CubeMX その6- USB-CDCの実装 – メモたんく
　ここを参考に、STM → PCは問題なく動いた。
　たぶんPC → STMも、1バイトづつだけど、ちゃんと動いてる。

　ただ、USART1.TXがUSB DPに流れ込む、という謎の挙動が発生していて、悩んでいる。

　最初、なんで動かないんだよ～と、悩んで、そういえばZEROPLUSのロジアナってUSBキャプチャもできたよな、と思ってキャプチャしたら、USARTがUSBに流れ込んでいる、という現場を発見した次第。
　上の画像は、上半分がUSARTで、そのさらに上半分がPC→STMの流れ、下半分がSTM→PCの流れで、画像下半分はUSBのキャプチャ。USARTは0.1152MBaudで、USBは12Mbaudなので、ボーレートはほぼ100倍違う。USB早いなぁ。
　黄色の、STM→PCのデータが数マイクロ秒程度遅れてオレンジのUSB DPにあらわれているのが見える。
　数マイクロ秒は短い時間だけど、光速だと1km前後になるから、配線での遅延ということはないはず。ということは、マイコンの中で何らかの遅延が発生し、それが外に漏れている、ということなのかもしれない。ただ、それにしたって数百クロックのディレイだから、ちょっと大きすぎるんじゃないかな、という気がする。何が原因だろうか。

　STBee F4miniの回路図を見てみると、USB周りはSTBee(STM32F1)とかに比べて非常に簡略化されている。F1はUSBを使うのにトランジスタ等を使った外部プルアップが必要だった。F4はダンピング抵抗で直結されてるだけ。
　ただし、PA10(USART1.RX)がUSB IDに直結されていて、ここは注意する必要がある。基本的にUSB IDはフロートなので無視していいが、USB OTGケーブルを差し込むとIDがGNDに短絡するので、USART1に接続している相手側のTXがGNDに短絡することになる。これの対策としては、1) 基板のパターンを削ってしまう 2) USB OTGケーブルを使用しないように注意する のいずれかしか無いと思う。どっちも嫌な感じ。

　しかし、今回問題になっているのはPA9がPA12に流れ込んでいる、という点であり、PA10はどうでもいい。回路図を見た感じではPA9とPA12には何の関係もなさそうだし、たかが50kHz未満の信号が隣のパターンに回り込むはずもないだろうし。

　ということで、今のところこの問題は謎のまま。今週はSTMに触りすぎてるので、もうちょっと時間を掛けてゆっくりと解決したい感じ。


　ところで、CDCってCommunication Device Classの略なんだけど、アクション映画とかよく見る人間としては、アメリカ疾病予防管理センター(Centers for Disease Control and prevention)のほうが強く連想される。よくゾンビ映画とか、ウイルス系のなんやらで出て来る機関。

　あと、最近のTeraTermって接続断しても自動的に再接続されるのね。昔は手動で切断→接続をやる必要が有った気がする。あと運が悪いとPCを再起動しないと再接続できなくなるような問題も有った気がする。
　マイコンのUSBでVCPを使うと再接続の手順が非常に面倒でデバッグに向かない、と思っていたけど、自動で再接続されるならUSBを使うのもありかなー。


追記
　オシロで確認してみました。赤がUSART1.TXで、黄がUSB D+です。

極めてアナログ的な波形ですね。
　傾向としては、USART1.TXから6usec程度遅れてUSB D+にも現れている感じです。立ち上がりが急峻で立ち下がりがゆっくりなのは、I2Cを始めとしたプルアップ系のアナログ波形とは逆の動作です。
　アナログ的な部分を見る時は、ロジアナだけでは足りませんね。ま、今回はオシロで見たところで何か改善するわけでもないですが。