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

I want to migrate my project (for a custom nrf5340/nrf7002 board) from NCS2.9.0 to NCS 3.2.0, to hopefully get the wifi WPA Enterprise functionality to work. This is an existing project, already in production, that builds and works just fine(mostly) under NCS2.9.0.

Sadly, as ever when updating NCS versions, the compile is broken by multiple changes, and worse, some things compile but don't work.

The mgration guides have some info, but don't cover all the breaking changes, which IMHO is just NOT ACCEPTABLE.

Here's what I have so far:

Update to nrfx hal : version is now nrfx4:

 - breaks code for SPIMinstance initialisation method has changed

- breaks code for PDM: config and instance initialisation have changed

- breaks code for I2S : config and instance initialisation have changed
Also, do the PDM and I2S drivers need an interrupt line? I had code like this:
IRQ_CONNECT(DT_IRQN(PDM_NL),  IRQ_PRIO_LOWEST, NRFX_PDM_INST_HANDLER_GET(0), 0, 0);
which no longer compiles, but I don't see the I2S having an interrupt line in the DTS?
- breaks code using nrfx_timer : connecting the timer interrupt
Previously I had this:
        IRQ_DIRECT_CONNECT(NRFX_IRQ_NUMBER_GET(NRF_TIMER_INST_GET(1)), 0, NRFX_TIMER_INST_HANDLER_GET(1), 0);
but NRFX_TIMER_INST_HANDLER_GET() no longer exists.
I try this:
        IRQ_DIRECT_CONNECT(NRFX_IRQ_NUMBER_GET(NRF_TIMER_INST_GET(1)), 0, nrfx_timer_1_irq_handler,0);
and 
static nrfx_timer_t _t2_rep_timer = NRFX_TIMER_INSTANCE(NRF_TIMER1);   // nrfx4.0 change NRFX_TIMER_INSTANCE(1);
NRFX_INSTANCE_IRQ_HANDLER_DEFINE(timer, 1, &_t2_rep_timer);
but haven't yet been able to see if that works right or not (see below for why)
Update of zephyr:
 - breaks wifi mgmt event callbacks : functions of this signature
void _net_mgmt_event_handler(struct net_mgmt_event_callback *cb,
                    uint32_t mgmt_event, struct net_if *iface)
now need to be this:
void _net_mgmt_event_handler(struct net_mgmt_event_callback *cb,
                    uint64_t mgmt_event, struct net_if *iface)
because all the event definitions (in net_event.h and net_mgmt.h) have changed to be 64 bits long instead of 32...
Luckily I compile with warnings=>errors to catch this...
- all of the USB library functions are depreciated! (and migration to new USB stack how? hopefully the old code will still work)
 - mqtt library changed:
mqtt_disconnect() now takes 2 params instead of 1...
 - ble breaks:
The connectable advertising params 'options' bit field no longer has BT_LE_ADV_OPT_CONNECTABLE, this appears to be replaced by BT_LE_ADV_OPT_CONN (which sets bits 0 and 1 now). Will it work the same? who knows...
According to this post ( Migration from NCS 3.0.2 to 3.2.1, device-tree and USB problems.  ), The connection interval is now given in u-seconds in the “bt_conn_le_info” structure...
 - nfc library fails to link
the linker fails with errors like:
c:/ncs/toolchains/66cdf9b75e/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe: nfc_t4t_lib_al.c:(.text.nrfx_nfct_evt_handler+0x30): undefined reference to `nrfx_nfct_rx'
c:/ncs/toolchains/66cdf9b75e/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe: nfc_t4t_lib_al.c:(.text.nrfx_nfct_evt_handler+0x5a): undefined reference to `nrfx_nfct_rx'
c:/ncs/toolchains/66cdf9b75e/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe: nfc_t4t_lib_al.c:(.text.nrfx_nfct_evt_handler+0x7e): undefined reference to `nrfx_nfct_autocolres_enable'
Why? who knows?
 - ALL CODE THAT TESTS NRFX_SUCCESS FROM ANY NRFX FUNCTION NOW FAILS AT RUNTIME:
From that post and the migration guide, a little 1 liner:
- return codes from nrfx_XX functions are no longer of type nrfx_err_t, but just an int, and NRFX_SUCCESS, although still defined, is NOT what is returned for success (now 0, but NRFX_SUCCESS=0x0BAD0000)
I really couldn't believe this was possible, but yes, all the function signatures have changed in this breaking way for nrfx hal....
So all my code that does
if (nrfx_fn()==NRFX_SUCCESS) { do stuff }
compiles, but will now not work as expected...
Thats a LOT of code to update. Why on earth didn't they just redefined nrfx_err_t as int, and made NRFX_SUCCESS to be 0? And no way for my code to be compatible for both old and new...
Seriously, WTF Nordic? Do you hate developers or what? 
 - wifi code for nrf70 now uses a seperate heap : ok, but now I have 4 heaps to juggle (wifi x 2, system, libc) and if any one has a temporary burst, game over...
Is there a way to calculate the maximum size based on the number of tx/rx buffers that the wifi will need?
And then of course, the breaking issue : the flash code size has increased by around 40kB just because of the version change. No additional functionality just more crappy code. And thats the breaking change right there for my device.
I live in hope that someone from Nordic will respond and explain why its not so bad, and how I can just define another magic line in prj.conf and everything will be better.... 
But for now, I'll roll back and see if NCS 3.1.1 has the better WPA enterprise code, but without the change to nrfx4 at least....
Parents
  • Hello,

    Your feedback is noted and forwarded. I know this is something that’s being looked into, as the frequent changes can be frustrating, even when each individual change may make sense on its own.

    I suggest you break down the issues you encounter and make individual case for each of them.

    Hope this helps,
    Kenneth

  • Hope this helps,

    pretty much not at all. 

    even when each individual change may make sense on its own.

    If you assumed that noone would ever migrate from an older version of NCS, then yes, maybe refactoring your code to be 'nicer' makes sense.

    But given the frequent response on this fourm is "try updating to latest version", its not developer friendly to make breaking changes even when there is no actual need to do so. This just means your products get a bad reputation.

    I suggest you feed this back to the nrfx lib development team, and get them to work on a migration update that makes the process possible.... and work out a way so make wifi support possible without using up all the flash!

  • Especially with the new EU regulations (CRA) and the neccessary vulnerability management, I'd like to keep my project at least during development up-to-date and target the latest SDK version to be sure, that I don't ship a device with possible vulnerabilities. We will also need to support updates, so it will probably necceessary to update the SDK later as well. I'd suggest to be more careful with major changes.

Reply
  • Especially with the new EU regulations (CRA) and the neccessary vulnerability management, I'd like to keep my project at least during development up-to-date and target the latest SDK version to be sure, that I don't ship a device with possible vulnerabilities. We will also need to support updates, so it will probably necceessary to update the SDK later as well. I'd suggest to be more careful with major changes.

Children
No Data
Related