• State Verified Answer
  • Locked Locked
  • Replies 1 reply
  • Subscribers 90 subscribers
  • Views 1043 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 287055
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

What are nRF52840 SoC revision impacts on SDKs?

Lucas Gabriel Coliado Bandeira

Hello,

I've been developing an application with nRF52840 and I've been reviewing the appropriate SDK to start with. I see Nordic recommends starting with nRF Connect SDK and using Zephyr.

I've read the compatibility matrix and it seems to imply that the SoC revision can make or break compatibility when developing. I've ended up with the following 3 questions:

1) My SoC ends with QIIAC0 - is this revision 1? 

2) I had been working with SDK 17.0.2 so far. I can compile, flash and use my application and it seems normal with nrfjprog. Is it possible that incompatible SDKs can produce half functional binaries for SoCs that can break unexpectadly?

3) What are the risks of working under early revisions of this SoC and downgrading the SDKs to reflect this?

Thanks.

Parents
  • +1

    Hi,

    1) My SoC ends with QIIAC0 - is this revision 1? 

    That is revision 1. You can see that from SoC revisions and variants.

    2) I had been working with SDK 17.0.2 so far. I can compile, flash and use my application and it seems normal with nrfjprog. Is it possible that incompatible SDKs can produce half functional binaries for SoCs that can break unexpectadly?

    Except for engineering versions, the SDK's typically never stop supporting existing versions. So the main problem here is if you use a newer IC revision than what is supported by the SDK you are using (or specifically the MDK, which is part of the SDK's in addition to being available stand-alone). There are differences here over time, but generally you should ensure that the SDK supports the IC revision you are using. If it does not, it may be enough to upgrade to a MDK that does. If the IC revision is not supported (typically because it is too new to be recognized by the MDK), you can see serious issues. Later MDK revisions has been updated to handle this better, so that an unknown revision is assumed to be identical to the latest known to the MDK, which is in most cases good enough. That is not the case in SDK 17.0.2 though, so if you migrate to the latest nRF52840 revision (revision 3), you must update to SDK 17.1.0 (or replace only the MDK files).

    3) What are the risks of working under early revisions of this SoC and downgrading the SDKs to reflect this?

    There is no reason to use a earlier SDK version because you are using an earlier IC. You typically want to use the latest SDK in any case to get the latest features, bug fixes and errata workarounds regardless of which IC revision you are using. The only problem is using new IC revisions with old SDK/MDK versions.

Reply
  • +1

    Hi,

    1) My SoC ends with QIIAC0 - is this revision 1? 

    That is revision 1. You can see that from SoC revisions and variants.

    2) I had been working with SDK 17.0.2 so far. I can compile, flash and use my application and it seems normal with nrfjprog. Is it possible that incompatible SDKs can produce half functional binaries for SoCs that can break unexpectadly?

    Except for engineering versions, the SDK's typically never stop supporting existing versions. So the main problem here is if you use a newer IC revision than what is supported by the SDK you are using (or specifically the MDK, which is part of the SDK's in addition to being available stand-alone). There are differences here over time, but generally you should ensure that the SDK supports the IC revision you are using. If it does not, it may be enough to upgrade to a MDK that does. If the IC revision is not supported (typically because it is too new to be recognized by the MDK), you can see serious issues. Later MDK revisions has been updated to handle this better, so that an unknown revision is assumed to be identical to the latest known to the MDK, which is in most cases good enough. That is not the case in SDK 17.0.2 though, so if you migrate to the latest nRF52840 revision (revision 3), you must update to SDK 17.1.0 (or replace only the MDK files).

    3) What are the risks of working under early revisions of this SoC and downgrading the SDKs to reflect this?

    There is no reason to use a earlier SDK version because you are using an earlier IC. You typically want to use the latest SDK in any case to get the latest features, bug fixes and errata workarounds regardless of which IC revision you are using. The only problem is using new IC revisions with old SDK/MDK versions.

Children
No Data
Related
Terms of service