HardFault Debug in STM32CubeIDE

One thing that immediately catched my eye:

> 0801059a: bl 0x8010370 <_Balloc>

The malloc() functions take memory from the heap, not the stack.

But many IDEs set the default heap size to zero when creating a new project. Or, your heap could overflow.

Not the answer to your original, non-RTOS version of this failure, but there are issues with the stock malloc() family when running an RTOS. @Dave Nadler​ has posted extensively about this (for example, here https://community.st.com/s/question/0D50X0000BB1eL7SQJ/bug-cubemx-freertos-projects-corrupt-memory), and has a web page describing in detail what is wrong and how to fix it:

http://www.nadler.com/embedded/newlibAndFreeRTOS.html

Since you now apparently know where in the code the fault is happening, step into the _Balloc function and see if you can tell why it is returning NULL. And for that matter, why is the code that CALLS Balloc not checking for error? Yeah, not your fault. It is buried in dtoa(), called from printf(). Inexcusably bad coding on the library's part.

FYI, here is the source to Balloc() from https://sourceware.org/newlib/ :

_Bigint *
Balloc (struct _reent *ptr, int k)
{
 int x;
 _Bigint *rv ;
 
 _REENT_CHECK_MP(ptr);
 if (_REENT_MP_FREELIST(ptr) == NULL)
 {
 /* Allocate a list of pointers to the mprec objects */
 _REENT_MP_FREELIST(ptr) = (struct _Bigint **) _calloc_r (ptr, 
						 sizeof (struct _Bigint *),
						 _Kmax + 1);
 if (_REENT_MP_FREELIST(ptr) == NULL)
	{
	 return NULL;
	}
 }
 
 if ((rv = _REENT_MP_FREELIST(ptr)[k]) != 0)
 {
 _REENT_MP_FREELIST(ptr)[k] = rv->_next;
 }
 else
 {
 x = 1 << k;
 /* Allocate an mprec Bigint and stick in in the freelist */
 rv = (_Bigint *) _calloc_r (ptr,
				 1,
				 sizeof (_Bigint) +
				 (x-1) * sizeof(rv->_x));
 if (rv == NULL) return NULL;
 rv->_k = k;
 rv->_maxwds = x;
 }
 rv->_sign = rv->_wds = 0;
 return rv;
}

You could also write your own float to string routine of some sort. Wouldn't be hard, especially if you know the expected data range.​

My thoughts about this, so far:

I got it working with two solutions, by working I mean that the firmware didnt crash running for some minutes (need more time of testing for a definitive response):

1. Original faulty firmware (crashing within 1min of operation on the accelerometer example I described) with just removing the sysmem.c file (the one with _sbrk()). Why it works without the _sbrk definition? No idea! I couldnt find _sbrk definition anywhere else. It shouldnt even compile (who calls this after all?). Anyway, this way it works using DMA for UART transmission and its more practical, because I can use the code generated by Cube as is.
2. Using Nadler's solution.

What I did:

• changed heap management for the one provided in his post. (thanks Nadler!);
• Removed sysmem.c (because now it was a duplicated definition of _sbrk());
• Defined #define configUSE_NEWLIB_REENTRANT 1
• Had to stop using DMA to transmit data on the UART (redirection using _write()). Despite being called with the right parameters, the _write() function was getting stuck in the second call, where I check for UART state (was busy forever).

What worries me the most, its that I cant understand whats going on.

I often run into problems with sprintf overflowing a buffer, as well as RTOS not allocating enough space for a task, both are my fault.

Running in the debugger and catching the place where the error occurs is often the best approach as the stacks (and memory) may be badly mangled before the fault transpires. i.e. don't necessarily look at the Hard fault registers, by then it may be too late. Rather look at what is goingon immediately before the fault.

Try switching tasks off and isolate the problem to a task or short piece of code.

Formatting and parsing floating point is non trivial and may consume yards of stack with all it's ifs, buts and maybes. You may want to try an alternate sprintf or even ftoa.

In embedded I generally know the range of your FP numbers, so can easily do work arounds. e.g. multiply/divide by 1000s and print as integer with metric suffixes. I once wrote a function to auto scale from 10^24 to 10^-24, (yotta to yocto) very simple and quick.

For embedded work, I prefer to limit usage of malloc and free as sooner or later I get into garbage collection of some form.

As a result I usually use stack space or pre-allocated buffers. It's surprising how little you can get away with without adding complexity to the code.

My code simplified substantially once I learned to work with tasks and static buffers.

I had the same problem, which kept me baffled for a very long time. 

I just doubled the "Stack Size(Words)" from "128" to "256" from RTOS -> "Tasks and Queues" and my problem was solved.