Memory usage in PlatformIO's Inspect inconsistent?

johnwee1 · April 27, 2023, 10:32am

Hi all, need to clarify on how to use PIO’s inspect feature. I am facing the same issue on a mega2560 project as in this thread where the RAM usage reported upon building is actually larger than that in the inspect explorer and there isn’t anything that I can see which can account for the discrepancy. Not sure if this is related to this open issue on how PIO is architecturally incorrect about RAM. Is the larger figure more accurate or the smaller figure more accurate on how much RAM I am using?

github.com/platformio/platformio-core

PlatformIO is architecturally wrong about RAM

opened 10:56PM - 21 Sep 21 UTC

maxgerhardt

feature build system

### 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](https://github.com/stm32duino/Arduino_Core_STM32/blob/6dec3b655fda17ba0f33cf12cef16b64d0333abd/variants/STM32F4xx/F427Z%28G-I%29T_F429ZET_F429Z%28G-I%29%28T-Y%29_F437Z%28G-I%29T_F439Z%28G-I%29%28T-Y%29%2Fldscript.ld#L31-L43) 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 ```ld 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](https://github.com/platformio/platformio-core/blob/develop/platformio/builder/tools/piosize.py). 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

maxgerhardt · April 27, 2023, 10:45am

You’re having the general problem than that the “Debug” feature inspects the firmware when built in debug mode when memory usage is generally larger.

Best to compile in “MinSize with Debug Info” mode by setting build_flags = -g3 -ggdb3 -Wl,-Map,output.map to the platformio.ini, building, and either run the resulting .map file through amap or the .elf file through GitHub - ARMmbed/mbed-os-linker-report: Post-processing of linker output to calculate and visualize memory usage for elf-sections like I did e.g. in STM32g030k6p6 simple sketch overflows the flash memory? - #5 by maxgerhardt