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
  • @jldewitt: Nice find, I didn't even think of that!

    And... I found the problem. It's my fault, of course. Sorry, Audun and Nordic folks.

    We build our firmware on a Unix system (OS X with gcc), but I noticed that our firmware worked fine if I flashed our device from Windows instead of our Unix build system. As in: the exact same binary that was built on OS X with gcc, but flashed with nRFgo Studio on Windows, worked fine. So that led me to believe that the build process, including the linker memory map, was all OK.

    To program our device on OS X, we convert the S110 .hex file to 2 .bin files to flash them with the command-line J-Link tools on OS X: a softdevice_main.bin file containing the ~80k of the S110, and a softdevice_uicr.bin file containing the 20 bytes that need to be written to the UICR region (at 0x10001000). I was using a custom UICR file derived from the S110 v5 firmware (with a different entry point for _start) instead of the softdevice_uicr.bin produced from the S110 v6 firmware. One byte had changed in the UICR region between v5 and v6. As soon I corrected that, ta-da, it now works.

    Thanks for all the support, and apologies for chasing my own tail.

Reply
  • @jldewitt: Nice find, I didn't even think of that!

    And... I found the problem. It's my fault, of course. Sorry, Audun and Nordic folks.

    We build our firmware on a Unix system (OS X with gcc), but I noticed that our firmware worked fine if I flashed our device from Windows instead of our Unix build system. As in: the exact same binary that was built on OS X with gcc, but flashed with nRFgo Studio on Windows, worked fine. So that led me to believe that the build process, including the linker memory map, was all OK.

    To program our device on OS X, we convert the S110 .hex file to 2 .bin files to flash them with the command-line J-Link tools on OS X: a softdevice_main.bin file containing the ~80k of the S110, and a softdevice_uicr.bin file containing the 20 bytes that need to be written to the UICR region (at 0x10001000). I was using a custom UICR file derived from the S110 v5 firmware (with a different entry point for _start) instead of the softdevice_uicr.bin produced from the S110 v6 firmware. One byte had changed in the UICR region between v5 and v6. As soon I corrected that, ta-da, it now works.

    Thanks for all the support, and apologies for chasing my own tail.

Children
Related