7.x.x SDK compatibility with nRF51422 - V2 chips

RE: 7.x.x SDK compatibility with nRF51422 - V2 chips

RK — Wed, 05 Aug 2015 00:27:14 GMT

I don't compile against the headers for the softdevice built-in to the SDK, you don't have to, it's just a convenience to make one package out of it. I compile library code from the SDK, although not much of it because I don't use much from the SDK, and the header paths for the softdevice come directly from the softdevice version I'm going to use. That ensures the SVC numbers are going to match.

The SD API is pretty stable at least, it does change slowly but usually in a way which shows up during compilation. As long as you use headers for the SD you're going to load and it compiles, it works fine.

RE: 7.x.x SDK compatibility with nRF51422 - V2 chips

Mark Rages — Tue, 04 Aug 2015 19:05:35 GMT

Can I rant about how annoying this whole mess of chip revisions, chip SDKs, softdevice SDKs, softdevice revisions is? I can go to Microchip and download an SDK that works for every PIC ever made. Same for MSP430, or Freescale. But Nordic can't even supply a single SDK that works with one chip number.

RE: 7.x.x SDK compatibility with nRF51422 - V2 chips

Mark Rages — Tue, 04 Aug 2015 19:03:29 GMT

The SVC numbers have changed between softdevices before (at least for S210 softdevice), instantly crashing if you compile with the wrong SDK.

RE: 7.x.x SDK compatibility with nRF51422 - V2 chips

RK — Tue, 04 Aug 2015 16:31:35 GMT

Good question and the source of much confusion. The Softdevice and the SDK really are two entirely different things. The softdevices work for a given range of chip revisions, the interface to them is very narrow indeed, it's a series of SVC calls, if the softdevice (SD) works for your chip, it works.

The SDKs are a pile of library code, they deal with peripherals, they deal with BLE services, they deal with advertisement and bonding and other things. They are mostly SD agnostic. The major compatibility issues with the SDK come not from the SD piece but from the peripheral limitations which are or aren't worked around in the SDK code.

The basic premise is if you have an SDK for library code and a SD for BLE code and you can compile it, it'll work. Doing this requires just removing the SDK SD headers and replacing with the SD you're using.

RE: 7.x.x SDK compatibility with nRF51422 - V2 chips

Mark Rages — Tue, 04 Aug 2015 16:16:54 GMT

Where would I look to find out which softdevices work with which SDK?

RE: 7.x.x SDK compatibility with nRF51422 - V2 chips

RK — Tue, 04 Aug 2015 07:49:28 GMT

so you may be using the bits of the SDK which either still have the workarounds for the rev 2 bugs and not the newer drivers, or you've been fortunate not to hit the issues for which there are no-longer workarounds. it may work in many circumstances, but it's not tested and not guaranteed and you may well have intermittent issues.

RE: 7.x.x SDK compatibility with nRF51422 - V2 chips

ImQ009 — Tue, 04 Aug 2015 07:32:12 GMT

That's interesting, because I'm using SDK 7.1 with a rev 2 chip.

RE: 7.x.x SDK compatibility with nRF51422 - V2 chips

RK — Tue, 04 Aug 2015 01:42:39 GMT

There's blank space there because there's no SDK which has the 8.0.0 SD plus library code compatible with the rev 2 chip. The last SDK with library code for the rev2 chip is 6.1, however you can use softdevice v8 with rev2 (provided you set a couple of flags).

You're really better off using two builds and two SDKs, although you could use the 6.x SDK and the 8.x softdevice on both rev 2 and rev 3, that would work, just need to figure out which chip you have at runtime and turn the flags on, or not.