big const table overflow the RAM

[leonardo]

Posted on November 03, 2016 at 00:58

I'm using a STM32F411 with an audiocodec driven by I2S stream.

I'm runing out of RAM, so I'm trying to move OutputBuffer (the buffer that I use to create sound and used ond HAL_I2SEx_TransmitReceive_DMA). This buffer is 9600 x 4 (uint32_t) =  38Kbyte. But, I'm not sure why creating several const OutputBuffer's end on RAM overflow. I get this message: c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: final_15_DP_TE_ConstStimuli.elf section `.bss' will not fit in region `RAM' c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: region `RAM' overflowed by 336136 bytes Why making a big const table end on a RAM overflow? Thank

[leonardo]

Posted on November 04, 2016 at 22:28

I don't explain myself clear or you are not reading my post.

I don't want/need advices about my appliction. It is working just fine. I need to make a big outputbuffer becouse I need to estimulate the cochlea and record the responses for about 46mSeg. Then do some math with the buffer. I'm not overflowing the RAM. That message is showing that the new OutputBuffer's don't go to the flash when I don't initialized to something. So, the big question is why const float32_t tblStimuli_01[5][9600]; end to RAM and const float32_t tblStimuli_01[5][9600] = {0}; end to FLASH.... Thank and sorry for my english

[Tesla DeLorean]

Posted on November 05, 2016 at 01:05

The thing is that if I don't explicitly initialize the array, then it will goes to RAM. I need to explicitly initialize the constant array to make it goes to FLASH.

I'm wondering why... The most obvious answer is that if you explicitly initialize it the LINKER can place the array of constants (ie unchanging) into to FLASH. If you don't explicitly initialize it the array becomes the responsibility of the C run-time code that allocates and initializes them. Not sure there is a guarantee that they will be zero'd, it is probably a dangerous to assume they take any value, the same hazard people fall into with local/auto variables, which can contain random stack junk. In embedded things can be placed in NOINIT/NOLOAD memory regions by the linker via it's scripts. When const is used for function arguments it creates the contract that it will treat them as read-only. Now presumably at some point you want this 192000 byte array to hold some fixed, but device/user specific set of constants/waveforms