Build Environment Problem

[matty]

I've just installed the Nordic SDK version 17.1, SES version 6.3, and Segger J-Link Software version 7.64e on a new Ubuntu 22.04 laptop.

I've installed everything in their default locations. I'm using a pca10056 nrf52840 DK.

I am able to open SES and compile and flash examples.

I am able to port some of my SDK version 16 projects and have them compile and flash proprietary boards which also use the nrf52840.

Everything has worked except for any example or project that uses UART. For example, the UART example in the SDK examples/peripheral/uart

It compiles but has 10 linker errors

Building 'uart_pca10056' from solution 'uart_pca10056' in configuration 'Release'
  Assembling 'thumb_crt0.s'
  Compiling 'nrf_log_frontend.c'
  Compiling 'nrf_log_str_formatter.c'
  Compiling 'boards.c'
  Compiling 'app_error.c'
  Compiling 'app_error_handler_gcc.c'
  Compiling 'app_error_weak.c'
  Compiling 'app_fifo.c'
  Compiling 'app_uart_fifo.c'
  Compiling 'app_util_platform.c'
  Compiling 'nrf_assert.c'
  Compiling 'nrf_atomic.c'
  Compiling 'nrf_balloc.c'
  Compiling 'nrf_fprintf.c'
  Compiling 'nrf_fprintf_format.c'
  Compiling 'nrf_memobj.c'
  Compiling 'nrf_ringbuf.c'
  Compiling 'nrf_strerror.c'
  Compiling 'retarget.c'
  Compiling 'nrf_drv_uart.c'
  Compiling 'nrfx_atomic.c'
  Compiling 'nrfx_prs.c'
  Compiling 'nrfx_uart.c'
  Compiling 'nrfx_uarte.c'
  Compiling 'main.c'
  Assembling 'ses_startup_nrf52840.s'
  Assembling 'ses_startup_nrf_common.s'
  Compiling 'system_nrf52840.c'
  Generating linker script 'uart_pca10056.ld'
  Linking uart_pca10056.elf
    /usr/share/segger_embedded_studio_for_arm_6.30/lib/libc_v7em_fpv4_sp_d16_hard_t_le_eabi_balanced.a(fileops.o): in function `putchar':
    fileops.c:(.text.libc.putchar+0x0): undefined reference to `stdout'
    fileops.c:(.text.libc.putchar+0x4): undefined reference to `stdout'
    /usr/share/segger_embedded_studio_for_arm_6.30/lib/libc_v7em_fpv4_sp_d16_hard_t_le_eabi_balanced.a(fileops.o): in function `puts':
    fileops.c:(.text.libc.puts+0x2): undefined reference to `stdout'
    fileops.c:(.text.libc.puts+0x6): undefined reference to `stdout'
    fileops.c:(.text.libc.puts+0x18): undefined reference to `__SEGGER_RTL_X_file_write'
    /usr/share/segger_embedded_studio_for_arm_6.30/lib/libc_v7em_fpv4_sp_d16_hard_t_le_eabi_balanced.a(fileops.o): in function `fwrite':
    fileops.c:(.text.libc.fwrite+0xc): undefined reference to `__SEGGER_RTL_X_file_stat'
    fileops.c:(.text.libc.fwrite+0x24): undefined reference to `__SEGGER_RTL_X_file_write'
Build failed

I know there is something wrong with my build environment, but I can't figure out where I went wrong. Any code trying to use UART has the exact same linker issue just more of them.

I have also installed nRF Connect version 1.9.1 using the SES for ARM (Nordic Edition) V5.68 using the manual method as described by

https://developer.nordicsemi.com/nrf_connect_sdk/doc/latest/nrf/gs_installing.html#installing-ses-nordic-edition

This to seems to be working but I haven't tried any UART.

Also I have and older system using SES version 5.50b, J-Link software version 6.96, nordic sdk 16 and 17, gcc 9.4.0, cmake 3.16.3, GNU make 4.2.1, etc... SES is able to compile and link the SDK version 17's uart example as well as anything else using UART. This system is a UBUTU 20.04 with everything installed to their default locations.

Can anyone suggest how I can put my build environment together correctly? Reinstall?

[Vidar Berg]

Hello,

The problem is that our retarget.c implementation responsible for redirecting printf() to print data out on UART is not compatible with the Segger Runtime library used in version 6.x.x of Segger embedded studio (Embedded Studio Library IO).

The recommended solution is to downgrade Embedded studio to the version we used for the release testing which was 5.42a. Excerpt from SDK release notes:

nRF5 SDK v17.1.0
------------------------
Release Date: August, 2021
 
Highlights:
 
- Added support for the new versions of the nRF52 devices:
   - nRF52820 revision 3
   - nRF52832 revision 3
   - nRF52833 revision 2
   - nRF52840 revision 3
   (Note: Programming these requires nrfjprog v10.13 or newer.)
- Updated nrf_oberon to v3.0.8.
- Updated Mbed TLS to v2.16.10.

The following toolchains/devices have been used for testing and verification:
 
 - ARM: MDK-ARM version 5.25   
 - GCC: GCC ARM Embedded 9.2020-q2.major
 - IAR: IAR Workbench 7.80.4
 - SES: SES 5.42a

Best regards,

Vidar

Edit: Another solution is to redirect printf to RTT as discussed in this post https://devzone.nordicsemi.com/f/nordic-q-a/86110/nrf5-sdk-17-1-0-examples-is-not-compiling-in-latest-ses-6-20a/359669#359669

[matty]

I am not getting anywhere with this.

1) I use SES 5.42b and open the nordic_sdk_16/examples/peripheral/uart example, compile and load the DK. I see all the expected results in my GTKTerm window.

2) I use SES 5.42b and open nordic_sdk_17.1/examples/peripheral/uart example, compile and load the DK. I don't see anything in my GTKTerm window. I run in the SES debugger and all the uart strings appear in the debugger's output window. Also I am able to enter keyboard characters through the terminal and watch the code reject everything but 'q'. So UART is working half-way. As in this post:

https://devzone.nordicsemi.com/f/nordic-q-a/87492/uart-example-in-nrf5-sdk-v17-0-2-not-working-as-expected-when-built-using-segger-embedded-studio-for-arm-v6-22

3) I use SES 6.30 and open a copy of the nordic_sdk_17.1 uart example. I use project options to change the Library I/O to RTT and I remove the retarget.c file from the project. As suggested in the post you provided in the edit. The project compiles and I load the DK. the results are exactly like 2).

I'm going to try the nordic_sdk_17.1 libuarte example next. In the meantime can you provide any insight. I would have expected number 2 to work. There must be something about my environment that effects the 17.1 SDK.

Ultimately I have to use SES 6.30 and the nordic_sdk_17.1 and make use of NRF_LOG_  macros to the Segger RTTViewer and use UART to get information into the firmware and out of the firmware. In fact I have the beginnings of a project that uses all four and its just the UART portion that isn't working although everything compiles and links. I can even use NRF_LOG_INFO, NRF_LOG_ERROR to see that the APP_UART_ macros are returning without errors. Because of the lack of UART issue, I went back to basics and tried using the uart example and I'm finding all of these difficulties.

My development set-up is as described at the top of this post. The sdk_config.h file and main.c are as provided by the examples and are unchanged. Any help will be greatly appreciated, thank you.

[matty]

Update - I tried the nordic_sdk_17.1 libuarte example with SES 6.30. All I did was remove the SEGGER_RTT_Syscalls_SES.c file from the project. It worked exactly as described.

[Vidar Berg]

matty said:

run in the SES debugger and all the uart strings appear in the debugger's output window. Also I am able to enter keyboard characters through the terminal and watch the code reject everything but 'q'.

The Debug Terminal window will only display RTT traffic indicating that the printf()'s are being redirected to RTT instead of UART in your case, but I don't see how this could have happened with these default project settings:

matty said:

I tried the nordic_sdk_17.1 libuarte example with SES 6.30. All I did was remove the SEGGER_RTT_Syscalls_SES.c file from the project. It worked exactly as described.

Yes, this should be sufficient for the other projects that include SEGGER_RTT_Syscalls_SES.c but don't rely on retarget.c.

matty said:

Ultimately I have to use SES 6.30 and the nordic_sdk_17.1 and make use of NRF_LOG_  macros to the Segger RTTViewer and use UART to get information into the firmware and out of the firmware. In fact I have the beginnings of a project that uses all four and its just the UART portion that isn't working although everything compiles and links. I can even use NRF_LOG_INFO, NRF_LOG_ERROR to see that the APP_UART_ macros are returning without error

Are you relying on retarget.c/prinft()s to send the UART data?

[matty]

Vidar Berg said:

The Debug Terminal window will only display RTT traffic indicating that the printf()'s are being redirected to RTT instead of UART in your case, but I don't see how this could have happened with these default project settings:

My apologies. I hadn't checked my sdk_config.h file. I know I said it wasn't modified but I must have done so during my trials and forgotten. Setting RETARGET_ENABLE to 1 gets that to work as it should.

Vidar Berg said:

Are you relying on retarget.c/prinft()s to send the UART data?

If my interpretation is correct, that won't compile when using SES version 6.30.

For example, using SES 6.30 and the nordic_sdk_17.1/examples/peripheral/uart example:

retarget.c either has to be removed from the project or RETARGET_ENABLE has to either be set to 0 or removed from the sdk_config.h file. But that is step one of two. The second step requires you to change the project's common options > Library > Library I/O to RTT from NONE. These two steps allow you to compile and load the DK. But printf() is redirected as you would expect, (I guess), since your I/O library seemingly uses RTTViewer exclusively.

I would like to understand why I can't use SES 6.30 and the nordic_sdk_17.1 and the UART Library since it looks like you can't. But it does look like the UARTE will work, (at least based on the nordic_sdk_17.1/examples/peripheral/libuarte example).

[Vidar Berg]

No worries, thanks for confirming what the issue was!

matty said:

I would like to understand why I can't use SES 6.30 and the nordic_sdk_17.1 and the UART Library since it looks like you can't.

You should be able to work with any of the uart libaries or drivers. The limitation is that you will not be able use the app uart library as the standard output for printf() because our retarget.c file is not compatible with the new Segger runtime libraries. You can see the changes that would have been required from the Segger Wiki page I linked to in my initial reply (Under "User-supplied I/O").

[matty]

Thank you, Vidar. I want to implement something using UARTE before closing this. Even though the libuarte example worked, I want to confirm it. Might take a day or two.