Solved! Go to Solution.
Hi @sensen_1,
I imagine you mean 2ms and 4.5ms for the response after a reset, correct?
You could try skipping most initialization until after you respond to the UDS. For example, check for a functional reset with Power_Ip_GetResetReason() API. After this, don’t switch to FXOSC/PLL until after the first UDS reply. FIRC is available quickly by default; FXOSC stabilization and PLL lock could cause additional overhead when initializing.
You can also try sending an NRC 0x78 (ResponsePending) command before issuing the reset to buy some time to respond to upper computer.
Best regards,
Julián
Hi @sensen_1,
I imagine you mean 2ms and 4.5ms for the response after a reset, correct?
You could try skipping most initialization until after you respond to the UDS. For example, check for a functional reset with Power_Ip_GetResetReason() API. After this, don’t switch to FXOSC/PLL until after the first UDS reply. FIRC is available quickly by default; FXOSC stabilization and PLL lock could cause additional overhead when initializing.
You can also try sending an NRC 0x78 (ResponsePending) command before issuing the reset to buy some time to respond to upper computer.
Best regards,
Julián