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

[PopradiArpad]

Hi,

I know that MtConnect05 is not a Nordic product but it contains a nRF52832

and these questions are about SDK for mesh usage.

The questions:

1. What does this assert log mean?

It happens at the first or second time I write '0' to RTT
in advertiser_packet_send (see pics for the backtrace).

The provisioning and configuring works.

2. It seems it's a kind of timing problem, but what could it be?

Thanks,

Árpád

P.S:

I put the code on Github if somebody would like to play with that.

I adapted the SDK for Mesh v1.0.1 by creating and using new board (mtconnect05.h, BOARD_MTCONNECT05)
using SERVER_COUNT 1 and simplifying the button handling in main.c.
mtconnect05.h reconfigures all buttons to the same free slot GPIO 14. BUTTONS_NUMBER is 1.

The code is at
github.com/.../light-switch-mtconnect05.git on branch mtconnect05-board.

I use Segger Embedded Studio with

• examples/light_switch/server/light_switch_server_nrf52832_xxAA_s132_3_1_0.emProject
• examples/light_switch/client/light_switch_client_nrf52832_xxAA_s132_3_1_0.emProject

project files.

The project files are assigned to dedicated JLink serial numbers.

Reproducing:
1. Fire up two Segger Embedded Studio one for the server, one for the client.
2. Adapt the JLink serial numbers to your ones. (In Project explorer > right click on the project > Edit options > JLink > Host connection)
3. In the Client IDE: Bring up the Breakpoint window and disable the HardFault breakpoint to let catch the hard fault.
4. Set breakpoint to nrf_mesh_sdk.c line 113 in softdevice_assert_handler
5. Start Client code
6. Start Server code

[tesc]

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...

[PopradiArpad]

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