platformio-core

platformio-core copied to clipboard

Configuration

Operating system: Win 10 x64

PlatformIO Version (platformio --version): 5.2.1b2

Description of problem

As outlined in https://github.com/platformio/platform-ststm32/issues/537 and recently in https://github.com/platformio/platform-ststm32/issues/563, PlatformIO has a real problem when it comes to microcontrollers that have multiple banks of RAM which live in non-continuous sections of the memory map. The board files do not describe all the RAM section a microcontroller has actually, but accumulate the number in upload.maximum_ram_size. This is fatal and has lead to the bugs shown above -- linker scripts using this value and assuming they can do things like setting the initial SP to the end of RAM with end of RAM being RAM start address + RAM length lead to an immediate crash, since the "end of RAM" is not necessarily at that address when the RAM is not organized in a perfectly linear, contiguous way.

Further, since the PlatformIO core only understand a singular "maximum RAM size" value, it does not understand (and thus e.g. display) the usage of the distinct RAM sections. For example, for a Nucleo-H723ZG, which has

MEMORY
{
  ITCMRAM (xrw)    : ORIGIN = 0x00000000,   LENGTH = 64K
  RAM     (xrw)    : ORIGIN = 0x20000000,   LENGTH = 128K
  FLASH    (rx)    : ORIGIN = 0x08000000,   LENGTH = 1024K
  RAM_D1  (xrw)    : ORIGIN = 0x24000000,   LENGTH = 320K
  RAM_D2  (xrw)    : ORIGIN = 0x30000000,   LENGTH = 32K
  RAM_D3  (xrw)    : ORIGIN = 0x38000000,   LENGTH = 16K
}

all PlatformIO can display is

RAM:   [          ]   4.6% (used 20336 bytes from 442368 bytes)
Flash: [          ]   2.1% (used 21772 bytes from 1048576 bytes)

when more informatively, it should be doing something like

ITCRAM: [          ]   0.0% (used 0 bytes from 65535 bytes)
RAM:    [          ]   4.6% (used 20336 bytes from 131072 bytes)
RAM_D1: [          ]   0.0% (used 0 bytes from 327680 bytes)
RAM_D2: [          ]   0.0% (used 0 bytes from 32768 bytes)
RAM_D3: [          ]   0.0% (used 0 bytes from 16384 bytes)
Flash:  [          ]   2.1% (used 21772 bytes from 16384 bytes)

The previous fixes regarding this like https://github.com/platformio/platform-ststm32/commit/38e325b59c165c954f6f69c70e0299d36f3b9225 are bandaids to the underlying problem: By pretending boards have less RAM than they actually have (to make the linkerscripts work), one may be able to construct a firmware that links through GCC but PlatformIO will end with an error message after it itself checks the firmware size.

The PlatformIO core and associated platforms should be improved to have a better understanding of different RAM sections of a microcontroller, so that PlatformIO can display RAM usage of these different sections. This would also improve the static memory usage analyzer. And enable builder scripts (e.g. Arduino, CMSIS) to explicitly select the correct RAM size value expected for a framework.

Steps to Reproduce

Build and inspect projects that use multiple RAM sections like https://github.com/maxgerhardt/pio-stm32h7-stm32cube-freertos/

Actual Results

Actual RAM + Flash usage output as seen above

Expected Results

Expected RAM + Flash usage outpu as seen above

If problems with PlatformIO Build System:

N/A

Additional info

None

Fully agree here. Running into this. I've filled the DTCM on an STM32, and while I was able to move .bss into RAM_1, the reports on PlatformIO are completely wrong.

This is a highly sought feature for us:

ITCRAM: [          ]   0.0% (used 0 bytes from 65535 bytes)
RAM:    [          ]   4.6% (used 20336 bytes from 131072 bytes)
RAM_D1: [          ]   0.0% (used 0 bytes from 327680 bytes)
RAM_D2: [          ]   0.0% (used 0 bytes from 32768 bytes)
RAM_D3: [          ]   0.0% (used 0 bytes from 16384 bytes)
Flash:  [          ]   2.1% (used 21772 bytes from 16384 bytes)

Has there been any movement on this or an expectation of when it could be addressed?

I looked over the python and it seems straight forward. It looked to me like the .py that @maxgerhardt posted has functions to get the name and size from the elf file, I think that is sections like .bss, .debug, etc. So the ini needs to take in names of sections and relate to the ld file, right? I'm sure it's more complicated than that, and that there is a backward compatibility, so the cop out would be "use_detailed_sections = true" or something but... This is a big deal imo, and it's only going to be an issue with more and more chips.