こーゆうコードって、自分だと

begin()
{
hookの設定
GPIOの設定
}

end()
{
GPIOの設定
hookの解除
}

と対称的に書いてしまうんだけど、このコードは何か意図があってGPIOの処理をbegin()/end()ともに最初にやっているんだろうか。むー。

https://github.com/juribeparada/STM32F10X_Lib/blob/1debc23063f3942608e2bd62d04d5e1249c47fa3/usb/usb_serial.cpp#L50

STM32F103のGPIO PA11/12とUSB D+/D-ピン、GPIOのpin configurationのAlternateFunctionで切り替えるのかと思っていたんだけどどうも自動的に切り替わる…ってこれ本当なんすか？

> once you enable the USB module, PA11 and PA12 automatically are "hijacked" by the USB module. input/output mode or AF doesn't matter.

http://www.chibios.com/forum/viewtopic.php?t=4586#p32541

//Pin PA11,PA12=LOW, USB Resetの項目は活かして、LONG_USB_RESETの有無は今後評価するとして、その後のところは削除で良いんだと思う。

config/ZUMspot_USB.hからSEND_RSSI_DATA, SERIAL_REPEATER(_BAUD), LONG_USB_RESET, ENABLE_DEBUGを除いて、上の改造を施している。他のconfigだとどうなるかも調査が必要かも。

とりあえず一歩進んだか。

https://github.com/juribeparada/MMDVM_HS/blob/master/IOSTM.cpp#L327 Mode_IN_FLOATINGの設定を行わせないようコメントアウトすると動くようになる。

逆に、LONG_USB_RESETの前にあるMode_Out_PPの設定を行わせないようコメントアウトすると（Bit_RESETの有無は関係ない）動かない。

bootloaderの、GPIO_Pin_11/12のこの辺の設定がどうなっているかを一度確認してみる必要があるかも。

メモ：USB Full-speedはD+を、Low-SpeedはD-を1.5kΩでpull-up（本当はUSB仕様書を見れば良いけど面倒なのでこっちにリンク）

https://www.macnica.co.jp/business/semiconductor/support/faqs/silicon_labs/109673/

STM32F103内部にあるGPIO pull-up/downは30k～50kΩくらい。代用にはならないはず。

https://www.st.com/resource/en/datasheet/stm32f103c8.pdf

おはよーございます。

ちょっとまだ試していないんですが、多分この辺が怪しい気がします。

https://github.com/juribeparada/MMDVM_HS/blob/master/IOSTM.cpp#L311

GPIO11/12のMode_Out_PPを設定したら、USB-CDCの初期化をすべて完了した後にMode_IN__FLOATINGにしないとマズいんじゃないかなあと考えています。

この想定が正しかったとすると、とりあえずの修正は可能そうですがSTM32Libと連携した修正を考えると厄介です…

bootloaderはちゃんと接続/解除を制御している感じなので、「何か」はあるんだと思う。

という訳で寝ます。Twitterと違って長々と書けるから考えをまとめるのが楽だ。

generic_boot20_pc13_long_rst.bin
ZUMSPOT_ADF7021
LONG_USB_RESETは指定せず

この組み合わせでも、GPIO_WriteBit(GPIOx, GPIO_Pin, Bit_RESET)の有無に影響しない。

USBモジュールの初期化がきちんと行われてからPC側にデバイスの存在を通知すりゃいいんじゃね？と思っているのだけど…

https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/config.h を見るに、TARGET_GENERIC_F103_PC13ではUSB_DISC_BANK/PINが未定義になっているのでGPIOでの制御はしていないと考えるべきか？（USBモジュール側の操作で完結というかなんというか）

今テストした組み合わせ（動いてない）

generic_boot20_pc13_long_rst.bin
LIBRE_KIT_ADF7021
LONG_USB_RESETは指定せず

JumboSPOTってZUMSPOTの完全なコピーなのかなあ。それとも一部だけな（改変してる箇所がある）のかなあ。回路図があれば良いんだけど…

STM32F10X_Lib/usb/usb_cdcacm.c、usb_cdcarm_enable()のGPIO_WriteBit(GPIOx, GPIO_Pin, Bit_RESET)をコメントアウトしても何も起きない。…となると、一体どこでUSBデバイスとして接続されたことをPC側に通知する(D+/D-のpull-upだかdownだかの制御をしている)んだろ？

もう一つ分かっているのは、ST-Link経由で給電している場合はUSBポート側で抜き差ししてもPC側ではMMDVMの存在をちゃんと検出できるのに対し、USBポートのみ使う場合はbootloaderのみ検出できる。なーんかヘンなバグが居る。

で、購入時のファームウェアは問題ないんだけど何故か今は配布されていない、とか。

LONG_USB_RESETの有無は（今のところ）関係なさそう。USBアナライザで見たところでは、bootloader→MMDVM_HSに切り替わった直後のUSBリクエストにだんまりを決めていることは分かっている。

bootloaderはgeneric_boot20_pc13.binではなくgeneric_boot20_pc13_long_rst.binを使った方が良さそう。Maple純正でも試してみたいけど、FlashROMの空きが無いのでできない。