[BUG] at32f437-mini/systemview: builds fail with error: implicit declaration of function 'SEGGER_RTT_LOCK'

[simbit18]

Description / Steps to reproduce the issue

====================================================================================
Configuration/Tool: at32f437-mini/systemview,CONFIG_ARM_TOOLCHAIN_GNU_EABI
2025-01-07 07:08:43
------------------------------------------------------------------------------------
  Cleaning...
  Configuring...
  Disabling CONFIG_ARM_TOOLCHAIN_GNU_EABI
  Enabling CONFIG_ARM_TOOLCHAIN_GNU_EABI
  Building NuttX...
In file included from segger/SystemView/SEGGER/SEGGER_SYSVIEW.h:65,
                 from segger/SystemView/SEGGER/SEGGER_SYSVIEW_Int.h:64,
                 from segger/SystemView/SEGGER/SEGGER_SYSVIEW.c:146:
segger/SystemView/SEGGER/SEGGER_SYSVIEW.c: In function '_VPrintHost':
Error: segger/SystemView/SEGGER/SEGGER_SYSVIEW_ConfDefaults.h:557:51: error: implicit declaration of function 'SEGGER_RTT_LOCK'; did you mean 'SEGGER_RTT_Read'? [-Werror=implicit-function-declaration]
  557 |   #define SEGGER_SYSVIEW_LOCK()                   SEGGER_RTT_LOCK()
      |                                                   ^~~~~~~~~~~~~~~
segger/SystemView/SEGGER/SEGGER_SYSVIEW.c:387:35: note: in expansion of macro 'SEGGER_SYSVIEW_LOCK'
  387 | #define RECORD_START(PacketSize)  SEGGER_SYSVIEW_LOCK();                            \
      |                                   ^~~~~~~~~~~~~~~~~~~
segger/SystemView/SEGGER/SEGGER_SYSVIEW.c:1005:5: note: in expansion of macro 'RECORD_START'
 1005 |     RECORD_START(SEGGER_SYSVIEW_INFO_SIZE + SEGGER_SYSVIEW_MAX_STRING_LEN + 2 * SEGGER_SYSVIEW_QUANTA_U32 + SEGGER_SYSVIEW_MAX_ARGUMENTS * SEGGER_SYSVIEW_QUANTA_U32);
      |     ^~~~~~~~~~~~
Error: segger/SystemView/SEGGER/SEGGER_SYSVIEW_ConfDefaults.h:570:51: error: implicit declaration of function 'SEGGER_RTT_UNLOCK'; did you mean 'SEGGER_RTT_Init'? [-Werror=implicit-function-declaration]
  570 |   #define SEGGER_SYSVIEW_UNLOCK()                 SEGGER_RTT_UNLOCK()
      |                                                   ^~~~~~~~~~~~~~~~~
segger/SystemView/SEGGER/SEGGER_SYSVIEW.c:390:35: note: in expansion of macro 'SEGGER_SYSVIEW_UNLOCK'
  390 | #define RECORD_END()              SEGGER_SYSVIEW_UNLOCK()
      |                                   ^~~~~~~~~~~~~~~~~~~~~
segger/SystemView/SEGGER/SEGGER_SYSVIEW.c:1015:5: note: in expansion of macro 'RECORD_END'
 1015 |     RECORD_END();
      |     ^~~~~~~~~~
cc1: all warnings being treated as errors
make[1]: *** [Makefile:109: segger/SystemView/SEGGER/SEGGER_SYSVIEW.o] Error 1
make[1]: Target 'libdrivers.a' not remade because of errors.
make: *** [tools/LibTargets.mk:107: drivers/libdrivers.a] Error 2
make: Target 'all' not remade because of errors.
/github/workspace/sources/nuttx/tools/testbuild.sh: line 385: /github/workspace/sources/nuttx/../nuttx/nuttx.manifest: No such file or directory
  Normalize at32f437-mini/systemview
====================================================================================

[NuttX Mirror Build Linux (arm-01)]
https://github.com/NuttX/nuttx/actions/runs/12646742907/job/35238004207

On which OS does this issue occur?

[OS: Linux]

What is the version of your OS?

ubuntu at GitHub Actions

NuttX Version

master

Issue Architecture

[Arch: arm]

Issue Area

[Area: Build System]

Verification

• I have verified before submitting the report.

[raiden00pl]

CI in its current state misses too many build errors :(

[xiaoxiang781216]

Yes, could we bring back more board into ci? @lupyuen ?

[xiaoxiang781216]

here is the fix: #15441

[lupyuen]

@simbit18 @raiden00pl @xiaoxiang781216 Yeah I reported this earlier based on NuttX Dashboard, and this also. I'm kinda exhausted from monitoring our CI Jobs every day since November. And it's not sustainable (in case something happens to me). Let's do this:

• Remember that we agreed to halve the CI Jobs for Complex PRs? We did this to stay within the ASF Budget of 25 full-time GitHub Runners: https://lupyuen.org/articles/ci3.html

• Over the past 30 days, we consumed 10 full-time runners (pic above)

• The load was higher than usual, because we ran more CI Jobs for NuttX Release. (Merging a Release Branch will trigger 100% of CI Jobs)

• This means we have spare capacity to double our CI Jobs. Thus we shall remove the 50% limit on CI Jobs for Complex PRs. Which means we shall run 100% of CI Jobs for Complex PRs.

• Except we won't run risc-v-07, since it compiles CPython for NuttX and might exceed our budget. (risc-v-07 will run in NuttX Build Farm instead)

• When we receive complaints about overuse of GitHub Runners: I'll reduce the CI Jobs back to 50%

• Hopefully this will improve the quality of Complex PRs, failing less often during the Daily Builds. I'm sorry Complex PRs will no longer complete CI Checks within 1.5 hours, they will now complete in 2 hours 10 mins.

• I'll prepare the PR now to increase the CI Jobs. Thanks :-)

• CI: Increase CI Jobs to 100% for Complex PRs #15460

• CI: Increase CI Jobs to 100% for Complex PRs nuttx-apps#2933

[xiaoxiang781216]

could we monitor the loading realtime and postpone the new pr ci when the loading approach the budget? Since the contributor doesn't care whether the ci can finish in one hour or extend to two or three hours in most case.

[lupyuen]

could we monitor the loading realtime and postpone the new pr ci when the loading approach the budget?

@xiaoxiang781216 Sorry are we suggesting that the monitor the GitHub Runners in real-time, then if the load exceeds 25 GitHub Runners, we will delay the CI Jobs for Complex PRs?

Right now we have this GitHub Runners Monitoring by Day: https://lupyuen.github.io/nuttx-metrics/github-fulltime-runners.png (Explained here)

We could use it to figure out the Current CI Load. However our CI Load tends to spike high and low, often exceeding 25 runners, even though the Daily Average Load is under 25 runners. So it's hard to know for sure whether it's OK to run the CI Job right now.

ASF said that they are OK so long as the Average Weekly Load is under 25 runners. So I think we are safe to run at 100% CI Load. Let's monitor and see what happens :-)