Correct way to override a zephyr git using another fork and build failure?

[OwainIncus]

Hi,

I need to make a small change one of the Zephyr git modules.

At the moment my Git has a west.yml and imports the nrfconnect SDK; which in tern imports the nrfconnect zephyr fork and all underlying modules.
Now the module I need to replace is one of the modules in the zephyr git west.yml.

My code all builds fine if I just locally change the one file in the module and all refs still point to original zephyr module git (not overrriden).
I now clone the modules git; and try and override the use of the original zephyr copy with my own; referring to the SAME commit number from my own west.yml.
My builds now fail.

I have checked the output of the "west update" when swapping between the two variants; this looks good.
I have compared the module sources; this looks identical.

I have tried to compare the build output for successful and failed builds; this is difficult for the two builds as the build order seems to differ.
But I can see there are differences in the two builds WRT compilation of segger related code; primarily subsys/logging/log_backend_rtt.c and subsys/shell/shell_rtt.c.
And final link error is related to Segger RTT.

I attach the build output that I try to compare.
But this does not contain the detail I need to see why one build fails; I think the correct toolchain is being used (2.1.0); but I want to see the complete build line for each target so I can try and work out why the one build fails.

buildlogBad.txtbuildlogGood.txt

[Marte Myrvold]

Hi,

Which module is this?

The nRF Connect SDK does not import all modules imported by Zephyr, only the ones explicitly listed in name-allowlist: https://github.com/nrfconnect/sdk-nrf/blob/v2.1.0/west.yml#L66.

I see that the build error is related to SEGGER_RTT_WriteSkipNoLock, and that you are also getting some warnings about SEGGER_RTT_HasDataUp in the failing build. Have you made any changes to the Segger module?

Best regards,

Marte

[OwainIncus]

Looking at the compile error there looks to be some kind of magic to do with compiler versions/architecures in SEGGER_RTT_Conf.h and SEGGER_RTT.h; looks as if RTT_USE_ASM has been given value 1 (or not defined); and the C implemenetation in SEGGER_RTT.c of that function is not included.

But no ASM version of the function is included in the build either.

[Marte Myrvold]

Hi,

Can you share your west.yml file?

Best regards,

Marte

[OwainIncus]

Hi Marte,

We are building from standard repos; avoiding the conflicting kernel version.h and mbedtls kernel.h issue by kludging our build to inject kernel version int build from top lvel project CMakeLists.txt.

add_definitions(-DKERNEL_VERSION_MAJOR=3)

This mean when tracealyzer includes version.h; picking up wrongly mbledtls version and bombig out due to the kernel version not being know; it just proceeds through and works.

The west.yml that gave us issues was...

 

manifest:
  remotes:
    - name: ncs
      url-base: https://github.com/nrfconnect
    - name: incus
      url-base: https://github.com/INCUS-Performance
    - name: zeph
      url-base: https://github.com/zephyrproject-rtos
    - name: ublox
      url-base: https://github.com/u-blox
  projects:



    - name: nrf
      repo-path: sdk-nrf
      remote: ncs
      revision: v2.1.0
      import: true

    - name: TraceRecorderSource
      repo-path: TraceRecorderSource
      remote: incus
      revision: 6999859769c108533a3718f24bffef3da4f63e9b
      path: modules/debug/TraceRecorder
      groups:
       - debug

    - name: ubxlib
      repo-path: ubxlib
      remote: ublox
      revision: fb63a1f22333c840464a658c708327c04191826e
      path: ubxlib
  self:
    path: nova

This overrides the standard trace recorder stuff with the kernel version check commented out.

But as said we have worked round the issue for now.

Regards,
Owain

[OwainIncus]

Last time round I had this issue upgrading to ncs2.1.0; but it mystically disappeared.
I now find myself being force to upgrade to ncs2.2.0 and the issue has raised itself again.


It looks as if the wrong copy of SEGGER_RTT_conf.h is being pulled in.

It appears that there are multiple copies of segger RTT related code littering the codebase; due to the fact that many third party libraies use segger RTT.

Copies exist under....

modules/debug/segger

modules/debug/TraceRecorder

modules/lib/matter

modules/lib/openthread

and its a bit of a lottery which copies get picked up depending on search include paths; in my case the build of the modules/debug/segger appears to pick up SEGGER_RTT_Conf.h from TraceRecorder; and TraceRecorder picks up its own copy. And as the integrations use different Segger libraies....bang.