Pixhawk 5X PX4 v1.17.0 – RAM usage reaches ~99% when automatic logging starts

PX4 Autopilot
1

Pixhawk 5X PX4 v1.17.0 – RAM usage reaches ~99% when automatic logging starts

Hi,

I am setting up a Holybro Pixhawk 5X running PX4 v1.17.0 stable and am encountering a repeatable RAM usage too high warning when the vehicle is armed and automatic ULog logging starts.

I have been troubleshooting the issue and have isolated it to the logger buffer allocation.

Hardware / Software

  • Flight controller: Holybro Pixhawk 5X

  • Hardware target: PX4_FMU_V5X

  • Hardware version: V5X

  • PX4 version: v1.17.0

  • PX4 git branch: stable

  • Build variant: default

  • MCU: STM32F76xxx, rev. Z

  • QGroundControl: 5.1.3

  • SD card: SanDisk Extreme 32 GB

The normal startup configuration appears to start the logger as:

logger start -b 40 -t -m file

and rc.board_arch_defaults contains:

set LOGGER_BUF 40

COM_RAM_MAX remains at the default value of 95%.

Observed RAM usage

With logging disabled, free shows approximately 86% heap utilisation.

With the automatic logger running but not yet recording, RAM usage is approximately 89–90%.

Once automatic logging starts, RAM usage rises to approximately 98.9–99.1%, leaving only around 4 KB free, and QGroundControl reports:

RAM usage too high

For example, during automatic logging:

  • Total heap: 429,776 B

  • Used: 425,152–425,872 B

  • Free: approximately 3.9–4.6 KB

  • Largest free block: approximately 2.5–2.6 KB

Logger buffer testing

I also tested smaller logger buffers manually.

12 KiB buffer

logger start -m file -b 12

  • RAM usage: approximately 93%

  • Max buffer usage: 11,723 / 12,288 B

  • 2 logging dropouts observed

  • Maximum dropout: 0.096 s

16 KiB buffer

logger start -m file -b 16

  • RAM usage: approximately 94.3%

  • Free RAM: 24,416 B

  • Max buffer usage after several minutes: 12,813 / 16,384 B

  • Logging rate: approximately 42 KiB/s

  • Dropouts: 0

Therefore, 16 KiB appears to provide enough logging buffer in my stationary test while keeping RAM below COM_RAM_MAX, whereas the normal 40 KiB configuration pushes RAM usage to approximately 99%.

SD card check

I initially suspected the SD card. The original card had relatively poor write latency, so I replaced it with a SanDisk Extreme 32 GB.

sd_bench -r 100 with the new card gave approximately:

  • Average sequential write: 968 KB/s

  • Maximum write time: 24 ms

  • fsync typically around 5–19 ms

However, the ~99% RAM condition with the automatic 40 KiB logger remained, so the RAM warning does not appear to be caused by the original slow SD card.

Questions

Is approximately 99% RAM utilisation expected on PX4 v1.17.0 on the FMUv5X/Pixhawk 5X when the default automatic logger starts?

In particular:

  1. Is LOGGER_BUF=40 the intended/recommended value for FMUv5X on v1.17.0?

  2. Is it safe/recommended to reduce the logger buffer on this target, for example to 16 KiB?

  3. Is there a supported persistent method of changing LOGGER_BUF, rather than modifying the PX4 startup scripts?

  4. Could this indicate an unexpectedly high baseline RAM usage or a regression in v1.17.0?

  5. Would you recommend testing another PX4 release/build before changing the logger configuration?

I have not increased COM_RAM_MAX or otherwise suppressed the warning, and I have not made any permanent changes to the logger startup configuration.

Any guidance on the expected RAM usage and recommended logger configuration for FMUv5X would be appreciated.

2

The 16 KiB result is interesting, but I would be cautious about treating the smaller logger buffer as the fix yet.

What stands out to me is the baseline memory usage before recording starts. If the system is already at ~86% heap utilization with logging disabled, the 40 KiB allocation may simply be exposing a much smaller memory margin rather than being the underlying cause.

Your comparison is useful:

  • logging disabled: ~86%
  • logger running, not recording: ~89–90%
  • 40 KiB buffer while recording: ~98.9–99.1%
  • 16 KiB buffer: ~94.3%, ~24 KiB free, no dropouts in the stationary test

Since changing the SD card did not materially change the ~99% condition, I would next try to separate a logger configuration issue from a v1.17.0/FMUv5X memory-footprint issue.

A useful A/B test would be the same hardware and configuration on the previous stable PX4 release, recording the free output at the same stages. If the pre-logging baseline is materially lower there, that would point toward a memory-footprint regression/change in v1.17.0 rather than the logger buffer itself.

I would also avoid increasing COM_RAM_MAX just to suppress the warning. The warning is telling us that the remaining margin is genuinely very small.

The 16 KiB test looks promising as a diagnostic result, but before making it permanent I would test it under the actual flight logging workload and check for logger dropouts, because the stationary ~42 KiB/s case may not represent the worst-case logging load.

If you can post the free output from the same configuration on the previous stable release, that comparison would narrow this down quite a bit.

3

Could you provide a log when this is happening?
Even a few seconds on the bench would be useful.