• State Verified Answer
  • Replies 6 replies
  • Subscribers 73 subscribers
  • Views 2618 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 105206
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

SDK 7 (forced) migration

Samuele Forconi

Hi, we have developed a product based on the nRF51822 using Nordic SDK v6.1.0 and S110 v7.1.0. Now we are on production and we are obliged to use the nRF51822-QFAA with Build Code Hx0. Looking at the document nWP-021 v1.0 "Migrating from the 2 nd to the 3 rd revision of nRF51822", it seems that the Build Code Hx0 is only compatible with SDK v7.x.

I downloaded the SDK v7.2.0 and I discovered that all the directories are heavily changed, the Makefiles for GCC aren't updated for the new directory layout. Moreover with the new directory layout the source files are mixed with the header files in a way that I really don't understand...

I'm writing to ask if there's a simple way to update the GCC Makefiles to use the SDK v7.2.0, or alternatively if I can replace only some files of the SDK v6.1.0 (such as the linker files and the *.s files) and continue to use the SDK v6.1.0.

Thanks for any help/suggestions.

Samuele.

Parents
  • 0

    Hi Samuele,

    I think the quickest way is to take the linker file suitable for 3rd generation of the chip from SDK 7.x and just use it in your project.

    If you want to use SDK 7.x you should not take as a reference Makefile.common file (we released it by mistake - it is outdated), but one of a Makefile from examples (we released separete Makefile for every example - they all have updated paths and other settings).

    I think that sources and headers are structured in a pretty logical way - header files are located in the same directory as source files to which they belong. We had to restructure our SDK to be able to support SDK releases in CMSIS-Pack format.

  • 0 in reply to Krzysztof Loska

    Sorry for the confusion. Now I noticed that in fact you didn't change the chip variant (like _xxaa to _xxac) but the chip revision. So probably everything should work without any changes, but be aware of the sentence from nWP-021 document: "Earlier versions of the SDK are likely to work on later versions of the device, but this cannot be guaranteed.". A good example is that a new chip revision contains anomaly resolutions. A driver intended for an earlier chip revision could have a workaround for some anomaly not needed for a later chip. Most time it does not influence a later chip but sometime it can disrupt its work.

Reply
  • 0 in reply to Krzysztof Loska

    Sorry for the confusion. Now I noticed that in fact you didn't change the chip variant (like _xxaa to _xxac) but the chip revision. So probably everything should work without any changes, but be aware of the sentence from nWP-021 document: "Earlier versions of the SDK are likely to work on later versions of the device, but this cannot be guaranteed.". A good example is that a new chip revision contains anomaly resolutions. A driver intended for an earlier chip revision could have a workaround for some anomaly not needed for a later chip. Most time it does not influence a later chip but sometime it can disrupt its work.

Children
No Data
Related
Terms of service