I just upgraded my environment from nRF Connect SDK v1.9.1 to v2.1.0. This process raised one critical bug, as well as some very important questions:
My projects make very minor changes to a copy of existing samples and boards:
I maintain modified boards: nrf9160dk_nrf9160 and nrf9160dk_nrf52840 where a second UART on each CPU connects them together. Next I change the gnss sample: a copy of the GNSS data is sent over UART1 to nrf52840, which makes it available over BLE (modified connectivity_bridge), and also over the it's other UART which is exposed over USB by the board controller.
1. Let's start with my expectations: a well maintained SDK should allow user code to be ported to a new SDK version with minimal or no effort.
2. Unfortunately this has never been the case with nRF Connect SDK. Even though my changes are minor and I work on copies of each board or sample, they never build when a new SDK is released, because each time the DSK is updated, the changes to API and the build environment are so big that every single aspect of the code and Cmake configuration needs to be adapted. This may take up to 2-3 days.
3. Critical bugs in release SDK v2.1.0 versions:
Once all boards and projects are adapted to a new SDK, we often face critical bugs in nRF Connect SDK, which makes it completely impossible to run anything. After days of debugging I figured that the UART pins on nRF52840 are not configured. All pins get the default value of -1. The baud_rate configuration is valid. Below in a snippet of my driver.
.pin_select_dma =
{
.CTS = DT_PROP_OR(DT_NODELABEL(uart0), cts_pin, -1),
.RTS = DT_PROP_OR(DT_NODELABEL(uart0), rts_pin, -1),
.RXD = DT_PROP_OR(DT_NODELABEL(uart0), rx_pin, -1),
.TXD = DT_PROP_OR(DT_NODELABEL(uart0), tx_pin, -1),
},
.baud_rate = DT_PROP_OR(DT_NODELABEL(uart0), current_speed, 115200),
.enabled = DT_NODE_HAS_STATUS(DT_NODELABEL(uart0), okay),
.flow_control = DT_PROP_OR(DT_NODELABEL(uart0), hw_flow_control, 0),
As a workaround, I can define the following macros in one of my headers:
#define DT_N_S_soc_S_uart_40002000_P_tx_pin 5
#define DT_N_S_soc_S_uart_40002000_P_tx_pin_EXISTS 1
#define DT_N_S_soc_S_uart_40002000_P_rx_pin 20
#define DT_N_S_soc_S_uart_40002000_P_rx_pin_EXISTS 1
#define DT_N_S_soc_S_uart_40002000_P_rts_pin 15
#define DT_N_S_soc_S_uart_40002000_P_rts_pin_EXISTS 1
#define DT_N_S_soc_S_uart_40002000_P_cts_pin 7
#define DT_N_S_soc_S_uart_40002000_P_cts_pin_EXISTS 1
#define DT_N_S_soc_S_uart_40028000_P_tx_pin 17
#define DT_N_S_soc_S_uart_40028000_P_tx_pin_EXISTS 1
#define DT_N_S_soc_S_uart_40028000_P_rx_pin 3
#define DT_N_S_soc_S_uart_40028000_P_rx_pin_EXISTS 1
#define DT_N_S_soc_S_uart_40028000_P_rts_pin 40
#define DT_N_S_soc_S_uart_40028000_P_rts_pin_EXISTS 1
#define DT_N_S_soc_S_uart_40028000_P_cts_pin 22
#define DT_N_S_soc_S_uart_40028000_P_cts_pin_EXISTS 1
Then all pins are configured properly and the connectivity_bridge sample works. Further investigation shows that the build script responsible for generating devicetree_unfixed.h does not generate any pin configuration. All CPUs are affected: non-modified samples and boards produce devicetree withoult pin configuration. At this state any stock sample or user project compiled with nRF Connect SDK v2.1.0 will not function properly.
This opens the question: Why is a completely broken SDK released in first place? This is not the first time Nordic releases an SDK incapable of building working code.
4. To make debugging even harder, the following other issue comes into play: a crash in the board controller prevent users from flashing nRF9160dk if any of the UARTs are open. nRF9160dk onboard controller crash
