[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 :-)

[xiaoxiang781216]

• 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)

can we stop the auto ci trigger on release branch? and let @jerpelea trigger ci manually.

[lupyuen]

can we stop the auto ci trigger on release branch? and let @jerpelea trigger ci manually.

@xiaoxiang781216 Hmmm I don't have an easy way to manually start CI Jobs on the Release Branch, it requires a script similar to this. I think let's not stress out Alin too much during NuttX Release :-)

I expected the CI Load to jump much higher last month for NuttX Release. But surprisingly the CI Load was OK (below 50% of our budget for GitHub Runners). That's why I think it's OK to increase our CI Jobs to 100%, even when NuttX Release is happening.

[xiaoxiang781216]

ok, let's monitor the ci loading.

[jerpelea]

@lup I think that we should switch the CI to manual for the release branch and do a full build on all targets manually Bets regards Alin

…

________________________________ Från: Xiang Xiao ***@***.***> Skickat: den 8 januari 2025 06:16 Till: apache/nuttx ***@***.***> Kopia: Jerpelea, Alin ***@***.***>; Mention ***@***.***> Ämne: Re: [apache/nuttx] [BUG] at32f437-mini/systemview: builds fail with error: implicit declaration of function 'SEGGER_RTT_LOCK' (Issue #15451) 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) can we stop the auto ci trigger on release branch? and let @jerpelea trigger ci manually. — Reply to * 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) can we stop the auto ci trigger on release branch? and let @jerpelea<https://urldefense.com/v3/__https://github.com/jerpelea__;!!O7_YSHcmd9jp3hj_4dEAcyQ!1qk8DUTvfeiPCZliU-AwcKOL8Aw4W8h7ZIIorbiGF1o0EIjai1tvTMqj-RdKHYrd9T1DJV645YJ4PfzmFLQiRFr3aA$> trigger ci manually. — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/apache/nuttx/issues/15451*issuecomment-2576772165__;Iw!!O7_YSHcmd9jp3hj_4dEAcyQ!1qk8DUTvfeiPCZliU-AwcKOL8Aw4W8h7ZIIorbiGF1o0EIjai1tvTMqj-RdKHYrd9T1DJV645YJ4PfzmFLR6iZ75lg$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AB32XCSLGLV4W7HGVNPGQDL2JSYBHAVCNFSM6AAAAABUXLFX5OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZWG43TEMJWGU__;!!O7_YSHcmd9jp3hj_4dEAcyQ!1qk8DUTvfeiPCZliU-AwcKOL8Aw4W8h7ZIIorbiGF1o0EIjai1tvTMqj-RdKHYrd9T1DJV645YJ4PfzmFLQPC2NTWQ$>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[lupyuen]

I think that we should switch the CI to manual for the release branch and do a full build on all targets manually

Sorry @jerpelea by "building manually", do you mean running a script at the command line?

I don't think there's a command in GitHub Actions that will allow us to click and start a CI Job. Here is the script that I run to start the build at the NuttX Mirror Repo: https://github.com/lupyuen/nuttx-release/blob/main/enable-macos-windows.sh

[lupyuen]

FYI our usage of GitHub Runners is still OK and within the ASF Budget. Past 7 Days: We consumed 18 Full-Time GitHub Runners. That's 72% of the ASF Budget for GitHub Runners (25 runners).

Next Week I expect our usage to spike up (just before the Lunar New Year). Following Week our usage should drop (during the Lunar New Year Holidays). I'll keep monitoring thanks :-)