無駄な３６Ｈの原因は［１８］

STM32ポエムです．

多忙な折ですが、謎のbugで３６Ｈ無駄にしました．

開発しているのはUSB deviceです．そのUSB codeは、STM32CubeMXが吐き出す雛形codeを改造してSTM32F401で動かして実証済です．

その後、targetをSTM32H723Zに変えて同じことをして動かしてみる・・・だがHOSTがtimeoutして停まってしまう．状況は、F401なら動くがH723では動かない、なのです．

F401改造前／F401改造後／H723改造前／H723改造後　の４パターンを動かしてみると、H723改造後は動かない．

F401とH723のUSBの雛形codeを比較したけど差異なし．

さらに付随する状況が在って、Linuxではある程度認識するが、winでは認識しないレベルだということ．Linuxではlsusbまでは通るんです．でもwinでは「descriptor読めない」エラーで停まってる．（たまに読めることもある）

改造でdescriptorが壊れたのかと調べたが問題なし．

Linuxでlsusb -vと詳細表示させると、最後にUSB statusを読めなくて20秒ぐらいしてtimeoutするという状況なので、USB statusコマンドとやらが原因なのかと考えました．それでSTMでUSBコマンドを表示させたけどそれっぽい物を発見できず．

wiresharkで飛び交うUSB packetを読もうとしましたが、wiresharkを使うのは苦手なので打ち切りにしました．わたしはwiresharkを使う域に達していません．

ここで、F401改造前／F401改造後／H723改造前／H723改造後　の４パターンをもう一度試してみろとゴーストが囁きます．するとなんということでしょう、４パターン全てが動く．最初の頃に試した時とは違う結果なのですがさておく．

ということは、H723にゴテゴテ拡張した機能が悪さをしているのではないかということで、機能を１つ１つ止めてみる．

ついに原因判明．

　struct ADCdata ad[18];

とすべきところを、

　struct ADCdata ad;

にしちゃってました．別件のcodeと融合したときに間違えました．

memoryを壊しまくって、その癌細胞が偶然USB IFへ転移して死亡してました．

ちなみにadのサイズは6kBぐらいあるので、１個と１８個ではRAMの逸脱量が100kBもあったのです．もっと判り易い死に方で早死にして欲しかった．こんな巨大bugが数日間もbuild errorを出さなかったのは何故かというと、ad[i]でアクセスせずに、ポインタでアクセスしていたからでした．

３６Ｈが超もったいない．

かしこ