Migration from nRF5 SDK to nRF Connect SDK

RE: Migration from nRF5 SDK to nRF Connect SDK

papatel — Mon, 26 Feb 2024 09:57:57 GMT

Not sure about your designs Samuele, but for our company, we standardized on a single SOC for all our designs and maintained pin consistency across all designs as much as possible. For the minor deviations where a GPIO had to be reassigned from an input or output or a flash chip is present or not, we can configure those deviations at run time based on UICR. You can still use Customer UICR registers to indicate features/versions etc... and have your code execute accordingly.

If your designs deviate massively in pin assignments and features, this approach will be problematic. But as you indicated, your designs are mostly the same and are focused on beaconing/indoor positioning, I think this approach will work.

RE: Migration from nRF5 SDK to nRF Connect SDK

Samuele Forconi — Fri, 15 Dec 2023 16:05:13 GMT

Ok Susheel,

thanks anyway for your support.

RE: Migration from nRF5 SDK to nRF Connect SDK

Susheel Nuguru — Thu, 14 Dec 2023 12:41:00 GMT

Samuele,

We do not seem to have any clear solution for this.

I think one solution can be to use nrfx driver directly instead of the Zephyr driver and you can control initialization and power control of peripheral in application.

RE: Migration from nRF5 SDK to nRF Connect SDK

Susheel Nuguru — Fri, 08 Dec 2023 09:08:11 GMT

Sorry for delays Samuele,

Your use case seems genuine, I will ask around internally to see if there were any other requests or if anyone else succeeded in having one firmware for different boards with NCs. If yes, I will find out more info on how to do it.

RE: Migration from nRF5 SDK to nRF Connect SDK

Samuele Forconi — Tue, 05 Dec 2023 16:39:29 GMT

Hi Susheel,

thanks for your feedback.

As I told in the previous message, our company makes BLE products mainly focused for indoor positioning and location based systems. We have at least 15 boards to manage and each one has its own hardware I/Os - i.e. some of them have an accelerometer, some of them have a RGB led, some monochrome led(s), some have button(s), etc...

The firmware that runs on these boards is mainly focused on the BLE advertising, as well as manage the hardware peripherals (i.e. speed-up/down advertising interval if movemnt is detected, etc.).

The firmware application logic is the same for all the boards.

The production department uses a custom programming software to program the firmware on the boards.

The production programming software let the operator choose on which board the firmware will be programmed and many other options that builds up the so called factory configuration.

With this kind of architecture, if a bug or if a new feature is introduced in the firmware, a single new firmware is released for all the boards and this is possible because when the firmware starts up it detects on which board is running by looking at the factory-written UICR register where the board identifier is set (during production).

With nRF Connect we will need to build 15 different firmwares (that are mainly all equal because the only thing that changes is the pin connections), but we will need to maintain many firmware versions both on production and in the cloud environment for the update via DFU-OTA.

I think that the approach of nRF Connect SDK is good for developers and makers, but today hardware companies are forced to have many models of their hardware to face every client needs, and being forced to have one-firmware-per-board I think is an SDK limitation.

RE: Migration from nRF5 SDK to nRF Connect SDK

Susheel Nuguru — Mon, 04 Dec 2023 07:53:13 GMT

Hi Samuele,

It might have been somehow manageable for you to have one firmware for all your products and boards and then detect the hardware versions later at run time in the nRF5SDK but in the nRF Connect SDK, this will be very very tricky. There are lot of settings in the device tree file based on a product and the board where many of the nodes/peripherals are set default enabled or disabled. If you have to follow the same strategy of detecting your board at runtime, then you most likely need to keep all the peripherals and modules enabled by default and then make sure that in runtime after you detect the right version of the hardware, disable the hardware peripherals which are not relevant for that product. There is a lot of risk involved in managing the power and security efficiency this way.

[quote user=""]We would like to have a single firmware file usable for many boards where the firmware initializes the boards I/O dinamically at runtime (i.e. reading the model number of the board from a UICR register).[/quote]

Not sure why you would like to have a single firmware file this way. Could be achievable but I do not recommend this.