If a connected device fails, the evidence explaining why can be scattered across a bug report, a kernel log, a modem trace and a memory dump – and they won’t necessarily agree on when things happened.
Google’s own debugging documentation warns that Android system and event logs use one time base while kernel logs count seconds from boot, a gap that widens further across suspend periods. Engineers are advised to piecewise-register kernel logs between suspend entry and exit messages just to line the two up.
That is before a modem trace, memory dump or hardware measurement enters the picture.
It’s safe to say that software engineers are feeling the challenge: A Black Duck 2025 survey of 785 embedded-software professionals found that complexity of software, hardware or systems was the most commonly selected challenge to eliminating critical defects and vulnerabilities.
Plus, Electronic Specifier also found that about 20% of engineers it surveyed raised development-complexity problems related to software complexity, toolchains and debugging as one of their top challenges.
With this, and as a device’s fault can surface in one layer while its cause sits in another – a problem three startups are now trying to hand to AI.
logcat.ai correlates the diagnostic artifacts a device leaves behind, BKPT Labs makes firmware’s actual execution queryable, and YProbe brings physical board measurements into the investigation.
Each is built on the same premise: source code alone doesn’t always explain what a device did. The three startups approach the same visibility problem from different points in the stack.
Why do device bugs cross layers?
“A bug in an operating system rarely stays in the layer where you notice it,” Varun Chitre, co-founder and CEO of logcat.ai, a device-software debugging startup, told TechInformed. “You see something wrong in the framework and the cause is in a driver. Or it looks like a kernel fault and the actual problem is a subsystem below it.”
Chitre illustrated the problem with a device that runs warm and loses battery rapidly only on certain mobile networks. Its bug report might show that the application processor is failing to enter deep sleep, pointing engineers toward partial wakelocks and the application layer.
In his example, the cause sits lower down. A modem struggling with marginal signal repeatedly attempts network registration. Those retries generate kernel-level wakeups that keep waking the application processor.
Proving that sequence requires the Android bug report, kernel wakeup and suspend data and a modem trace from the same period.
“That’s three specialists and three toolchains, and most of the time goes into establishing that the layers are even related,” Chitre said.
Arm has drawn a similar distinction between reading code and observing software as it runs. When the chip designer introduced Dynamic Insights for Arm Performix in August, it said AI coding assistants can analyze source code but cannot infer everything from it. Some problems appear only when software is interacting with processors, memory, storage and other parts of a running system.
The three startups take that missing evidence from different places. logcat.ai connects diagnostic artifacts produced after something goes wrong. BKPT Labs records what firmware actually executed. YProbe takes the investigation onto the circuit board by feeding AI measurements from test equipment.
Each approach gives the AI a different view of what the device actually did.
What can AI learn from the evidence left behind?
logcat.ai starts with evidence the device has already produced.
Its Diagnose product accepts Android bug reports, logcat and dmesg output, modem traces, CAN bus captures and other diagnostic material. The company says its Delta mode can compare captures across devices, software builds or periods and correlate events across different system layers.
In Chitre’s battery example, an engineer could provide the bug report, kernel data and modem trace together instead of inspecting each separately. Delta would align their timelines and test whether processor wakeups occurred alongside modem-state transitions. With captures from multiple devices, it could also look for the same pattern elsewhere.
The result is what logcat.ai describes as a root-cause report with the supporting evidence attached. An engineer can inspect the events behind the diagnosis rather than receiving only the model’s explanation.
“The difference is you start from a substantiated hypothesis instead of spending the first three days working out whether the layers are related at all,” Chitre said.
The product still has boundaries. Diagnose is available today, but deeper runtime-to-source attribution remains a research preview and automated validation is still under development. On its website, logcat.ai describes Diagnose as forensic rather than a live-monitoring system. Chitre said it also does not replace interactive debuggers or hardware probes.
Engineers therefore remain responsible for checking the evidence, confirming the code path against their own software tree and putting any proposed fix through normal review and testing.
The approach also depends on what the device captured before the investigation began. BKPT Labs is trying to change what evidence is available in the first place.
What if AI could replay what the processor did?
BKPT Labs, an embedded debugging startup, is developing a system that records firmware execution and makes that trace queryable by an AI agent.
BKPT Studio is currently in private beta. The company says the agent can inspect the execution timeline, memory and symbols alongside source code, allowing it to query the captured execution rather than infer what probably ran from code alone.
A missed timing deadline is one example. BKPT says an engineer could ask why the deadline was missed and have the agent inspect which task was running, which interrupt service routine pre-empted it and how long each operation lasted. The answer remains tied to the trace.
That addresses a different problem from logcat.ai’s cross-layer correlation. Firmware can look correct in source code yet behave differently because an interrupt occurred at the wrong moment or operations happened in an unexpected sequence.
Source code records what the software was designed to do. The execution trace records the path it took.
The company says its tooling currently targets Arm Cortex-M development and works with standard debug probes. BKPT Studio remains in private beta, while ViewAlyzer and BKPT Debug are available for trial or licensing. The company’s BKPT #1 probe is also in private beta. The AI agent is optional, with the underlying trace and debugging tools still usable without it.
Both logcat.ai and BKPT operate around software and processor behavior. YProbe instead targets evidence produced by the board’s electrical behavior.
What if the answer is on the circuit board?
YProbe, a PCB debugging startup in invitation-only early access, is trying to give AI access to the electrical behavior of the board itself.
Its software imports a board’s netlist and bill of materials to map components, power rails and electrical connections. It can then connect to an oscilloscope, recommend which signal an engineer should probe next and update its fault hypotheses as measurements arrive.
YProbe’s public demonstration shows the system detecting a voltage drop when an Ethernet component wakes. Because another power rail connected to the same regulator has failed, the software directs the engineer to test that regulator next.
The example is a demonstration, not an independently documented customer failure. But the measurement itself illustrates what software evidence can miss: a voltage droop, missing clock edge or intermittent electrical connection may affect a device without appearing directly in source code or an operating-system log.
Physical measurements create another verification problem. YProbe says it checks whether a probe is making stable contact before accepting a reading, validates AI-generated component and net names against the imported board design and retains the oscilloscope measurement as the underlying evidence.
Is this becoming a wider engineering approach?
Larger engineering vendors are also connecting AI tools to evidence beyond source code.
Arm’s Dynamic Insights combines Performix profiling data with large language models and exposes that information to coding agents. Arm says its recommendations remain linked to the underlying performance evidence, allowing engineers to check whether an apparent CPU, memory or I/O bottleneck is actually present.
MathWorks has taken another route through Simulink Copilot and Polyspace Copilot in its 2026a release. Simulink Copilot grounds responses in engineering models and documentation, while Polyspace Copilot uses static-analysis results to help engineers interpret code defects and possible fixes.
Research into AI-assisted log analysis points to the same verification constraint. A 2026 systematic-review preprint covering 145 papers found that large language models can help combine evidence across sources, but identified hallucinations, context limitations, system drift and long-tail events as barriers to dependable use. The researchers emphasized grounding and verifiable outputs for real-world deployment.
What happens when the evidence isn’t text?
Device debugging adds another constraint: some of the evidence is not text to begin with.
“A general purpose model can’t read a memory dump, can’t correlate a modem trace against a kernel fault, and can’t match debug symbols to a kernel that no two vendors build the same way,” logcat.ai CTO Tarun Vashisth told TechInformed. “A ramdump isn’t text.”
Giving a model access to that evidence therefore requires more than putting a prompt around a general-purpose AI system. The approaches described by the companies rely on parsers, trace capture, timing correlation, board topology or test instrumentation to turn device behavior into information the model can use.
None removes the engineer from the process. BKPT Studio and YProbe remain early-stage products. logcat.ai’s deeper attribution and automated validation capabilities remain under development. Chitre said engineers should treat its findings as hypotheses, inspect the cited evidence and put proposed fixes through their normal review and testing processes.
AI coding tools can already inspect source code. Connected devices pose the harder problem: the evidence needed to explain a failure may instead sit in a modem trace, an interrupt timeline or a voltage rail.
Across the three products, the common design choice is to keep an AI-generated diagnosis tied to evidence an engineer can inspect, whether that evidence comes from logs, an execution trace or an electrical measurement.