STM32F7: USBH_malloc fails (despite 8 KB heap)

[Lars Beiderbecke]

In my project, which uses FatFs and a couple of peripherals, I always used a heap size of 0x100 bytes, with no apparent problems.

After activating the USB Host for HID Class, I increased the heap size to 0x2000 bytes (8 KB), but still the USBH_malloc call for 52 bytes in USBH_HID_InterfaceInit() fails, i.e., returns NULL.

USBH_malloc seems defined as plain malloc, but alas, I cannot debug into the malloc function.

The heap section in the linker file is

_Min_Heap_Size = 0x2000;      /* required amount of heap  */
...
/* User_heap_stack section, used to check that there is enough "RAM" Ram  type memory left */
  ._user_heap_stack :
  {
    . = ALIGN(8);
    PROVIDE ( end = . );
    PROVIDE ( _end = . );
    . = . + _Min_Heap_Size;
    . = ALIGN(8);
  } >RAM

at the end of the declarations. The map file shows the position of the heap as intended:

...
                0x0000000020019848                __bss_end__ = _ebss
 
._user_heap_stack
                0x0000000020019848     0x2000 load address 0x0000000000217308
                0x0000000020019848                . = ALIGN (0x8)
                0x0000000020019848                PROVIDE (end, .)
                [!provide]                        PROVIDE (_end, .)
                0x000000002001b848                . = (. + _Min_Heap_Size)
 *fill*         0x0000000020019848     0x2000 
                0x000000002001b848                . = ALIGN (0x8)

What can cause malloc to fail here? Is 8 KB still not enough for 1 USB class/interface/endpoint/configuration each?

[Tesla DeLorean]

a) failure to release

b) fragmentation

c) reentry/thread safe issues

Might want to walk the heap and see what the state is at failure. Instrument the malloc/free to track symmetry, and detect double free, or orphans.

Not using GCC, but would expect linked list hidden in front of the allocation. Check the allocator source.

[Lars Beiderbecke · Accepted solution]

Clive, thanks for your answer!

I actually found out what is wrong. I read that _sbrk() in syscalls.c is somehow is involved in malloc(), and sure enough:

caddr_t _sbrk(int incr)
{
	extern char end asm("end");
	static char *heap_end;
 
        // ...
	if (heap_end + incr > stack_ptr)
	{
		errno = ENOMEM;
		return (caddr_t) -1;
	}
        // ...
}

Now what I didn't write (isn't it always in the details you don't mention?) is that I relocated my stack to DTCM, but heap is in RAM1. Thus, that check will be always false!

After replacing stack_ptr with 0x2003c000, everything works fine.

[Tesla DeLorean]

Yes this depressing piece of code has propagated everywhere, big headaches with STM32 with multiple RAM regions.

Why ST can't use linker symbols properly for both heap and stack initialization and limit checking is beyond me.

That and the use of symbols to set SCB->VTOR to what the linker built...

[Pavel A.]

> Why ST can't use linker symbols properly for both heap and stack initialization and limit checking is beyond me.

Not to compete with makers of proper tools and libraries for their hardware? For demonstration and examples this simplistic code is enough...

-- pa

[Piranha]

Are you guys pretending to not see the obvious because of political correctness? ;)

The code speaks for itself - software (non)architecture, code bloat, rough bugs all around, lack of understanding interrupt and thread safe principles and their developer sometimes insanely incompetent comments here... That team is just totally incompetent and incapable of developing a decent software.

[Pavel A.]

> Are you guys pretending to not see the obvious because of political correctness? ;)

I don't like cursing and offensive language. This is not helpful at least . The world has changed, it won't be like it was 20 years ago again.

One simply cannot get other sort of team for this sort of job these days.

Lifetime of embedded C/C++ coder in a department like this is 2-3 years. Then, good folks are promoted or move on... C'est la vie. There may be exceptions of course.

-- pa

[chaaalyy]

That´s not the whole truth ... For example: take a look into the actual x-cube-audio library. Updated in dec. 2019, but still it contains usb device library from 2016 ... Imho that´s just stupidity and ignorance. As developer i have to trust the guys, who bring the stuff to life. And even more important: I don´t have the possibilities or the time (nor do i want to...) to struggle around 99% of the time with the results of stupidity and ignorance.

Atm there´s exactly ONE great exeption at ST´s software teams and that´s TouchGFX. They listen, they answer and they do something. THAT is the way, how the things should be handled. For me it´s NO problem to stumble about bugs or mistakes if the people behind don´t wear their noses so high that it rains in. It´s just sad: There are many solutions and help offers from the community, but they are just ignored and even worse: discussed to death :(

[Piranha]

Pavel, it's just an evaluation of work they've done as an extremely bad and their capabilities as a totally incapable and incompetent. Calling it offensive is just an excuse. People have to be able to criticize as it drives the improvement. Just silently accepting the crap like HAL/CubeMX is the thing that is actually not helpful.

Everyone cannot be promoted, because the higher you go, the less seats there are... And even if there were good folks working for 2-3 years in that team, you could see the results of it. ST's problem is not in a "world" (at least no to that extent), but their management's blindness and/or "we don't care" attitude. One doesn't have to go far in search for a counterexamples:

https://www.youtube.com/watch?v=myKkmPIGT38

A team of 50 people and they rule the world! There are countless other decent projects like FreeRTOS, lwIP, FatFS, BearSSL, CMSIS, Mbed TLS, ChibiOS, µC/OS, ThreadX, Linux and whatnot. Closed/open source, free/paid and even size of the team doesn't matter in this regard - they all produce useful products. Nothing is perfect, but their products definitely are not an absolute crap, which is not the case with ST's software libraries.