RE: nRF52 silicon and SoftDevice compatibility

Vidar Berg — Mon, 29 Feb 2016 15:09:23 GMT

Hi,

It is possible that an old PAN workaround in s132_nrf52_2.0.0-4.alpha is causing the behavior you describe on QFAABA . I'd suggest to try one of the BLE examples from SDK 11 alpha with s132 v.2.0.0 alpha-7 and see if you get the same result.

Further, will we also have to update the SDK if we're migrating to SoftDevice v2.0.0?

It's is not a requirement, the migration document found in the s132 v.2.0.0 download folder provides instructions on how to migrate your code. This will probably be easier when SDK 11 is out so you can use it as reference.

With regards to PCA10040 v0.9.0 compatibility with production release:

The s132_nrf52_2.0.0 SoftDevice is production tested for, and intended for use on, “Engineering C” and "Rev 1" nRF52832 chips.

(See the compatibility matrix in Nordic Semiconductor’s infocenter, infocenter.nordicsemi.com)

For development purposes, the SoftDevice may also be run on “Engineering B” nRF52832 chips. On this chip revision, Erratum 73 (TIMER: Event lost) applies. The workaround for this Erratum must be applied as described in the Errata document for "Engineering B". If the workaround is not applied, the SoftDevice may occasionally trigger a fault (assert) due to missing events from the hardware when running on this chip revision. This assert will then have to be handled by the application’s assert handler. (This Erratum also affects the application itself in the same way.)

See the eErata list for nRF52832 in the Nordic Infocenter, infocenter.nordicsemi.com .

As the issue depends upon a race condition, it’s occurrence may not be deterministic seen from the application. Expected rates of occurrence could be once or a few times in hours of SoftDevice use, but may also be higher or lower than this, depending upon the exact conditions and the use case.