• State Verified Answer
  • Replies 1 reply
  • Subscribers 71 subscribers
  • Views 2131 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 112208
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF52 silicon and SoftDevice compatibility

puz_md

Hi,

we have developed some software that is running fine on the nRF52-DK (PCA10040 v0.9.0) which uses nRF52832 IC revision "Engineering B".

We are using SoftDevice s132_nrf52_2.0.0-4.alpha (which is a bit outdated, but we wanted to wait for a production ready release before putting effort into migration).

We are using nRF52 SDK v0.9.2 (here, we are also waiting for a production ready release of nRF5x SDK v11).

Our problem: When we try to run the software on our own PCB which uses the NRF52832 QFAABA 1545AG, we can't observe any radio activity (advertising). But we get debug output, so the system itself seems to be running. Our PCB does not contain the DCDC coils, but that doesn't seem to be the problem here (we removed the coils on the PCA10040 and the software still worked).

Will it be necessary to update the SoftDevice to run our software on the NRF52832 QFAABA 1545AG?

If we update to the latest SoftDevice v2.0.0 (production ready), will we be able to use the PCA10040 v0.9.0 with this SoftDevice? Or will we have to throw away the nRF52-DKs with Engineering B revision? This page suggests that SoftDevice v2.0.0 does not run on the Engineering B revision.

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

Parents
  • 0

    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.

Reply
  • 0

    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.

Children
No Data
Related
Terms of service