NRF52 Restarts from Main() Instantly on Connect when using CCC Characteristic Notification (Intermittent)

[veletron]

Hi

I have followed this example: https://github.com/bjornspockeli/custom_ble_service_example through to the end, but am now having issues with some intermittent behaviour. Sometimes when I try and connect to the device using nRF Connect (Android), it fails to connect, and my code ends up back at the breakpoint start of main().

To get it working again, powercycle, clear, reprogram soft device and re download firmware sometimes works, sometimes not. The code is the same.

The watchdog is disabled via SDKConfig, soft device is SD132, V6.0 SDK V15.0. Compiler Keil V5

Unfortunately, I am stuck, unless I can get notifications to work each and every time, no matter the state of the board prior to my clearing it and programming it then my project wont happen.

To get this back into working order, I strip out the notification code, run it up (works) put ALL that code back, run it up again (works). To break it, I run any other example from the SDK, then clear the memory, reprogram my SD, re-download my unchanged application - and it fails to work. MY CODE HAS NOT CHANGED - same HEX file being downloaded.

My thought was that it there was not enough memory for the soft device, unfortunately, I have found decent no info to assist in determining the correct settings for IROM1 and IRAM1, I have:

IROM1: 0x26000, length 0x5A000

IRAM1: 0x20002260, length 0xDDA0

To erase the device, I use nrfjprog --family nRF52 --eraseall

To program the soft device, I use nrfjprog --program s132_nrf52_6.0.0_softdevice.hex

Any idea's?

Nigel

[veletron]

This appears to be related to the commented out code from the example which goes off on the connect event.

static void on_connect(ble_cus_t * p_cus, ble_evt_t const * p_ble_evt)

{

    p_cus->conn_handle = p_ble_evt->evt.gap_evt.conn_handle;

    /*ble_cus_evt_t evt;

    evt.evt_type = BLE_CUS_EVT_CONNECTED;

    p_cus->evt_handler(p_cus, &evt);*/

}

God knows why it sometimes works and sometimes doesn't, but removing it fixes the example.

[AndreasF]

Hi.

I'm not sure what could be wrong, as I don't have access to your code. I've therefore attached my project when I did this example.

Perhaps you could compare what I've done to what you have done?

Download here: custom_ble_service.zip

 - Andreas

[veletron]

Hi

Thanks for that. I think some it it was down to the way I had ordered the calls vs yourself, but my main issue was my removal of the code for case: BLE_CUS_EVT_NOTIFICATION_ENABLED without removing the APP_ERROR_CHECK!!

No default value was set for the variable err_code , it usually ended up with a zero and hence it worked (NRF_SUCCESS = 0), but if it had another value from a previous use of the memory then it failed - hence my random connect fail issue. So like I said - my code did not change, but due to my failing to specify an initial value for err_code, the underlying value for that variable did change.

I shall get into the habit of initialising err_code with NRF_SUCCESS like the code in bsp.c / etc does.

Thanks again

Nigel