Softdevice assert: 4097:190958:256 by trying to adapt SDK for Mesh v1.0.1 light-switch demo to MtConnect05

RE: Softdevice assert: 4097:190958:256 by trying to adapt SDK for Mesh v1.0.1 light-switch demo to MtConnect05

PopradiArpad — Mon, 26 Feb 2018 14:45:12 GMT

Hi,

I answer my question.

With the help of an MtM Engineer here is the solution:

But first what is the problem?

The problem is that the low frequency accuracy of the MtConnect05 is other as of the chip built into the nRF52DK.

1. change mesh_core_setup

Add the bold code in nrf_mesh_sdk.c - mesh_core_setup

__LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Initializing softdevice\n");
#if SD_BLE_API_VERSION >= 5
nrf_clock_lf_cfg_t lfc_cfg = {NRF_CLOCK_LF_SRC_XTAL, 0, 0, NRF_CLOCK_LF_ACCURACY_20_PPM};
#elif SD_BLE_API_VERSION >= 3
nrf_clock_lf_cfg_t lfc_cfg = {NRF_CLOCK_LF_SRC_XTAL, 0, 0, NRF_CLOCK_LF_XTAL_ACCURACY_75_PPM};
#elif SD_BLE_API_VERSION >= 2
nrf_clock_lf_cfg_t lfc_cfg = {NRF_CLOCK_LF_SRC_XTAL, 0, 0, NRF_CLOCK_LF_XTAL_ACCURACY_20_PPM};
#elif defined(S110)
nrf_clock_lfclksrc_t lfc_cfg = NRF_CLOCK_LFCLKSRC_XTAL_20_PPM;
#endif

2. change main in the server project:

Add the bold code in main.c - main of the server

#if defined(S110)
    config_params.lf_clk_cfg = NRF_CLOCK_LFCLKSRC_XTAL_20_PPM;
#elif SD_BLE_API_VERSION >= 5
    config_params.lf_clk_cfg.source = NRF_CLOCK_LF_SRC_XTAL;
    config_params.lf_clk_cfg.accuracy = NRF_CLOCK_LF_ACCURACY_20_PPM;
#elif SD_BLE_API_VERSION >= 3
    config_params.lf_clk_cfg.source = NRF_CLOCK_LF_SRC_XTAL;
    config_params.lf_clk_cfg.xtal_accuracy = NRF_CLOCK_LF_XTAL_ACCURACY_75_PPM;
#else
    config_params.lf_clk_cfg.source = NRF_CLOCK_LF_SRC_XTAL;
    config_params.lf_clk_cfg.xtal_accuracy = NRF_CLOCK_LF_XTAL_ACCURACY_20_PPM;
#endif

    ERROR_CHECK(nrf_mesh_node_config(&config_params));

After this the MtConnect05s run like a dream :)

Best,

Árpád

RE: Softdevice assert: 4097:190958:256 by trying to adapt SDK for Mesh v1.0.1 light-switch demo to MtConnect05

tesc — Fri, 23 Feb 2018 15:05:14 GMT

Sorry, I did not realize it was all visible in the second screenshot.

ID of 4097 (0x1001) is NRF_FAULT_ID_APP_MEMACC, which means there is an access violation. The pc points to the place in the application which is at fault. In hexadecimal it is 0x2E9EE, and you should be able to find it in the disassembly which would then give you the file and line number.

See the Hardware peripherals section of the SoftDevice Specification for a list of what hardware peripherals are protected.

Unfortunately I do not know why mouse over and printout gives separate values. Actually the printout seems to be the correct one...

RE: Softdevice assert: 4097:190958:256 by trying to adapt SDK for Mesh v1.0.1 light-switch demo to MtConnect05

PopradiArpad — Wed, 21 Feb 2018 07:23:57 GMT

Hi tesc,

you are right the logged values are not the same as the ones detected by the debugger:

Here are the decimal values by mouse over:

id: 0

pc 190958

info: 2

Best,

Árpád

P.S What causes the difference?

RE: Softdevice assert: 4097:190958:256 by trying to adapt SDK for Mesh v1.0.1 light-switch demo to MtConnect05

PopradiArpad — Wed, 21 Feb 2018 06:29:43 GMT

Hi tesc,

it asserts with the same values reproducibly. You can read them from the second image I sent. (last line in the debug terminal).

Best,

Árpád

RE: Softdevice assert: 4097:190958:256 by trying to adapt SDK for Mesh v1.0.1 light-switch demo to MtConnect05

tesc — Mon, 19 Feb 2018 14:06:33 GMT

Hi,

What are the values for "id", "pc" and "info" passed to softdevice_assert_handler(), and does it consistently assert with the same values? (You can figure out the values by mouse over, or read from the "locals" debug window which you can enable from the "view" menu or by Ctrl+Alt+L.)

Regards,
Terje

RE: Softdevice assert: 4097:190958:256 by trying to adapt SDK for Mesh v1.0.1 light-switch demo to MtConnect05

PopradiArpad — Fri, 16 Feb 2018 09:13:19 GMT

Hi leonwj,

thank you for the info about Monitor Mode Debugging, I didn't know it.
I will use that but in this case that is not problem.

The issue even happens without any breakpoint set.

I set up the breakpoint only to get more information about what it causes.
Step 3 and 4 have only that purpose.
Without Step 3 the breakpoint set to the assert handler (Step 4) doesn't come.

So the breakpoint is set within the softdevice_assert_handler and comes
only when the software already crashed.

Best,

RE: Softdevice assert: 4097:190958:256 by trying to adapt SDK for Mesh v1.0.1 light-switch demo to MtConnect05

leonwj — Fri, 16 Feb 2018 01:01:18 GMT

hello PopradiArpad,

I believe that you are running into the general debugging issue with Bluetooth and halt mode debugging. Of the RF protocols, Bluetooth in particular, has extremely sensitive timing requirements which means that it is very difficult to single step debug through various sections of application code without affecting radio operations. The softdevice has most likely asserted due to this. Most people run to breakpoints whilst in halt mode debug to ensure that timing issues are minimized.

In order to entirely overcome the issue, you will have to enable monitor mode debugging (MMD) which is a feature of the Cortex-M3/M4 (and therefore will not be available if you are debugging an nrf51 chip). From the screenshots that you provided, it looks like you are using the nrf52832 so it's supported on that. The following link provides some basic details on MMD functionaility.

The Nordic Blog also has some practical guidance on setting up MMD with SES, see here...as well as here... (there are a couple of blog entries that are unavailable/404 since the migration to this new devzone branding so i haven't been able to link to those)

Finally, from your screenshots, you appear to be using ubuntu/linux as your development platform and there are licensing issues which you would need to be aware of (since the on-board nrf52x jlink MMD evaluation only covers Windows I believe). Please review the following link to determine your requirements on that front. (https://devzone.nordicsemi.com/f/nordic-q-a/27363/monitor-mode-debug-w-nrf52840-ses-3-3-sdk14-1-0-ble-s140/108073#108073)

Post back if you need any additional details on the MMD front or clarification of the above.

Regards,