Group Actions
Engagement
  • Author Author: Moussa1492
  • Date Created: Date Created
  • Views 24 views
  • Likes 1 like
  • Comments 1 comment
Related
Recommended

Validating an idea: a tool to explain STM32/Cortex-M HardFaults more clearly

Moussa1492

Hi everyone,

I’m working on a small tool idea around STM32 / Cortex-M debugging, and I’d like honest feedback before building too much.

The problem I’m trying to validate is this:

When a Cortex-M firmware crashes into HardFault_Handler, many students, junior developers, and even intermediate embedded developers struggle to understand what actually happened. The data is usually there — CFSR, HFSR, BFAR, MMFAR, stacked PC, LR/EXC_RETURN, stack frame, GDB logs — but interpreting it correctly is not always obvious.

The idea is not to build another IDE or replace STM32CubeIDE, VS Code, Ozone, or GDB.

The first version would be an offline analyzer:

  • input: .elf file, GDB log, register dump, stack dump

  • output: a clear report explaining the probable fault cause, source line if available, decoded fault registers, and suggested next checks

Example use case:

  • firmware crashes into HardFault

  • developer copies the relevant GDB/register dump

  • tool generates a readable diagnostic report

I’m especially interested in whether this would be useful for:

  • STM32 learners

  • embedded training centers

  • university labs

  • junior firmware developers

  • small teams without a Cortex-M debug expert

A few questions:

  1. When you hit a HardFault on STM32/Cortex-M, how do you debug it today?

  2. Do tools like Ozone, CubeIDE, Cortex-Debug, or your own scripts already solve this well enough?

  3. Would a readable diagnostic report save time, or is this not a real pain point?

  4. Would this be more useful as:

    • a CLI tool,

    • a VS Code extension,

    • a training/teaching tool,

    • or just documentation/tutorials?

  5. For educators: would structured HardFault/BusFault exercises be useful in embedded courses?

I’m not trying to sell anything at this stage. I’m trying to understand whether the problem is real enough before investing more development time.

Brutally honest feedback is welcome.

  • I think it should definitely be a VSCode extension. Getting people to use another tool, that doesn't integrate well with their workflows, is unfamiliar, etc, is a big hassle. With a VSCode extension, you'd have a bunch of existing tooling to build upon, simple to install, integrates well, no need to install a separate program.

    I don't have any Cortex-M debugging experience at all, so if an extension existed that could just magically tell me what went wrong, give me a call stack, jump to the specific lines in source files, maybe even give some plain English description for common issues, that would be a really cool and useful tool.