STM32H7: Bug in CubeMX Code Generation - Stacksize is too small for JPEG Module INIT

[MikePhillyFlyers]

Hi,

I wasn't sure where to post this, as this isn't really a question but more of a finding.. I've been using CubeMx 5.xx (was also using the prior 3.xx versions)... I am using an STM32H7, with many of the modules enabled...

I was only using code generated by CubeMX to test the processor startup and make sure things initialized, when I found this problem...

It kept crashing during JPEG init, until I finally tracked it down to a stack size problem in IAR (TrueStudio does not have this problem, as they set 'min' stack sizes, but not a hard/fixed size as IAR does)

static HAL_StatusTypeDef JPEG_DCHuff_BitsVals_To_SizeCodes(JPEG_DCHuffTableTypeDef *DC_BitsValsTable, JPEG_DC_HuffCodeTableTypeDef *DC_SizeCodesTable)
{
  HAL_StatusTypeDef error;
 
  uint32_t k;
  uint32_t l;
  uint32_t lastK;
  uint8_t huffsize[257];     ***  257 bytes required ***
  uint32_t huffcode[257];  *** 1028 bytes required ***
.
.
.

The above function, as part of the huffman table setups, requires 0x505 bytes on the stack, but the IAR linker file sets up the stack as follows:

define symbol __ICFEDIT_size_cstack__ = 0x400;
define symbol __ICFEDIT_size_heap__ = 0x200;

This function ends up overwriting it's region and stack, and overwriting global memory, in my setup clobberting the HJPEG handle, and then blowing up.

Manually adjusting the stack size to something like 2k (0x800) instead of 1k (0x400) fixes this init problem...

[Tesla DeLorean]

The GNU/GCC stuff just commits the bulk of the SRAM to the heap and stack, pointing the stack to the top of memory. Everything is great until they collide.

Some of the USB stuff has issues with small stacks, and using malloc() under interrupt.