How to identify SDK version?

[rookie]

This question was asked a few years ago, but I don't know if the feedback was incorporated. I'm working on SDK 16 and was wondering if there is an internal constant that identifies the SDK version that is released. The current version is 16.0.0_98a08e2 that is only appended to the SDK zip file name.

[tesc]

Hi,

SDK version is reflected in the zip name (and thus default folder name when you extract it.) You can also find the version number listed in the release notes (<sdk folder>/documentation/release_notes.txt) and documentation overview page (<sdk folder>/documentation/index.html).

There is no indication in hex files what SDK the firmware was made with, but for all SoftDevices there is a Firmware ID (FWID) that can be used to figure out SoftDevice version and variant, which again is indicative of SDK version.

Regards,
Terje

[awneil]

It would be useful to have some sort of SDK version in the SDK source, at least.

[tesc]

Hi,

Indeed. That reminds me you do get a clue from the license text printed atop of the source files, from the end year of the copyright notice.

I'll hear if we can include SDK version text as well, the same way we add the license text to source files as part of the release process.

Regards,
Terje

[StefXinet]

Dear tesc,

unfortunatly having the version in the txt file does not solve the problem.

It would be better to have some #defines in code.

[tesc]

Hi,

Thank you for the reminder on this issue.

Unfortunately there is still no such mechanism in nRF5 SDK. There is a similar mechanism for the connectivity firmware used by pc-ble-driver, see the addition of the struct named "version_info_t" in the .patch files at https://github.com/NordicSemiconductor/pc-ble-driver/tree/master/hex for how this is added to the serialization example from the nRF5 SDK. The relevant code:

typedef struct __attribute__((packed))
{
        uint32_t    magic_number;               /* Magic number to verify the presence of this structure in memory */
        uint32_t    struct_version     : 8;     /* Version of this struct format */
        uint32_t    rfu0               : 24;    /* Reserved for future use, shall be 0xFFFFFF */
        uint32_t    revision_hash;              /* Unique revision identifier */
        uint32_t    version_major      : 8;     /* Major version number */
        uint32_t    version_minor      : 8;     /* Minor version number */
        uint32_t    version_patch      : 8;     /* Patch version number */
        uint32_t    rfu1               : 8;     /* Reserved for future use, shall be 0xFF */
        uint32_t    sd_ble_api_version : 8;     /* SoftDevice BLE API version number */
        uint32_t    transport_type     : 8;     /* Connectivity transport type, 1 = UART HCI */
        uint32_t    rfu2               : 16;    /* Reserved for future use, shall be 0xFFFF */
        uint32_t    baud_rate;                  /* UART transport baud rate */
} version_info_t;
#if defined ( __CC_ARM )
static const version_info_t version_info __attribute__((at(0x50000))) = 
#elif defined ( __GNUC__ ) || defined ( __SES_ARM )
volatile static const version_info_t version_info  __attribute__ ((section(".connectivity_version_info"))) = 
#elif defined ( __ICCARM__ )
__root    const version_info_t version_info @ 0x50000 = 
#endif
{
    .magic_number       = 0x46D8A517,
    .struct_version     = 2,
    .rfu0               = 0xFFFFFF,
    .revision_hash      = 0,
    .version_major      = APP_VERSION_MAJOR,
    .version_minor      = APP_VERSION_MINOR,
    .version_patch      = APP_VERSION_PATCH,
    .rfu1               = 0xFF,
    .sd_ble_api_version = NRF_SD_BLE_API_VERSION,
    .transport_type     = 1,
    .rfu2               = 0xFFFF,
    .baud_rate          = SER_PHY_UART_BAUDRATE_VAL,
};

You could add something similar yourself. However such a proprietary solution would mean that you would have to keep track of the mapping between struct and application version / SDK version / etc. yourself.

There is currently no such mechanism in the nRF Connect SDK either, but I will report internally that this is something we should look into.

Regards,
Terje