Knowledge Base
Last Updated: 2026-07-02
NRC 0x78 indicates that the ECU accepted the request but still needs time before returning the final response.
It commonly appears during erase memory, download, or other heavy operations where the ECU cannot return a positive response immediately.
The real problem is usually not the 0x78 itself, but whether the client waited long enough and what the ECU emitted after that pending response.
Rebuild the timeline around the pending response and confirm whether the session ended with a positive response, another negative response, or a transport-level interruption.
This is especially important when a diagnostic tool reports a timeout without preserving the lower-level exchange.
Some tools collapse a long pending phase into a single timeout message, which hides whether the ECU kept responding correctly or whether the transport path died first.
If the capture includes repeated 0x78 responses, compare spacing and final outcome instead of assuming every pending loop means the ECU is healthy.
The key evidence is the request that triggered the pending state, the number of pending responses, the gap between them, and the first response that breaks the loop.
That final transition often reveals whether the issue is ECU-side processing, tester impatience, or a broken session after erase or download starts.
These examples are drawn from real capture files available in the project evidence pool. They give the article something stronger than generic protocol theory.
ADC log extraction with repeated pending states on multiple SIDs
Evidence reference: EVID-NRC78-ADC-PENDING-01
Node roles in this case
A long v3 DoIP capture where response-pending appears in more than one stage, which makes it a useful anti-misread example.
Evidence signals
Timeline
This supports the KB claim that NRC 78 should be read as a state transition problem, not as a binary success-or-failure marker.
A clean readout window later transitions into pending before recovering
Evidence reference: EVID-LATE-PENDING-SRS-01
Node roles in this case
A short derived window from a longer real capture that shows a normal read sequence entering repeated pending states before a positive response returns.
Evidence signals
Timeline
This is a strong public-safe sample because it teaches the pending-state concept without requiring brand-specific addresses or full vehicle context.
A long pending phase can branch into a harder failure instead of recovery
Evidence reference: EVID-NRC78-FAILURE-BRANCH-01
Node roles in this case
This case fills the key missing contrast for the NRC 78 page. The same workflow that spends a long time in Response Pending does not recover cleanly; it later surfaces a harder failure condition instead.
Evidence signals
Timeline
With this sample, the NRC 78 page can now show both branches: pending that eventually recovers and pending that turns into failure.
These are the interpretation traps that real packet evidence helps avoid.
Use nearby guides to move from protocol filtering to root-cause troubleshooting without leaving the knowledge base.
No. It often means the ECU accepted the request but needs more time. The important question is what happened after the pending phase.
Many tools collapse repeated pending responses into a generic timeout and hide whether the ECU later returned success, a new failure, or nothing at all.
Best when a flashing or erase operation stalls and the tool only shows a timeout.
Browse all seeded guides