AI工具导航

HardFaultHandler

为你的 AI 编程智能体聚焦真实硬件

HardFaultHandler 是什么?

HardFaultHandler(HF·NODE)是一款面向嵌入式开发的外部调试硬件,让 AI 编程 Agent 真正"看见"真实电路板。它无需 SDK、无需改动代码,即可实时监控 GPIO、ADC 与电源轨,读取 CPU 与寄存器状态,区分板卡死机与彻底损坏,捕捉固件"跑歪不崩"的隐蔽故障,并支持远程 OTA 升级与回滚。这样一来,嵌入式开发可以完全交由 AI 自主完成,从异常检测到变砖修复,全流程无人值守。

产品详细介绍

为你的 AI 编程智能体聚焦真实硬件

HardFaultHandler(HF·NODE)是一款面向嵌入式开发的外部调试硬件,让 AI 编程 Agent 真正"看见"真实电路板。它无需 SDK、无需改动代码,即可实时监控 GPIO、ADC 与电源轨,读取 CPU 与寄存器状态,区分板卡死机与彻底损坏,捕捉固件"跑歪不崩"的隐蔽故障,并支持远程 OTA 升级与回滚。这样一来,嵌入式开发可以完全交由 AI 自主完成,从异常检测到变砖修复,全流程无人值守。

定价方案

需要付费
官网查看
定制方案
  • 暂未采集到具体套餐,价格以官网为准

创始人评论

sarvesh dhar
sarvesh dhar创始人

它解决了什么问题?

如今每款 AI 编程工具写嵌入式代码的方式都如出一辙:它推理应该发生什么,然后交给你一段"可能能跑"的代码。它没有寄存器状态,没有电源轨电流,没有 GPIO 时序,甚至不知道上一次烧录的固件到底有没有跑起来。它只是在流畅地猜测。对 Web 代码来说这还能凑合,因为 Agent 会跑测试、读报错、然后自我修正。但对固件而言,根本没有报错可读,因为没人盯着硬件。这个回路是断开的,而人充当了传感器,手动回报板子的实际行为。HardFault 把这个回路闭合了——烧写、烧录、观察、验证、回滚,全部针对真实芯片运行,并且把观察这一步自动化了。

第二个问题是,嵌入式团队没有软件团队习以为常的任何东西。没有预发布环境,没有每次提交的 CI,没有错误追踪,没有一键回滚,没有默认的可观测性。于是行业纪律就变成了:开发几个月,做到非常稳定,再投放现场,因为现场迭代的成本高到几乎被禁止。这种谨慎不是严谨,而是大家都习惯了称之为"严谨"的工具缺失。

第三,一个报废的现场设备是不可恢复的。它停止上报,这就是你的全部信号。你分不清它是真的死了还是卡死了——这两种是完全不同的修法,但从服务端看一模一样。你看不到它静默前几分钟发生了什么。你也无法重新烧录它。得派人开车过去,或者整机替换,或者它就这么一直死着——在十个设备的试点中,几块"砖头"就能决定试点是能转化还是会悄无声息地结束。

第四点,也是其他工具都抓不到的一点:固件跑错了但不崩溃。崩溃类工具已经很成熟——core dump、fault handler、看门狗追踪,全都依赖一个失败信号。当没有失败信号时,整整这一类工具都成了瞎子。设备上报空闲,电源轨显示 82mA,你的整个技术栈没一个注意到其中的矛盾,因为没有任何东西把这两条事实摆在一起对比。没有崩溃,没有日志,没有告警,就这样出货了。

这四个问题的底层是同一个约束:你一旦为了捕捉间歇性 bug 而给固件加上埋点,时序就变了,bug 也跟着消失——所以 HardFault 完全独立于目标之外运行。不需要 SDK,不需要改代码,给被测设备什么都不加。它采集 GPIO、ADC 和电源轨,通过 SWD/JTAG 读取 CPU 和寄存器状态,跨启动、运行、睡眠和故障跟踪设备生命周期,并支持带回滚的 OTA 推送和远程恢复。然后它交叉比对固件声明的状态与硬件实际行为,把矛盾摆给你看。

---

你的思路或过程是如何演化的?

我一开始做的是错误的产品。V1 是个远程调试探针——远程烧录、戳一下、读寄存器。有点用,但不是任何人买单的理由。转折点出现在我不再把电源轨当作另一个传感器通道,而是开始把它当作证人。固件会撒谎说自己处于什么状态,电流消耗不会。产品不再是远程访问,而是拿证据去交叉核对声明,其他一切都从这个转变衍生出来。

然后 AI Agent 来了,买家变了,产品没变。我原本是为人类搭了一层观察层,但我真正建出来的是一个"真值源",而真值恰恰是自主 Agent 缺的东西。同样的硬件,同样的测量——只不过不再是凌晨一点由人去读仪表盘,而是变成一个无人值守循环里的验证步骤。我有意把它保留为一个平台,而不是某个 Agent 的插件。测量本身才是资产,Agent 只是它的一个消费者。

我还干过一件事:在产品还拿得出手之前就开卖。冷邮件,仔细的定向,重写的文案,更多的列表。零回复,一个都没有。我一直在优化话术,而真正的问题是我在让硬件工程师——世界上最讲证据的一群人——接受一个没有任何东西可看的声明。再多的话术也补不上缺失的实物。我彻底停掉了外联,转头去搭演示。这次发布,就是认了这点之后的下游产物。

我不再把产品交给陌生人了。早先只要有人点头,我就递一台出去。现在是先签 NDA,要求合作伙伴有真正的承诺,八周结构化反馈,最后产出一份具名的案例研究。试点更少,但深得多。第一台设备已经随一个位于 [Noida] 的 IoT 团队出去了,现在路线图上大部分东西,都是从这一次合作里长出来的,而不是我事先规划出来的。

元教训是:我花了三个月优化设备本身,却几乎没有花时间想清楚会不会有人相信我。这两件事本该从第一天起就是同一个项目。

HardFault Handler 以一个电池供电的无线设备形态独立于你的板子之外——不需要 SDK,不需要改代码,目标上一无所加。它采集 GPIO、ADC 和电源轨,通过 SWD/JTAG 读取 CPU 和寄存器状态,跨启动、运行、睡眠、故障跟踪设备生命周期,并保存事件发生前的证据,让你不用对着"尸体"瞎猜。它能区分真正死掉的设备和卡死的设备,并支持远程烧录、回滚和恢复——所以客户现场的一台坏设备不再意味着一天的差旅。兼容 STM32、ESP32/ESP8266、Arduino/AVR、Silicon Labs EFR32、Nordic nRF52 以及 TI。

AI 分析建立在设备自身采集到的测量之上,这正是它也能作为 AI 编程代理之眼的原因——烧写、烧录、观察、验证、回滚,全部针对真实芯片而不是仿真器。

它还在 Beta 阶段,我想让它被狠狠地踢。试点以借出硬件的形式发货,没有预付费用。如果你现在正在把硬件调起来,告诉我最后一个让你浪费了一周的 bug——那种间歇性的、一上调试器就消失的、只在现场才出现的。我想知道这个东西能不能抓到它,同样也想听它抓不到的那些情况。

创始团队

sarvesh dhar
sarvesh dharDebugging embedded without guesswork