Is it possible to use sd 8.0.0 with rev 2 silicon?

[Anthony Ambuehl]

There seems to be a discrepancy between the 8.0.0 softdevice release notes and the product compatibility matrix. I would like to know if it is possible to use 8.0.0 softdevice with 8.1.1 SDK on revision 2 silicon.

It seems from the softdevice release notes that rev 2 silicon could work if:

BLE_COMMON_OPT_RADIO_CPU_MUTEX is set with sd_ble_opt_set

AND

sd_power_dcdc_mode_set(NRF_POWER_DCDC_DISABLE) is called

However the series compatibility matrix shows the shows the latest supported SDK is 6.1.0 for SD 7.1.0, and it lists no supported SDK for SD 8.0.0.

Is this "lack of compatibility" related to the examples not supporting the additional configuration of the DCDC and radio mutex?

[RK]

No you're mixing up SDK and Softdevice, despite the fact that each revision of the SDK ships with a revision of the SD, they are really very independent.

The softdevice itself is just code which runs quietly by itself and the entire communication from user code is done via SVC calls, every (pretty much) sd_* call just boils down to preparing some data in registers and calling SVC #number. All the header files for the SD have is the structures for that revision SD and the mapping of function calls to SVC calls.

So for the particular two options you mention, both of them are sd_* calls, and they are designed to tell the softdevice to turn on the CPU mutex and turn off the DCDC in order to make it compatible with rev 2.0 hardware. That's why the compatibility matrix says v8 works with rev 2.

The SDK has two types of code, code to work with the peripherals on the device, UART, TWI, timers etc and other convenience libraries which I'll come to. The hardware code is revision-specific. As the SDK has evolved many of the 'fixes' for hardware issues in older revision hardware have remained (the TWI driver still uses two PPI channels for instance) but some haven't and the newer drivers in each SDK were written for newer hardware and don't have the workarounds. So new SDK code won't necessarily work on old hardware.

Then there's the other piece of the SDK which are convenience libraries. Many of those are BTLE-related, the device manager, the advertising manager, the bonding manager. They are just code which wrap sd_ calls and other logic into modules which make it easier to do common tasks, like advertise and manage bonds. They use timers, they use pstorage, they use other things, but they are really just code libraries. They aren't hardware-specific, so they'll work on any chip revision, but they do have API dependencies on the SD and the hardware drivers. The hardware drivers don't change API contract very much (app_scheduler is an example of one that has), the SD does, it adds functions and parameters change. So older revisions of these libraries may not compile against new SDs and vice-versa, however the API contract has been stable enough that if your code does compile (with warnings turned on to make sure you're getting full argument checking etc) then there's a better than very good chance it will work, it's just code. Given the changes in directory layout between the various SDKs you'll mostly have to do some work fixing include paths to get mismatched SDK/SD code to compile.

So if you want to try it - take the SDK for your chip revision, and rip out the softdevice header files which are embedded in it. Then adjust all your include paths to point to the revision of the softdevice you want, every softdevice comes with an include directory, they are totally self-contained, just that each SDK embeds one such in it. Then start fixing compile errors and at least do a brief audit of the sd_ calls the code you're compiling is making, to ensure there aren't new options you ought to set.

[Anthony Ambuehl]

Thanks RK, I might just try this since I won't need most of the peripheral drivers. I actually found most of the new peripheral drivers to be very inefficient so would probably avoid using them anyway.