platformio / platformio/platformio-core

PlatformIO is architecturally wrong about RAM

Open
#4,059 1 comment 3 reactions 2 assignees View on GitHub

@ivankravets is already working on this.

Since Sep 22, 2021.

build system feature
Dominant language
Python
Stars
9.5k
Forks
905
Avg merge
2d 13h
Merged PRs (30d)
2

Description

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

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.