STM32F103R8 - Random Hard Faults on simple(?) project

[m12lrpv]

Full disclosure. I'm new to STM32 and i'm porting from Arduino based 8 bit code to run on an STM32F103R8T6. This is on a manufactured / assembled PCB with supposedly genuine micro and not a random ebay blue pill board.

While debugging I'm getting random hard faults after about 30 seconds of runtime with no obvious reason why. I've selected the right device in CubeMX and presumed that the generated code would be correct.

To add to the strangeness when not running the debugger it takes longer before locking up.

To diagnose I've literally cut the project down to a LCD hello world project with a followup LCD print in a loop. Next step will be debugging via the toggling of a single pin.

I've read that hard faults are usually a memory issue and I'll admit I've not changed any project settings related to memory mostly because I have absolutely no idea how so technically i'm running the default settings.

In this instance though according to the stack trace I'm returning from a function that's simply toggling a pin. As far as I understand it from what i've read there is no way this should be causing a hard fault as it's completely unrelated to memory

I'm obviously hoping that someone can point me to what I might be doing wrong. Thanks in advance.

Edit:

Other properties at time of failure:

_rs_pin Pin is PB12

_rs_pin: 4096

_rs_port: 0x40010C00 // Is there are reference for checking these?

[Ozone]

Common causes for "random" crashes are stack overflows, out-of-bound array accesses, and dangling pointers.

You would need to check your source code for such issues, perhaps with the help of static code analysis.

Or with the help of the debugger.

[m12lrpv]

Unfortunately I'm not really in a position to be debugging ST's generated code. I don't have enough experience with the device in question or the architecture in general.

My source code has run flawlessly for more than 5 years on other far simpler devices with a lot less memory. And yes that sounds arrogant but I've spent 2 days verifying it with a backport to it's original platform.

[Ozone]

The Cube/HAL code is ugly and bloated, I very much agree.

But at least a stack overflow would be easy to correct.

The Cube framework already occupies interrupts (SysTick), and callback handlers run in interrupt context.

So, preempting interrupts can easily overflow a small stack.

BTW, the old SPL (Standard Peripheral Library) is available for download for the F10x series, which contains more comprehensive examples.

> I don't have enough experience with the device in question or the architecture in general.

Than different architectures, I guess.

Cortex M of all vendors are all quite similar, only the peripherals differ.

[m12lrpv]

I figured it out. Started probing with a scope and realised that something was out with the timing.

CubeMX had switched my crystal from 16MHz to 8MHz.

The clock timings aren't something someone would play with after setting them initially so it wasn't something I was checking periodically. I didn't expect it to change and need correcting. You live and learn i suppose. Thanks for your help, much appreciated.