This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF_CLOCK_LFCLKSRC_SYNTH_250_PPM/sd_softdevice_enable() changed from S110 v5 to v6?

Hi Nordic folks,

I’m stumped by an an error in sd_softdevice_enable() that outputs this from my error handler:

[ERROR] app_error_handler (src\core_functions.c:183) error_code=3735928559

All my main() function does is set up the UART so I can get serial output, and then immediately performs a single call to SOFTDEVICE_HANDLER_INIT, like this:

SOFTDEVICE_HANDLER_INIT(NRF_CLOCK_LFCLKSRC_SYNTH_250_PPM, false);

That SOFTDEVICE_HANDLER_INIT() macro calls the softdevice_handler_init() function, which then calls sd_softdevice_enable(), which is then triggering app_error_handler() with an error code that I’ve never seen before. (If it helps, the error code above, 3735928559, is -559038737 if treated as a signed 32-bit integer.)

The above call to SOFTDEVICE_HANDLER_INIT() seemed to work fine with S110 v5 with BLE_STACK_HANDLER_INIT(), but since upgrading to S110 v6.0.0, it now fails, triggering my app error handler with the message above. I do not have a src\core_functions.c file, which leads me to believe that the S110 binary is triggering an assert somewhere internally where I don’t have visibility.

I’ve tried every variant of using the RC clock by using the NRF_CLOCK_LFCLKSRC_RC_250_PPM_{250,500,1000,2000,4000,8000}MS_CALIBRATION enum, and the exact same error message appears. We do not have an external 32.768KHz clock in our product, so using NRF_CLOCK_LFCLKSRC_XTAL_500_PPM and its variants expectedly halts everything.

I don’t suppose someone here has a clue about what’s going on?

One concern of note is that the S110 v6.0.0 release notes mention that: “Synthesized low frequency clock source is not tested or intended for use with BLE stack.”, but that’s also mentioned for every S110 release before v6.0.0.

I've searched the devzone forums for other similar issues and keywords and haven't found anything that resembles this problem. Any advice would be greatly appreciated. Thanks!

Parents
  • Hi Andre,

    when upgrading from S110 v5 to v6, did you also make sure to update the API header files?

    For a major revision update, such as v5 to v6, there typically are API-breaking changes that requires some change to the application. If you've only replaced the SoftDevice without using the new .h files there could be unexpected error codes or other mysterious behavior.

    We recommend using SDK 5.2.0 (currently the latest version) together with S110 v6.0.0. If your application is using components from SDK 4.x.x they should be replaced with the updated versions as well.

    And as you mention, it's not recommended to use the synthesized low frequency clock. If you don't incude an external 32 kHz crystal, use NRF_CLOCK_LFCLKSRC_RC_250_PPM_x as clock source.

    Audun

Reply
  • Hi Andre,

    when upgrading from S110 v5 to v6, did you also make sure to update the API header files?

    For a major revision update, such as v5 to v6, there typically are API-breaking changes that requires some change to the application. If you've only replaced the SoftDevice without using the new .h files there could be unexpected error codes or other mysterious behavior.

    We recommend using SDK 5.2.0 (currently the latest version) together with S110 v6.0.0. If your application is using components from SDK 4.x.x they should be replaced with the updated versions as well.

    And as you mention, it's not recommended to use the synthesized low frequency clock. If you don't incude an external 32 kHz crystal, use NRF_CLOCK_LFCLKSRC_RC_250_PPM_x as clock source.

    Audun

Children
  • Hi Audun! Thank you for the reply.

    We did also update the header files when we upgraded from S110 v5 to v6, and are currently using v5.2.39364 of the nRF SDK, so all versions should be matched. I will go triple-check this, just to be sure, but I'm quite positive they're correct,

    As mentioned in the above post, I have also tried using NRF_CLOCK_LFCLKSRC_RC_250_PPM_250MS_CALIBRATION and the other RC enums, and all of them result in the same error code.

    In the meantime, are there any other ideas? I don't suppose a Nordic engineer would be kind enough to look at src\core_functions.c line 183 to see what assert I'm triggering?

    Thank you!

Related