Architecture Support: Zephyr

[Janek Hoffmann]

Hi Team,

I'm interested in the current status of Zephyr RTOS support in the project. I came across the architecture implementation in the arch/ folder and wondered if there is still any ongoing work? In particular, I would like to demonstrate a PubSub MQTT communication with Zephyr and open62541 - is this already possible?

Thanks in advance!

Best regards,

Janek

[Julius Pfrommer]

Yes, that should be possible out of the box.

See this PR for how to move files into the /zephyr folder in order to get detected as a "real" zephyr module.

https://github.com/open62541/open62541/pull/6951

Regards, Julius

[Janek Hoffmann]

Thanks.

I followed the steps in the PR and tried to build the example "zephyr/server" for STM32 Nucleo H563ZI. First I ran into issues with linking:
[375/381] Linking C executable zephyr\zephyr_pre0.elf

...

c:/workspace/zephyr_home/zephyr-sdk-0.17.0/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe: unrecognized option '--major-image-version'
c:/workspace/zephyr_home/zephyr-sdk-0.17.0/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe: use the --help option for usage information

On my research I found a generell fix of setting:

set(CMAKE_SYSTEM_NAME Generic)

in the zephyr/server/CMakeLists.txt, which seemed odd to me but fixed the issue of the unrecognized option '--major-image-version'.

However this led to more issues also during "[375/381] Linking C executable zephyr\zephyr_pre0.elf" regarding:

- conflicting CPU architectures 2/17

- Multiple undefined references

- RAM overflow errors

I'm curious if anyone has experience running open62541 with Zephyr on STM32 platforms and could offer some guidance. Am I missing crucial configuration files or settings?

Any suggestions would be appreciated.

Regards,

Janek

[Janek Hoffmann]

UPDATE:

Changing the order of setting the project in CMake solved the issue:

cmake_minimum_required(VERSION 3.20.0)

# set(CMAKE_OBJCOPY /usr/bin/arm-linux-gnueabihf-objcopy)
# set(Python3_EXECUTABLE "/usr/bin/python3" CACHE STRING "" FORCE)
# find_package(PythonInterp 3 REQUIRED)

find_package(Python REQUIRED COMPONENTS Interpreter)

set(DTC_OVERLAY_FILE ${CMAKE_CURRENT_LIST_DIR}/boards/nucleo_h563zi.overlay)
set(CONF_FILE ${CMAKE_CURRENT_LIST_DIR}/prj.conf)

# set(EXTRA_ZEPHYR_MODULES ${CMAKE_CURRENT_SOURCE_DIR}/../../../arch)
set(EXTRA_ZEPHYR_MODULES ${CMAKE_CURRENT_SOURCE_DIR}/../../modules/lib/open62541/arch)

find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})

project(open62541_server LANGUAGES C)

target_sources(app PRIVATE src/main.c)
target_link_libraries(app PUBLIC open62541)

I also added an .overlay file to ensure that the RAM of the nucleo_h563zi is recognized as contiguous to enable successful flashing.

However, I ran into problems with Client/Server subscriptions. The details are described in https://github.com/open62541/open62541/issues/7063

As far as I'm concerned, "sampleAndPublishCallback" is not called despite a "GOOD" result when adding the function with addRepeatedCallback in "ua_subscription.c".

Is there any solution or similiar experiences?

Regards,

Janek

[Julius Pfrommer]

Hmm. I have never seen a problem with the sample callbacks.

Are you sure your system time is advancing like it should?

Regards,

Julius

[Janek Hoffmann]

Hi,

I just resolved the issue, details are in the Github issue mentioned above.

Regards,

Janek