網絡管理測試中會測試第一幀網絡管理報文的外發時間，即網絡的啟動時間。一般需求會明確外發第一幀網絡管理報文的閾值時間（TPowerWakeUp），比如：150ms，容差10%，即最大165ms。1ECU啟動流程

我們先明確這150ms要耗費在哪里，ECU從被供電到程序穩定運行會經過硬件啟動->Boot啟動->Boot運行->App啟動->App運行這幾個階段，如下所示：

HW Startup:此階段完全由硬件特性決定，軟件層面沒有優化余地。此階段包括VCC供電（比如：KL15上電），之后ECU對應的5V、3.3V及1.25V電源管理模塊上電。5V一般給IO使用，3.3V一般給Flash使用，1.25V一般給CPU內核使用。

Bootloader Startup：此階段一般是Bootloader使用外設資源的初始化，比如IO、System Timer、CAN等模塊的初始化。

Bootloader running：此階段，會判斷程序是否需要更新，如果沒有程序需要更新，Boot程序會停留一段時間，比如：20ms，這就是前面聊的

Stay In Boot

功能，可以回顧

UDS之刷寫：你真清楚Application和Bootloader如何溝通？

因此

Stay In Boot

耗費的時間無法避免。

HW,OS,Application Startup：此階段包含應用所需外設資源的初始化，OS的初始化以及各軟件模塊初始化。

提示：如果Boot程序是security boot，可能耗費的時間更長，當然需求也會明確security boot的啟動時間。

2

TPowerWakeUp測試步驟

關閉網絡仿真（上位機不模擬網絡管理報文發送），關閉供電電源；

開啟供電電源（一般指KL15上電），觸發DUT在該網段上通信（硬線喚醒或者網絡喚醒）。當KL15電壓達到6V時作為起始時間，MCU通常為5V供電，將此刻記為T1；

等待DUT在該網段發送第一幀報文，將此刻記為T2；

檢查是否(T2-T1) < TPowerWakeUp。

3

工程實例

在這里分享一個工程Bug實例：測試TPowerWakeUp時，在沒有security boot情況下，TPowerWakeUp高達200ms，遠大于150ms。實際測試TPowerWakeUp＜165ms即可，要考慮10%偏差。

問題解決切入點：

1、SPI速率使用不當帶來的延時

CAN模塊對應的收發器使用的是NXP TJA1145，該收發器需要通過SPI控制其模式切換。問題出現前使用的波特率是100Kbps，通過提高通信速率，優化了＞30ms時間。NXPTJA1145速率提升到4Mbps，查閱其用戶手冊可以看出，NXPTJA1145在Normal/Standby模式下，其時鐘周期可以配置為4Mbps(1/250ns = 4000000Hz)。如果考慮Sleep Mode，至少也可以配置1Mbps，這樣也能提升10倍通信速率。

2、PORST Pin配置參數修改

一般來說，ECU從被供電那一刻，即VCC（12V）供電，VCC會瞬間拉到穩定，幾乎不耗費時間。而5V、3.3V、1.25V一般在同一時間點，電壓開始爬升，耗費的時間相差不大，一般會在幾個ms量級，即T1時刻，比如3ms左右。這幾個電壓耗費的時間是物理特性，沒有優化余地。但是PowerOnPin這個電壓值可能由配置決定，通過修改外圍供電芯片可修改該Pin的供電時間。我在項目實際中確實碰到了這樣的設計，通過配置外圍芯片配置，PowerOnPin的供電時間由十幾ms降低到3ms左右，又優化了近10ms的啟動時間，即優化T2時間。

綜上所述，帶來的思考點有：

使用了SPI的外圍器件，先確定其最大支持的通信速率，橫向對比，使用UART的地方是否也可以提高通信速率；

特定器件的配置是否設計時間配置。

最后說一下，這些時間是如何測量的，本文在目標代碼位置反轉IO電平狀態，使用示波器測量，這樣即可知道代碼，函數耗費時間情況，進而針對性的優化。



審核編輯：劉清