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

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

BrianW — Mon, 09 Feb 2026 15:56:07 GMT

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.

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

David M. M. — Mon, 09 Feb 2026 15:49:09 GMT

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.

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

BrianW — Fri, 06 Feb 2026 17:19:29 GMT

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

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

David M. M. — Tue, 20 Jan 2026 16:02:54 GMT

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,

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

David M. M. — Fri, 16 Jan 2026 13:41:33 GMT

Another remark, in the migration guide to 3.2.0, it is indicated to “Use CONFIG_NRFX_WDT instead of the following: CONFIG_NRFX_WDT0”. But, it seems that the NRFX_WDT is not configurable (has no prompt, see here). So, we’re also not sure how to use the NRFX watchdog after upgrade.