號呆鵝的操盤室

這篇終於不用驗屍，可以DEMO了，我終於完成地下室飆車的心願了 XD 在STM32中間人對速度封包動點手腳，邏輯很簡單，速度給他+100就可以了 Video demo： 地下室用時速120過彎 感謝閱讀，買車兩年多，終於踏入CAN開發的入門磚

給開發板做個家 亂成一團的設備也是Bug來源，我請收納專家（老婆）幫忙改善。收納真的是專業！ 開發板的針腳插入泡棉當底座，底座再用熱熔膠貼在盒子裡 專家：網購的紙箱都是用熱熔膠固定，唯一答案 杜邦線用束帶固定在盒子邊緣 專家：這種紙不能用膠帶黏，束帶才是正解，還可以反覆調整 在盒子挖洞固定OBD-II頭（熱熔膠固定），以及走USB線 MCU開發板，供電和燒錄用 OBD-II供電，5V轉12V給設備用 樹莓派供電 這篇文章最後的結論：樹莓派妙用無窮！ 玩MCU還是要沾醬油（Data Sheet） 換STM32優點是環境單純，而且STM給了CAN驅動程式， 沾醬油(Reference Manual) 服用更美味，這份文件有1954頁。我想起十年前刻 S3C2410 bootloader 的往事， 整份datasheet 大概600頁我也幾乎讀遍，把peripheral driver全部寫一輪 開卷有益，我對CAN Bus又有一些新的了解，也修掉幾個Bug。底下文字我純粹留個紀錄，客官看看就好 STM32 boot code預設沒開CAN重傳，這個功能必須打開 封包從HUD轉發到汽車時，很有可能被忙碌的CAN BUS撞掉，需要重傳 如果沒開重傳，STM32發送失敗就會丟掉封包，於是HUD以為車子不理他 STM的register命名很爛：NART，No Auto ReTransmission 我自己寫軟體很注意 正向表列 ，0關閉，1打開，符合人類直覺才好debug 名字要正向表列才對，改成 EN ART（Enable Auto ReTransmission） STM32的CAN-TX很強，Mailbox能承受3個message排隊 直接發送封包即可，如果queue滿了軟體印條紀錄就好 拔掉畫蛇添的semaphore可以拔掉（沒寫他造成程式鎖死） STM32的CAN-RX也很強，有兩套FIFO，每套FIFO都能存3個message 基本上不大需要擔心buffer overflow STM32的CAN1/CAN2共享資源，需要透過CAN1幫CAN2設定Filter的起點和參數 他硬體就是這樣做，不知道就會卡很久 靈光一閃

Introduction 在學校念書時，課本都會把定理整理好，好似一切理所當然！我自己的經驗卻覺得過程應該是曲折的：比如我自信滿滿地寫了 驗屍報告 ，現在也要自信滿滿的推翻。我想工程師日常就是這樣：信心滿滿的提出proposal，傷痕累累的被打槍（重複以上過程） Anyway，真相只有一個，撐下去總是找得到答案！ 這系列文章我也希望呈現真實的開發過程（或著我很弱的事實），在混亂中匍匐前進 買新的軍火 我在 Mouser 買了 STM32 Nucleo F767ZI 開發板，這是一顆90nm的高階MCU Cortex-M7 @ 216Mhz，512KB SRAM，2MB Flash 處理器很快，記憶體很大，程式記憶體很大，程式亂寫也跑得完 3x CAN，USB 2.0HS，Ethernet 有三個CAN，可以在MCU裡面進行轉發 那天想玩USB和Ethernet也有得用 FedEx效率很高，禮拜五訂貨，下周二版子就從美國送到；加上淘寶買的CAN收發晶片，經過一番努力我終於搞定CAN轉發！示波器上看到延遲從400us壓縮到20us，我都流淚了 HUD不是被延遲打死的 轉發完要立刻上去測嗎？我隱隱約約覺得不安。如果HUD是因為中間人延遲，那直接對接Pi-CAR和HUD不就沒有延遲？這時候Pi-CAR的反應速度又是多少？ 下面這張圖黃色是HUD發出的詢問，藍色是Pi-CAR的回覆，兩個紅框是查詢和回覆，4ms = 4000us還是活的 把延遲弄得更誇張一點，Pi-CAR收到Query等0.1sec=100ms=100000us試試看，還是活著！！ 從美國買了兩片板子（湊免運）1500，搞了很久的STM32開發，結果方向又錯了，臉腫腫的。Anyway，我還是很喜歡這片開發板，MCU環境受控，Linux複雜難駕馭。我可以用熟悉的工具（J-Link Debugger）進行分析，而且他轉發快，我還是會繼續用下去 我把這套設備弄上車做實驗，果然還是點不亮HUD，所以我還是不知道HUD怎麼死的 反省與改進 如果是上班，通常我有第一個想法，我會找同事討論。很爛的想法一邊講會找到錯誤；講不順會知道哪裡沒想清楚；同事會從沒想過的觀點切入，又有機會精煉想法 不過搞車子不是搞專

本來想炫耀 地下室甩尾 的美技暫時碰壁了：我鼓起勇氣拿Pi-WIRE接HUD上車，結果HUD不會動，幸好車子還可以開，所以這是一篇［驗屍報告］ 我在紀錄檔看HUD發出封包，也有汽車的回應，應該不是通訊協定錯。直覺告訴我是中間人攻擊增加的延遲，讓HUD行為發生變化 先看延遲極小值 CAN@500kbps，一個8byte封包大概需要200us 1bit需要2us，8byte封包約100bits，t_pkg = 2us*100bit = 200us 中間人的延遲（t_delay）包括兩段：內部處理（t_mitm）和重新傳輸（t_pkg） t_delay = t_mitm + t_pkg t_mitm，中間人內部處理，想辦法壓低 t_pkg = 200us，重新發送封包也需要200us 除非用FPGA重新設計CAN controller，一邊收一邊打，不然躲不掉 HUD發出詢問速度，等待汽車回應，一共要承受兩發t_delay Before t_roundtrip1 = t_pkg + t_pkg = t_pkg*2 After t_roundtrip2 = (t_pkg + t_delay) + (t_pkg + t_delay) = t_pkg*4 + t_mitm*2 因為中間人增加的延遲 t_roundtrip2 - t_roundtrip1 = t_pkg*2 + t_mitm*2 以樹莓派來說，t_mitm的極小值是20us CAN控制器MCP2515，使用10Mhz的SPI介面 10Mhz，1bit = 0.1us 從MCP2515讀回和寫入100bits的極速都是10us，相加得到20us 假設HUD預期查詢要在1000us以內回覆 1000 = t_pkg*4 + t_mitm*2 = 800us + t_mitm*2 我得做到 t_mitm < 100us 才能讓HUD滿意 其實我不知道HUD的需求，反正這裡就猜猜看了 :-) 測量當前平台的t_mitm，並且努力壓縮他 第一版本軟體：Python-CAN，t_mitm高達1920us！！ 我很喜歡Python，寫起來簡單流暢，生產力很高，而且Python-CAN簡單優美不用折騰S

目的 借助Pi-WIRE的幫忙，在社區狹窄的地下室用時速120飆車，證明我高超的駕駛技術！ 惡搞HUD需要搞定Pi-WIRE和Pi-CAR。首先要弄清楚HUD和汽車的介面，我猜HUD是定期和車子詢問速度，所以我修改 第四篇 配置，把ELM327換成HUD，觀察Pi-CAR要怎麼回應才能顯示時速120： Before ELM327 ---- Pi-WIRE ---- Pi-CAR After-1 HUD ---- Pi-WIRE ---- Pi-CAR (report speed=120) 然後再把Pi-CAR換成真的車，讓Pi-WIRE竄改速度：把速度灌水100看來不錯 After-2 HUD ---- Pi-WIRE ( report speed = car_speed + 100 ) ---- XC60 (speed < 20) HUD逆向工程開始 配置妥當，Pi-WIRE開始監聽。歷史上CANBUS格式有兩種，舊年份Volvo使用29bit-ID，現在新車都是11bit-ID。HUD會發出兩種格式，查詢Service01 PID00，看哪一種有人理他，這樣就能判斷CANBUS版本（為什麼是7E8和18DB33F1，參考資料 ISO 15765-4 有答案） HUD會接下來查詢底下資料，只要讓Pi-CAR回應命令，HUD就會老實顯示速度了 01 00, supported PID in 01-20, 4byte bitmap 01 05, Engine coolant 01 0C, Engine RPM 01 0D, Speed 01 10, MAF air flow rate 01 20, supported PID in 21-40, 4byte bitmap 01 40, supported PID in 41-60, 4byte bitmap 我在家裡把HUD飆上180喔！ 逆向工程HUD，有趣的點 HUD啟動的機制 汽車發動電瓶電壓會瞬間下降，因為發電機運轉電壓上升 我轉電源供應器，發現HUD是偵測電壓上升開機 HUD關閉的機制 HUD接在OBD-II的頭，車子熄火狀態OBD-II不會斷電，HUD永遠上電 HUD讀到引擎轉