HardFault Handler

RE: HardFault Handler

inspiringdev123 — Tue, 17 Feb 2026 16:27:08 GMT

Global Memory

RE: HardFault Handler

Vidar Berg — Tue, 17 Feb 2026 16:25:24 GMT

Great to hear! Was this buffer on the stack or in static (global) memory?

RE: HardFault Handler

inspiringdev123 — Tue, 17 Feb 2026 16:22:02 GMT

Found a buffer overflow. Thanks guys!

RE: HardFault Handler

Vidar Berg — Tue, 17 Feb 2026 16:21:06 GMT

[quote userid="116423" url="~/f/nordic-q-a/127040/hardfault-handler/561380"]I enter the LR address (0x00044343) into the memory search and my Segger Embedded Studio crashes. [/quote]

That sounds like a bug in Segger embedded studio. Not sure what version you are using, but I haven't experienced this myself.

[quote userid="18935" url="~/f/nordic-q-a/127040/hardfault-handler/561381"]Does not mean much. Stack based buffer overflow can also destroy the LR saved on the stack - we have no idea if that value was vaild or not.[/quote]

I didn't suspect a stack buffer overrun in this case because it's only the stacked PC value that is obviously corrupted, so I think checking the LR or inspecting the full call stack is a good first step.

RE: HardFault Handler

Turbo J — Tue, 17 Feb 2026 15:37:14 GMT

Does not mean much. Stack based buffer overflow can also destroy the LR saved on the stack - we have no idea if that value was vaild or not.

RE: HardFault Handler

inspiringdev123 — Tue, 17 Feb 2026 15:27:13 GMT

I enter the LR address (0x00044343) into the memory search and my Segger Embedded Studio crashes.

RE: HardFault Handler

Vidar Berg — Tue, 17 Feb 2026 08:52:17 GMT

Hello,

Yes, the PC address explains why the fault exception was raised. Did you try looking at the stack trace to trace back to where the error occurred? You can also check the LR address. Hopefully, that will show where the branch to this address was made. It's possible that a corrupted function pointer is being called.

Best regards,

Vidar