Attachments (0)
Nordic Case Info
  • Case ID: 305723
Options

problems migrating nrf5340 project from SDK 1.9.1 to 2.3.0

GerardB

Dear Nordic Support

We are having problems migrating our nrf5340 project from SDK v1.9.1 to v2.3.0.
We have now spent more than 1 week on the migration & although the project builds with no (obvious) errors, the code will crash after flashing. So it won;'t run.
With SDK v1.9.1 everything works great and we can't isolate the problem with v2.3.0 & have no way of debugging it as it seems to be in a permanent reset loop after flashing/installing the version built with SDK v2.3.0.

So need your help to figure out how to fix this. Here are some details;

We are using vscode with nrfExtension on MacOS for development and latest nrfConnect version.

We have read the migration guide for v1.x to v2.x and can't see anything there that points to our problem.

We use mcuboot and OTA DFU. It all works well with v1.9.1

We do NOT have a sample.yaml file in the project.

Our west.yml file looks like this:

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
manifest:
remotes:
- name: ncs
url-base: https://github.com/nrfconnect
projects:
- name: sdk-nrf
remote: ncs
path: nrf
revision: v2.3.0
import: true
clone-depth: 1
self:
path: WS_firmware_sdk2
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Our cMakeList.tx file looks like this:

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#
#
cmake_minimum_required(VERSION 3.20.0)
#set(PM_STATIC_YML_FILE
# ${CMAKE_CURRENT_SOURCE_DIR}/boards/pm_static_${BOARD}.yml
# )
find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
project(WS_firmware_sdk2)
# NORDIC SDK APP START
target_sources(app PRIVATE
src/main.c
src/analog.c
src/usb_serial.c
src/sensor_settings.c
src/i2c_accel.c
src/i2c_pressure.c
)
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Our nrf5340dk_nrf5340_cpuapp.overlay is very simple and is the same for v1.9.1. and v2.3.0:

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
&adc {
status = "okay";
};
&button0 {
status = "disabled";
};
&button1 {
status = "disabled";
};
&button2 {
status = "disabled";
};
&button3 {
status = "disabled";
};
&uart0 {
status = "okay";
};
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Our prf.config file looks like this:

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#
# Copyright (c) 2021 WearSense LLC
#
CONFIG_PM=y
CONFIG_PM_DEVICE=y
# DC/DC JB
CONFIG_BOARD_ENABLE_DCDC_APP=y
CONFIG_BOARD_ENABLE_DCDC_NET=y
CONFIG_BOARD_ENABLE_DCDC_HV=y
# set next 4 lines to "y" for USB log/debug... (has significant power draw impact)
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_STDOUT_CONSOLE=y
CONFIG_ASSERT=n
# set next 3 lines to "y" for USB logging and uncomment 4th line (CONFIG_USB_DEVICE_PRODUCT=....)
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

We have a "child_image" folder which contains the file "hci_rpmsg.conf", which looks like this:

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
CONFIG_LOG=n #changed
CONFIG_SERIAL=n #added
CONFIG_RPMSG_SERVICE=y
CONFIG_RPMSG_SERVICE_MODE_REMOTE=y
# CONFIG_HEAP_MEM_POOL_SIZE=8192
CONFIG_MAIN_STACK_SIZE=2048
# CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048
# CONFIG_BT=y
# CONFIG_BT_HCI_RAW=y
# CONFIG_BT_MAX_CONN=2
# CONFIG_BT_CTLR_ASSERT_HANDLER=y
# CONFIG_BT_HCI_RAW_RESERVE=1
# CONFIG_BT_BUF_CMD_TX_COUNT=8
# Workaround: Unable to allocate command buffer when using K_NO_WAIT since
# Host number of completed commands does not follow normal flow control.
CONFIG_BT_BUF_CMD_TX_COUNT=10
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

The terminal log from a pristine build looks like this:

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
-- Found BOARD.dts: /opt/nordic/ncs/v2.3.0/zephyr/boards/arm/nrf5340dk_nrf5340/nrf5340dk_nrf5340_cpunet.dts
-- Generated zephyr.dts: /Users/gerardbucas/Documents/GitHub/WS_firmware_sdk2/build/hci_rpmsg/zephyr/zephyr.dts
-- Generated devicetree_generated.h: /Users/gerardbucas/Documents/GitHub/WS_firmware_sdk2/build/hci_rpmsg/zephyr/include/generated/devicetree_generated.h
-- Including generated dts.cmake file: /Users/gerardbucas/Documents/GitHub/WS_firmware_sdk2/build/hci_rpmsg/zephyr/dts.cmake
warning: UART_CONSOLE (defined at drivers/console/Kconfig:43) was assigned the value 'y' but got the
value 'n'. Check these unsatisfied dependencies: SERIAL (=n), SERIAL_HAS_DRIVER (=n). See
http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_UART_CONSOLE and/or look up UART_CONSOLE in
the menuconfig/guiconfig interface. The Application Development Primer, Setting Configuration
Values, and Kconfig - Tips and Best Practices sections of the manual might be helpful too.
Parsing /opt/nordic/ncs/v2.3.0/zephyr/Kconfig
Loaded configuration '/opt/nordic/ncs/v2.3.0/zephyr/boards/arm/nrf5340dk_nrf5340/nrf5340dk_nrf5340_cpunet_defconfig'
Merged configuration '/opt/nordic/ncs/v2.3.0/zephyr/samples/bluetooth/hci_rpmsg/prj.conf'
Merged configuration '/opt/nordic/ncs/v2.3.0/nrf/subsys/bootloader/image/secure_boot.conf'
Merged configuration '/opt/nordic/ncs/v2.3.0/nrf/subsys/partition_manager/partition_manager_enabled.conf'
Merged configuration '/Users/gerardbucas/Documents/GitHub/WS_firmware_sdk2/child_image/hci_rpmsg.conf'
Merged configuration '/Users/gerardbucas/Documents/GitHub/WS_firmware_sdk2/build/hci_rpmsg/zephyr/misc/generated/extra_kconfig_options.conf'
Configuration saved to '/Users/gerardbucas/Documents/GitHub/WS_firmware_sdk2/build/hci_rpmsg/zephyr/.config'
Kconfig header saved to '/Users/gerardbucas/Documents/GitHub/WS_firmware_sdk2/build/hci_rpmsg/zephyr/include/generated/autoconf.h'
-- The C compiler identification is GNU 12.1.0
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

The project folder looks like this:

As per this devzone suggestion: https://devzone.nordicsemi.com/f/nordic-q-a/97081/ncs-v2-3-0-rc1-ota-dfu-does-not-compile, we removed the 5 lines of code recommended there.

I would REALLY appreciate it if you could look at the above and let me know if there are any obvious issues with any of the above.

As I mentioned, the project seems to build OK but after flashing, the code seems to go into an endless "reset loop" (seems to crash immediately after it starts up). Yet the same code seems rot work (with minor changes to add zephyr/ prefix to #include paths) perfectly when built with v1.9.1.

Thanking you in anticipation.

Gerard.

Terms of service