HardcoreAI
Firmware intelligence platform
One week ago I posted about HardcoreAI here and got incredible feedback from this community. Thank you — genuinely.
You told me the most painful parts of embedded development:
Clock tree configuration on STM32H7 that silently breaks peripherals
DMA setup where one wrong transfer size bricks the board
I2C address conflicts that take hours to trace
Errata bugs documented nowhere except page 847 of a reference manual
Every single one of those is now in our fault decoder.
What changed since the last post
We took your feedback and shipped.
The workflow now:
Research first. Generate second. Flash last.
Upload your datasheet and errata. HardcoreAI indexes everything — reference manual, errata, schematics, vendor docs — before generating a single line of code. Every generated line cites the exact page and register it came from. On fault, it reads CFSR, HFSR, BFAR, MMFAR directly, maps the fault bits to the exact peripheral configuration that caused them, corrects, and reflashes automatically.
We caught a clock tree conflict on STM32H7 where the documentation said the configuration was valid but the fault decoder flagged it as physically impossible on that silicon revision. That is the class of bug this exists to catch.
Pricing — straightforward and honest
Free Launch Offer — $0
1 complete embedded project workspace. MCU reference manual indexing. Hardware constraint mapping. Ground-truth firmware generation. No credit card. No waitlist.
Try it: hardcore-ai-inky.vercel.app
Individual Developer — $30/seat/month
Unlimited projects and workspaces. Multi-thousand-page vendor RAG. Register and clock constraint engine. Priority execution and support.
For professional firmware engineers building production products.
Reserve: hardcoreai.in/#seat-survey
Engineering Teams — $25/seat/month
Everything in Individual plus shared team workspaces, centralized hardware rule index, and team license management.
For hardware engineering teams collaborating across schematics and firmware.
Reserve: hardcoreai.in/#seat-survey
Why we are moving to paid
Free users give you opinions. Paying users give you requirements.
We need requirements from engineers who actually ship embedded products for a living — people for whom a wrong register address costs a board respin, a week of delay, and real money. At $30/month, the tool pays for itself the moment it catches one configuration error before it reaches the board.
One prevented respin saves $10,000–$150,000. The math is not complicated.
The honest ask
If you tried HardcoreAI after my last post — email me directly. I want to know what worked and what broke.
sricharan.srikrishna@gmail.com
If you have not tried it — first project is free, no barriers.
hardcoreai.in
That’s the problem I’m trying to solve with HardcoreAI.
Give it the datasheet/reference manual and a real embedded task.
Instead of guessing registers or generating generic code, HardcoreAI researches the hardware context first, then helps generate and debug the firmware around it.
Today’s challenge:
Give HardcoreAI the messiest STM32/ESP32 firmware problem you have.
Wrong GPIO?
Clock configuration?
SPI/UART issue?
Register confusion?
Peripheral setup?
I want to see where it breaks.
I’m looking for 10 embedded engineers to try it on a real problem and give brutally honest feedback.
No pitch. Just technical testing.
Try it: https://hardcoreai.in/
I’m building HardcoreAI because I kept seeing the same problem in embedded development:
You have the board.
You have a 300–1000 page datasheet.
You know what you want the firmware to do.
But actually translating those registers, peripherals, timing requirements and errata into working firmware can take days — and debugging the wrong assumption can cost weeks.
So we built HardcoreAI — an agentic firmware intelligence platform that researches the hardware before generating firmware.
The workflow:
→ Upload/select your hardware
→ Research Mode — AI analyzes the datasheet and hardware documentation
→ Ask questions about registers, peripherals and configuration
→ Generate firmware
→ Build, test and iterate
We’re opening it up for developers to try.
If you work with STM32, ESP32, Arduino, PlatformIO or embedded systems, I’d genuinely love your feedback.
Try it here: https://www.hardcoreai.in/
What’s the most annoying part of embedded development for you right now?
-
1
The errata-handling questions above are the right ones, but I'm curious about a different failure mode: when you don't fully know what you want the firmware to do yet — you're still forming the requirement while reading the datasheet. Does Research Mode support that back-and-forth (question → partial answer → refine question), or does it assume the spec is fixed before you start? That back-and-forth is usually where the real time goes, more than the register lookup itself.
-
1
Well said .....it can do both based on the prompt
-
-
1
"Datasheet-to-firmware is a real time sink—I’ve seen teams burn weeks on register maps and errata. Automating that translation could cut bring-up from months to days, especially for niche MCUs. Curious: are you targeting devs already comfortable with embedded, or trying to onboard more generalists who find the datasheet barrier too steep?"
-
1
Trying to onboard devs with experience in embedded ,More than that we have made the abstraction layer so simple that even a prompt engineer can develop a deep tech prototype ,So its both ways a senior embeddeed dev can automate the work of a junior or a junior dev /prompt engineer can build prototypes faster
-
1
Interesting approach. I think the biggest value is not only making embedded development easier, but packaging expert workflows into an abstraction layer.
AI is powerful when it doesn't just generate code, but transfers domain expertise into a repeatable process. The challenge is balancing simplicity for new users while keeping enough control and transparency for experienced engineers.
Excited to see how this evolves.
-
-
-
1
The sharpest thing you've built is "research before generate," the only thing that makes AI firmware trustworthy. In embedded, a wrong register assumption or missed erratum can silently brick a board or hide a bug for weeks because the code "looks right." A confident wrong answer is catastrophic, not annoying, which is why devs don't trust code-gen for firmware.
So your wedge isn't "generates firmware faster," it's "reads the datasheet and errata first, so it doesn't guess." Errata handling especially, that's what eats weeks and no generic LLM accounts for. Show it catching a real erratum gotcha, that's the demo.
To your question: STM32 clock tree and peripheral init, one wrong prescaler means silence, no error.
When it hits an erratum contradicting the datasheet, does it flag the conflict or silently pick one?
-
1
it flags the conflict and you can ask specific questions to the research agent regarding its decisions and it will point out to the datasheet with citings for page numbers
-
1
That answer is your whole pitch, and I don't think you're treating it as one yet. "Flags the conflict, lets you interrogate the agent's decisions, cites the datasheet page number" isn't a feature, it's the entire reason a skeptical embedded dev would trust AI-generated firmware at all.
Here's why it's bigger than it sounds. The reason devs won't touch code-gen for firmware isn't that the code is wrong more often, it's that when it's wrong they can't see why, and a silent wrong register assumption costs weeks. Your citation-and-interrogation layer is a direct answer to that exact fear: the dev doesn't have to trust the output, they can audit the reasoning down to the page. No generic LLM does that. It can't, it doesn't have the datasheet grounding to cite.
So the demo that sells this isn't "watch it generate firmware," everyone's seen an LLM emit code. It's "watch it justify a non-obvious prescaler choice with a page citation, then watch it flag an erratum that contradicts that same page." A skeptical firmware engineer has never seen an AI do that, and it's the moment they stop seeing a toy and start seeing an auditable tool. Generation is table stakes now. The citation trail is the product.
Is that reasoning-and-citation view front and center when someone first tries it, or do they have to generate firmware before they discover it exists?
-
-
-
1
This is a huge pain point in embedded development. Reading through hundreds of pages of datasheets to get the configuration right can take forever. Really interesting approach to solving this!
-
1
Please use the tool mate
-
-
1
The interesting bit here isn't the generation, it's the errata — those are exactly the pages people skip and then lose a week to. Does Research Mode cite the specific datasheet page/register it based a decision on, so a firmware engineer can check it before flashing?
-
1
I started my career in mainframe integration, and the lesson that carried over: the documentation was never the source of truth, the running system was. So the thing that would make me trust this isn't datasheet parsing, it's the debug loop proving generated code against a real board. One video of it catching something like your page-247 UART clock bug on actual hardware would sell harder than any feature list.
-
1
ahh this addresses a real itch
-
1
looks good but nav is too many sections... Which looks bad. Put some main and dropdown. It will better.
-
1
sure will work on that on the next update
-
-
1
The "research the datasheet before generating code" angle is brilliant—that's where I always lose hours. Just signed up, excited to see if it actually saves me from the STM32 reference manual rabbit hole!
-
1
The datasheet-to-firmware gap is so real—glad someone's finally tackling it. I'd love to see how it handles ESP32 register configs; that's where I lose the most time.
-
1
Love this concept—reading 1000-page datasheets is genuinely the worst part of embedded work. Curious how it handles edge cases like errata or undocumented quirks that usually eat up debugging time?
-
1
This is such a pain point—spending hours digging through errata only to find out the register you needed was on page 600. Love that you're tackling it head-on with a research-first approach!
-
1
This is such a pain point—nothing worse than digging through a 500-page datasheet just to find one register offset. Love that you're tackling the research phase head-on; that's where most of the time actually disappears.
-
1
The datasheet rabbit hole is so real—spending hours hunting for one register bit that's buried on page 600. This looks like a solid way to skip straight to the good part.
-
1
This is such a real pain point—datasheets are brutal when you're just trying to get a peripheral working. Curious how you handle errata in the research mode, since that's usually where I lose days!
-
1
Love this — the "research before generate" angle is exactly what's missing from most AI coding tools. Datasheet spelunking is the worst time sink, so happy to see someone attacking it head-on.
-
1
Thanks for you’re reply
Please use the tool !
-
-
1
The datasheet rabbit hole is so real—this sounds like a huge time-saver for the "wait, which register was that?" moments. Curious how it handles conflicting info between the datasheet and silicon errata, that's always been my biggest headache.
-
1
This is such a real pain point—I've lost way too many hours cross-referencing obscure register bits. The research-first approach makes total sense, excited to see how it handles ESP32 edge cases!
-
1
Thanks mate ,Please use the tool and let us know
-
-
1
Datasheets are the worst part of embedded work, hands down—this sounds like a lifesaver for those "wait, which register was that again?" moments. Excited to see how it handles the ESP32's inconsistent docs!
-
1
The "research before generate" workflow is such a smart angle—so many devs get burned by AI hallucinations on obscure register details. Curious if you've tested it against some of the nastier errata cases yet?
-
1
This is such a pain point—I've definitely lost days to datasheet rabbit holes. The research-first approach sounds like a game-changer; can't wait to try it with my ESP32 projects!
-
1
This is such a real pain point—digging through 1000-page datasheets for one register value is brutal. Love that you're putting the research phase front and center instead of just generating code blindly.
HardcoreAI is now live.
The reason we built it is pretty simple: firmware development isn't just writing C.
A lot of the actual work is figuring out what the hardware expects — datasheets, reference manuals, registers, clock trees, pin mappings, peripheral configuration, and then figuring out why something that compiled still doesn't work on the board.
The workflow we've built is:
Select Target Board → Research Mode → IDE Mode → Generate → Test → Run → Debug
Research Mode is used to understand the hardware documentation and project context before moving into the IDE. The goal is then to take the generated firmware through the actual build, execution and debugging loop.
It's currently available for STM32 and supports 1,500+ boards through PlatformIO.
HardcoreAI: https://www.hardcoreai.in/
It's free to try for the first project.
I'm mainly looking for people to use it on real firmware problems, not toy examples. If you have a difficult peripheral configuration, DMA issue, clock problem, interrupt bug, hard fault, or something else you've been putting off debugging, that's exactly the kind of test we'd find useful.
If you try it, I'd genuinely like to know where it succeeds and where it fails.
-
1
If you're launching your product, you might want to try Launch Nest. It’s a place where founders can launch products for free and where users can discover new tools and startups.
And the best part: you can earn credits and use them to get your product featured for free.
-
1
The Research Mode → IDE → Test → Debug flow is what stands out. It suggests the product is trying to cover the actual firmware workflow rather than just generate code.
6 Comments
This comment was deleted 5 days ago