Migration from NCS 3.0.2 to 3.2.1, device-tree and USB problems.

[David M. M.]

Hi,

We are working on the nrf5340 and our current device firmware uses the NCS 3.0.2 (i.e. nRF Connect SDK 3.0.2). We wanted to try an upgrade to NCS 3.2.1 and followed both migration guides to 3.1.0 and 3.2.0. However, we got plenty of problems with our custom-board device-tree and with USB.

• For the device tree, the base nrf5340 definitions for partitions seem to have changed, including for ram.
• For USB the situation with Zephyr is complicated because the previous “USB device support” is deprecated (covering CDC ACM) and it seems that a new “USB device support (NEXT)” is proposed. With new KConfig option prefixed with CONFIG_SAMPLE_USBD_.

We didn’t find mention of these changes in the migration guides.

Did we missed something in the documentation?

As a side note, Zephyr changed from 4.0 to 4.2 between the two NCS (3.0.2 and 3.2.1) and we didn’t find mentions of this or a migration guide from Zephyr.

[David M. M.]

Hi,

We figured out how to fix the upgrade. Below are some notes on our issues and solutions:

• 25% Zephyr/HAL footprint increase: By upgrading from NCS 3.0.2 to 3.2.1, our minimal test project increased in size by 25%. 393kB is now used by Zephyr and Nordic HAL (nrf/nrfx) which is a lot since we don’t use much features, and the guide to reduce Zephyr footprint will not help in this case. I don’t know how Nordic could continue with nRF52 and nRF53 without dropping flash-heavy features such as bootloader or TF-M. It is also unfortunate that Nordic discourages the use of its HAL, which could be a solution to this flash-footprint problem. This is not new.
• Changes in partition’s DTSI location: In the boards, the files that specify partitions have changed location. They are now located in “\zephyr\dts\vendor\nordic” instead of “\zephyr\dts\common\nordic”. However the “vendor” folder can be omitted in the include, i.e. “#include <nordic/nrf5340_cpuapp_partition.dtsi>” should be used instead of “#include <common/nordic/nrf5340_cpuapp_partition.dtsi>”.
• In NRFX HAL, the NRFX_SUCCESS return value is not used any more: For NRFX modules such as TWIM, GPIOTE, PWM, return values have been modified. If you assume that the condition “nrfx_twim_xfer(&i2c1_handle, &i2c_xfer_desc, 0) == NRFX_SUCCESS” is a valid condition, you’re wrong, you must test “nrfx_twim_xfer(&i2c1_handle, &i2c_xfer_desc, 0) == 0”. Error codes have been changed such as “-EALREADY” must be used instead of “NRFX_ERROR_ALREADY”. The NRFX_SUCCESS was already a strange definition with a value of 0x0BAD0000...
• BLE connection interval in micro-seconds (not everywhere): The connection interval is now given in u-seconds in the “bt_conn_le_info” structure. However, the callback function for connection parameter update, still returns an interval in 1.25ms/LSB!
• Watchdog: Without any sample for using NRFX watchdog, we had to reimplement it using the Zephyr watchdog. As I mentioned above, it is unfortunate that the use of the HAL is discouraged. I personally think that something like watchdog should be as simple as possible, and the Zephyr layer is a bad idea.

Good luck, and I hope Nordic engineers will reevaluate the role of their HAL.

Best,

[BrianW]

Hi

I am going through the same pain (2.9.0 to 3.2.1) and agree the migration documents are lacking several breaking changes...

What did you do about the USB driver depreciation?

thanks

brian

[David M. M.]

Hi,

For the moment we stay with the old (deprecated) USB driver and it works.

We use USB CDC ACM and the new USB driver by Zephyr seems very similar for this use case.

Good luck.

[BrianW]

Ok, thanks for the info.

Right now I'm not going to migrate up to 3.2.x due to the nrfx4 breaking changes, as I'll have to redo a lot of code due to the NRFX_SUCCESS madness.

I'm trying to at least get to 3.1.1 but even that is hard (flash size issues with wifi, especially WPA_ENTERPRISE.)

See  Migration from NCS 2.9.0 to NCS 3.2.1 is hard, not well documented and will break all nrfx code.