Recommended workflow to update sdk_config.h ?

[Magoo]

Hi,

my question might sound a bit silly, but I am certain that someone already faced the problem therefore I am wondering how it was addressed.

The question:

what is the recommended workflow to migrate the sdk_config.h file of a Nordic SDK software project from an older SDK version to a newer one?

I have started a project with SDK 15.0.0 and would like to migrate it to SDK 15.2.0 due to obvious advantages of the newer SDK version.

The problem is that sdk_config.h has undergone a large overhaul between SDK 15.0.0 and 15.2.0. It is not simply a few lines of code added at the end of the file, but the whole file structure is different (sections pertaining to certain features have been moved to other places in the file).

Since the sdk_config.h in my project contains several personalizations (which I cannot all remember with absolute certainity), I am in trouble to transfer these changes to the new sdk_config.h

I have tried to run a side-by-side file comparison between the new (v15.2.0) sdk_config.h and my (v15.0.0) personalized version of the same file. But for the reasons exposed above, this method is impractical. 

Using CMSIS configuration wizard to "copy" the changes implemented in my original sdk_config.h file to the new one does not work either, because some features have changed name or have been moved or removed. And besides, CMSIS configuration wizard is not able to show all the details in the file.

As a last resort, I tried to "manually" scan through my old sdk_config.h file and locate the corresponding items in a new "original" v15.2.0 sdk_config.h file and implement the personalizations one by one in an editor.
This took me several hours of work and the result was unsatisfactory because I must have messed up some CMSIS formatting tags with the result that the file can no longer be opened with the CMSIS configuration wizard.

I would hate having to repeat such a nightmare the next time I will have to migrate my project to a newer SDK.

Therefore here is my question:

What is the recommended workflow to migrate a (already customized) sdk_config.h file from an older SDK version to a newer one, without loosing the customizations and with the lowest risk of human errors?

THANKS for any valuable suggestion!!!

[AndreasF]

Hi.

The API included in sdk_config.h in SDK 15.2 should be the same as the API included in the major versions sdk_config.h (SDK 15.0). This should apply for all major and minors (ex API should be the same in SDK 14.0, 14.1, 14.2, but it might not be the same from 14.0 to 15.0).

With this in background, if you are working on a example project, the content of the sdk_config.h file should contain the same in SDK 15.0 as in SDK 15.2. Where the different #defines are placed should not matter, unless you want a clear structure of where you place your different #defines.

You could use the USE_APP_CONFIG macro to place the #defines which you miss in SDK 15.2 from SDK 15.0 in a seperate configuration file you name app_config.h.

Like this:

#ifndef APP_CONFIG_H__
#define APP_CONFIG_H__

#include <stdbool.h>

/**
 * @defgroup APP_SDK_CONFIG SDK configuration
 *
 * Application-specific SDK configuration settings are provided here.
 *
 * @{
 */

/* Override default sdk_config.h values. */
#define THE
#define DEFINES
#define THAT
#define ARE
#define DEFINED
#define HERE
#define WILL
#define OVERRIDE
#define THE
#define DEFINES
#define DONE
#define IN
#define sdk_config.h

/** @} end of APP_SDK_CONFIG */

#endif /* APP_CONFIG_H__ */

And then you edit the top of your sdk_config.h file to:

#define USE_APP_CONFIG
#ifdef USE_APP_CONFIG
#include "app_config.h"
#endif

Using this technique also allows you to be more thorough with adding only the nessesary defines, if you read the API on the infocenter and are aware of which defines you require.

I hope this helps you, best regards.

Andreas

[Magoo]

Dear Andreas,

thank you for the explanations and the useful suggestion with the USE_APP_CONFIG macro!

It is good to know that APIs are retained throughout all versions having the same major (e.g. v15.x.y).
But that still does not completely answer the question to these developers who would like to migrate from SDK 14 (or SDK 13 or even older) to SDK 15.
I'm sure that there are many fellow developers out there who are in this situation. What workflow would you recommend in that case?

And returning to my original question (= migrating from SDK 15.0.0 to 15.2.0) I see that I cannot simply copy the sdk_config.h file from the project in v15.0.0 to v15.2.0.

I don't care much about the position of the #defines in the file. But I'm worried about the large number of changes. Here just a few of those that matter in my case:

1. sdk_config.h in SDK 15.2.0 contains many new (or renamed) #defines which assign a value or a macro to a keyword. This is particularly true within the "nRF_Crypto" and "nRF_Logger" sections. I can imagine that if these statements are missing (which would be the case if I simply copy the sdk_config.h file from my SDK 15.0.0 project to the 15.2.0 project), the software would not run correctly or would not even compile/link.
2. the majority (if not all) interrupt priorities (#define xxxx_IRQ_PRIORITY) in the section "nRF_Drivers" have been changed from 6 (in SDK 15.0.0) to 7 (in SDK 15.2.0). The question that arises here is: when I migrate my project (which was running stable under SDK 15.0.0) should I keep the interrupt priorities at 6 or change them to 7 with the new SDK? This decision can have a significant impact on the code behavior!
3. while developing my project, I have put together parts of sdk_config.h taken from various SDK example projects (i.e. from an usb peripheral example project and from a ble peripheral example project) because I needed these functionalities. If I migrate the whole thing to SDK 15.2.0 and start from scratch with a genuine "global" sdk_config.h file (which is supposed to be the one found in /SDK/config/nRFxxxx/config/, according to this discussion), some of the #defines needed in my project will be missing. Does this mean that I have to scan through the updated (SDK 15.2.0) project examples and copy the relevant parts in their sdk_config.h file to my "new" sdk_config.h file? I hope not, because that's a lot of work with a great risk of screwing up things...
4. (see above): what should I do if I decide to leapfrog SDK 15.2.0 and wait until SDK 16.0.0 is released to migrate my project? I mean, given the complexity of migrating between two minor versions, what should I expect when I have to migrate between two major versions?

Looking at all these difficulties (potential sources of trouble) I wonder if Nordic is suggesting to stay updated with the SDK or if they recommend to stick with the same (old) SDK for the entire lifetime of a product?

For how long will older SDK versions receive technical support?

Thank you!

Best regards

[AndreasF]

Hi again.

 

Magoo said:

It is good to know that APIs are retained throughout all versions having the same major (e.g. v15.x.y).
But that still does not completely answer the question to these developers who would like to migrate from SDK 14 (or SDK 13 or even older) to SDK 15.
I'm sure that there are many fellow developers out there who are in this situation. What workflow would you recommend in that case?

I would suggest you follow the migration guides on the infocenter, for example this one (from SDK 14.2 to SDK 15.0)

 There are different migration guides for a older SDK version to a newer SDK version.

Magoo said:

the majority (if not all) interrupt priorities (#define xxxx_IRQ_PRIORITY) in the section "nRF_Drivers" have been changed from 6 (in SDK 15.0.0) to 7 (in SDK 15.2.0). The question that arises here is: when I migrate my project (which was running stable under SDK 15.0.0) should I keep the interrupt priorities at 6 or change them to 7 with the new SDK? This decision can have a significant impact on the code behavior!

 The interrupt priority levels 6 and 7 are below the SoftDevice, so there shouldn't be any issue. Read here about interrupt priority level.

Magoo said:

while developing my project, I have put together parts of sdk_config.h taken from various SDK example projects (i.e. from an usb peripheral example project and from a ble peripheral example project) because I needed these functionalities. If I migrate the whole thing to SDK 15.2.0 and start from scratch with a genuine "global" sdk_config.h file (which is supposed to be the one found in /SDK/config/nRFxxxx/config/, according to this discussion), some of the #defines needed in my project will be missing. Does this mean that I have to scan through the updated (SDK 15.2.0) project examples and copy the relevant parts in their sdk_config.h file to my "new" sdk_config.h file? I hope not, because that's a lot of work with a great risk of screwing up things...

 I think that discussion might have been a bit confusing for you, here is what i would to:

Use the ble_template_project sdk_config.h file found in nRF5_SDK_15.2.0_clean\examples\ble_peripheral\ble_app_template\pca10040\s132\config.

This file should have all the defines you need listed. You said you have CMSIS configuration wizard, and you have used code from various different examples, so what i would do is:

Open the example you have used code from in Segger Embedded Studio and CMSIS Configuration for the sdk_config.h file in this example, on one screen.

Open the template project in Segger Embedded Studio and CMSIS Configuration for the sdk_config.h file in the tutorial example, on one another screen.

You know which libraries you have used, so you should just simply compare each CMSIS Configuration wizard with eachother. Like this:

I still can see that this might be a bit work, but I think it's a decent method to do it.

When you are done, the sdk_config.h file in the template project should be configurated correct.

Magoo said:

(see above): what should I do if I decide to leapfrog SDK 15.2.0 and wait until SDK 16.0.0 is released to migrate my project? I mean, given the complexity of migrating between two minor versions, what should I expect when I have to migrate between two major versions?

 Again, there will be migration guides from one SDK to another, both major and minor.

 

Magoo said:

Looking at all these difficulties (potential sources of trouble) I wonder if Nordic is suggesting to stay updated with the SDK or if they recommend to stick with the same (old) SDK for the entire lifetime of a product?

 This depends, if your product works well and don't require any new features, you could stick with the old SDK

If you have bugs or require new features, you should upgrade.

We do recommend that you have DFU capabilites.

Magoo said:

For how long will older SDK versions receive technical support?

They will always receive techincal support.

Best regards.

Andreas

[Magoo]

Dear Andreas,

thank you very much for all your useful information. It really helps and I will try to follow these instructions when migrating the project to a newer SDK version.

And thank you for drawing my attention to the existence of a migration guide (which I was not aware of).
In fact it is rather well hidden in the tree structure of the SDK documentation (under the "Getting Started" section, and only for X.0.0 SDK major versions).

Regarding the ble_template_project whose sdk_config.h you recommend when starting from scratch during a migration: just a hint which might be useful to other readers: the description of the project can be found in the online Infocenter (or in the newer online Documentation Library), however not under the name "ble_app_template" but under the name "Template Application":
- in Infocenter here: Examples > Bluetooth low energy examples > BLE Peripheral > Template Application
- in Documentation Library here: Examples > Bluetooth low energy examples > BLE Peripheral > Template Application

My conclusion to all this discussion is that I will try to "clean" my sdk_config.h file back to its genuine "factory" form as much as possible, by moving all the customizations (including overrides of #defines contained in sdk_config.h) to a separate app_config.h file and follow your instructions using the USE_APP_CONFIG macro (see above).
This should simplify the future migration efforts, which still requires quite some work and presents risks of introducing potential errors.
I also understand that such a migration should not be attempted while under project delivery deadline pressure, but should be planned with sufficient time margin.

Best regards.

[nordev]

Hi Andreas, thank you for this code snippet -- it is extremely helpful. Would you kindly explain how/why the defines in app_config.h override the defines in sdk_config.h? How does the preprocessor know that app_config.h should take precedence?

Since #include app_config.h is at the beginning of the sdk_config.h file, based on this and this, you would think that when the same things get defined later in sdk_config.h, those #defines would override the #defines in app_config.h, undoing your custom configs. 

EDIT: never mind, no reply needed. I see that sdk_config.h is full of #ifndef and #define, so that it doesn't overwrite things that are already defined.