• State Not Answered
  • Replies 4 replies
  • Subscribers 86 subscribers
  • Views 168 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 357825
Options

NCS v1.7.0 Toolchain for nRF9160 + nRF52840 Dual-IC Gateway (Fanstel BLG840FB4) — Build Environment and Migration Guidance

Kirolos Sedra
Hi Nordic team,
We have a production firmware developed on nRF Connect SDK v1.7.0 targeting a Fanstel BLG840FB4 gateway module (nRF9160 SiP + nRF52840 SoC). We are trying to rebuild the firmware from source and are hitting toolchain and environment issues. We would appreciate Nordic's guidance on the following.

1. Correct Toolchain for NCS v1.7.0
The nrfutil sdk-manager only lists SDK versions from v2.0.0 onward. We understand v1.7.0 can be set up manually via west init / west update. Could you confirm:
The exact GCC ARM Embedded Toolchain version validated against NCS v1.7.0 — we believe it is gcc-arm-none-eabi-10-2020-q4-major. Can you confirm?
The correct Zephyr SDK version, if applicable.


2. nRF9160 Modem Firmware Compatibility
Which modem firmware version is validated with NCS v1.7.0? We want to ensure our modem firmware is compatible before flashing.

3. Migration Path if v1.7.0 Is No Longer Practical
If Nordic considers NCS v1.7.0 too old to support, what is the recommended minimum migration target for an existing nRF9160 LTE + nRF52840 BLE codebase? We are looking for the version that requires the least refactoring of:
  • LTE link control and modem libraries
  • MQTT / TLS socket APIs
  • Multi-image build (nRF9160 + nRF52840)
We suspect NCS v2.1.x or v2.2.x may be the closest stepping stone from 1.7.0, before the larger TF-M and sysbuild changes landed. Can you confirm whether that is a reasonable migration path, or if there is a better target?

4. Board Support
The BLG840FB4 is a Fanstel product. We are requesting board-level DTS/overlay files from Fanstel separately. If Nordic has any generic dual-IC gateway reference (nRF9160 + nRF52840) board definitions that may be close to this hardware, pointers would be helpful.

Environment Details
ItemDetailHost OS Windows 11 and Windos 10 Current NCSv1.7.0 (cloned via west)Target hardwareFanstel BLG840FB4 (nRF9160 SICA + nRF52840 QIAA)Use caseBLE-to-LTE gateway, MQTT over TLS to cloud. 





Thank you for any guidance.
Best regards,
Kirolos
  • 0

    My 2 cent (I'm just an other user):

    AFAIK the Fanstel module was just using the nRF9160-DK board definitions with an overlay (at least that was the case 2 or 3 years ago, when I was testing it).

    Even NCS v2.2.x is somehow deprecated, the current versions would be v.3.2.3 (or v3.1.2).

    How hard it will be to migrate from a that old version (1.7), isn't easy to say.

    In some cases, the app was build adapting a sample, e.g. the a http, mqtt, coap or udp sample. If so, it may be easier to use the current version of that sample and try to adapt that again.

  • 0

    Hi Kirolos,

    2. nRF9160 Modem Firmware Compatibility
    Which modem firmware version is validated with NCS v1.7.0? We want to ensure our modem firmware is compatible before flashing.

    Regarding your second question, see here.

    I will have to get back to you on the rest of these questions later this week.

    Regards,

    Elfving

  • 0

    Hi again, and thanks for the patience on this case. I was waiting for a few of my go-to resources for these topics who were away on a trade-show this past week, and see that it took a bit longer than I originally expected.

    what is the recommended minimum migration target for an existing nRF9160 LTE + nRF52840 BLE codebase? We are looking for the version that requires the least refactoring of:

    I agree with the line of thinking here, migrating can often essentially mean remaking the entire application unfortunately, so opting for one without huge changes needed sounds tempting.

    We do not use the word deprecated lightly. But using the newest is ofcourse best.

    It might for instance be worth mentioning that LTE link control had big refactoring into modules in 2.8.0. And like you mention, sysbuild is a big change that might require some of extra work. There has been changes in TFM in 2.2, but along with them came PSA 1 certification, so you also need to consider whether that is important to you. SPM was removed and replaced by TFM in NCS 2.3. In 2 we switched to the zephyr toolchain and got eg. pinctrl. (though that is arguably not as much of a problem as eg. TFM).

    I guess that can sound like an argument for 1.9 or 2.1, then, but that is still a little leap and might require several changes (I would recommend browsing through the migration guides). So since this would be a bit of work either way, I would also consider going all the way to the newest, even though that would essentially mean recreating everything - Unless there is a certain older feature you need ofcourse. 

    So to sum up, it is a bit hard to recommend a certain NCS version here. There are minor changes all over, and a few bigger ones you might be hit with depending on your application. 

    3. Migration Path if v1.7.0 Is No Longer Practical

    Well the most practical is to use what is newest. We would keep supporting you no matter what NCS versions you use, although supporting can mean a lot of different things. There could for instance be a known bug, where the go-to solution is to switch to another NCS version - but I would still say that we support all NCS versions. nRF5 SDK however is in maintence mode and we support that to a lower degree, and the old nRF5 "add-on" zigbee SDK is completely deprecated. But even with that, I could still try to help some-one with that one if you were desperate enough.

    1. Correct Toolchain for NCS v1.7.0
    The nrfutil sdk-manager only lists SDK versions from v2.0.0 onward. We understand v1.7.0 can be set up manually via west init / west update. Could you confirm:
    The exact GCC ARM Embedded Toolchain version validated against NCS v1.7.0 — we believe it is gcc-arm-none-eabi-10-2020-q4-major. Can you confirm?
    The correct Zephyr SDK version, if applicable.

    I believe that is correct, but I rarely find that using the wrong toolchain gives me any big issues. What sort of issues are you running into? Do you have error logs?

    The BLG840FB4 is a Fanstel product. We are requesting board-level DTS/overlay files from Fanstel separately. If Nordic has any generic dual-IC gateway reference (nRF9160 + nRF52840) board definitions that may be close to this hardware, pointers would be helpful.

    I think it might be an idea to get this from them. Though I guess it is worth noting that the 91DK does have a 52840 onboard. The HW files and dts for that is ofcourse available. What Achim says here about the only thing being added here is an overlay file sounds believable.

    Regards,

    Elfving

  • 0

    Hi again! I just want to note two more things:

    I was just made aware of that it says in VSC that versions <2 are deprecated. The wording there can be a bit misleading - the use of those NCS versions in VSC are not supported, but if you are fine using SES, those NCS versions are still supported by us.

    Another thing is that you typically do not want to switch toolchains in an already existing project unless you are very pressed into doing so, so switching to a version <2 might make the most sense for that reason.

    Regards,

    Elfving

Related
Terms of service