BLE advertising cannot be stop without hardware crash

[iznow]

Hye,

using the nrf 2.4.2 toolchain

i have an unsolvable problem about ble on a nrf52840 based project with imu, i2s strip led, buttons, spi speaker...

i have a classic ble enable process at startup after everthing else initialized (i try disabling all around too... same)

i get a systematic crash on advertising stop with bt_le_adv_stop();

i tried a lot of things about irq conflict or configs...

i tried to put in thread allowing to start and stop advertising few times but a crash anyway 

it just reboot with HARDWARE reset cause (12).

relevant config is for now:

CONFIG_MAIN_STACK_SIZE=8192

CONFIG_HEAP_MEM_POOL_SIZE=16384

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=8192

CONFIG_BT=y

CONFIG_BT_PERIPHERAL=y

CONFIG_BT_DEVICE_NAME="XXX"

CONFIG_BT_GATT_CLIENT=y

#CONFIG_BT_CTLR_ADVANCED_FEATURES=y

CONFIG_BT_EXT_ADV=y

CONFIG_ZERO_LATENCY_IRQS=y

CONFIG_BT_LL_SW_SPLIT=y

CONFIG_BT_CTLR_ULL_HIGH_PRIO=2

CONFIG_BT_MAX_CONN=1

CONFIG_ISR_STACK_SIZE=1024

CONFIG_BT_DIS=y

CONFIG_BT_DIS_FW_REV=y

CONFIG_BT_DIS_MODEL="xxxxxx"

CONFIG_BT_DIS_MANUF="xxxxxx"

CONFIG_BT_DIS_PNP=n

CONFIG_BT_SETTINGS=y

CONFIG_BT_GATT_CACHING=n

CONFIG_BT_DIS_SETTINGS=y

CONFIG_BT_THROUGHPUT=y

CONFIG_BT_GATT_DM=y

CONFIG_BT_USER_DATA_LEN_UPDATE=y

CONFIG_BT_USER_PHY_UPDATE=y

CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS=n

CONFIG_BT_BUF_ACL_RX_SIZE=502

CONFIG_BT_ATT_PREPARE_COUNT=2

CONFIG_BT_L2CAP_TX_MTU=498

also the project use FOTA:

CONFIG_MCUMGR=y

CONFIG_IMG_MANAGER=y

CONFIG_MCUMGR_GRP_IMG=y

CONFIG_MCUMGR_GRP_OS=y

CONFIG_MCUMGR_GRP_STAT=y

CONFIG_MCUMGR_GRP_OS_TASKSTAT=y

CONFIG_BOOTLOADER_MCUBOOT=y

CONFIG_MCUBOOT_GENERATE_CONFIRMED_IMAGE=y

CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y

CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU_SPEEDUP=y

CONFIG_DISABLE_FLASH_PATCH=y

thanks

 

[iznow]

After insvestigation, it appear that a call to a settings_save_one() function just after the ble stop break the execution without explicite exception and reset cause 0x12 HARDWARE_RESET.

After disabling watchdog, the same problem reset with cause 0x10 BROWN_OUT.

Finally i manage to avoid the crash by moving the settings_save_one() call before the ble stop...

but i still do not know what's exactly going on...

i did not found any irq conflict and tried a lot a configuration variation about it...

same behaviour with all others sensors disabled and uninitilaized... maybe dts.?

i didn't try on DK for now...

[Edvin]

Where do you see 0x12 and 0x10? 

And where do you call settings_save_one()? Is this something you added to your application, or is it something that is part of the default bt_le_adv_stop() API?

Best regards,

Edvin

[iznow]

i see the reset cause at the beginning of my app after reboot, using the reset cause api.

settings_save_one() call is in my app and was called after the bt_le_adv_stop(). but debugger stop in bt_le_adv_stop() ????

moving settings_save_one() call before the bt_le_adv_stop() solve the crash !!

[Edvin]

iznow said:

i see the reset cause at the beginning of my app after reboot, using the reset cause api.

Sorry, this may be obvious, but I have not seen it. Can you please specify what API that is?

iznow said:

moving settings_save_one() call before the bt_le_adv_stop() solve the crash !

unless you are done with this issue, of course. 

And if it is possible to reproduce in a DK, that would make it easier to understand what's going on.

Best regards,

Edvin

[iznow]

uint32_t reset_cause;
int err = hwinfo_get_reset_cause(&reset_cause);

CONFIG_HWINFO=y in prj.conf

Edvin said:

unless you are done with this issue, of course. 

i would prefer to understand...

will take a moment in DK... if some time to do it...

[Edvin]

Thank you!

Ok, so 0x10 is bit 5, and 0x12 is bit 2 and 5. The RESETREAS register, that is used for the hwinfo_get_reset_cause is retained, so it is not reset unless you do it in the application (or a power on reset). 

Bit 2 = RESET_BROWNOUT
Bit 5 = RESET_DEBUG

From what I can tell, there is nothing in z_impl_hwinfo_get_reset_cause() from the file ncs\zephyr\drivers\hwinfo\hwinfo_nrf.c that can trigger bit 2 (Reset brownout), which makes sense, because there is no bit in the RESETREAS register that will indicate a brownout. 

Bit 5 (RESET_DEBUG) means:

"Reset due to wake up from System OFF mode when wakeup is triggered from entering into debug interface mode"

In case of a power on reset or a brownout reset, the register should be 0x00000000, giving a reset reason = 0. But since it is cumulative, it means that all reset reasons since the last power on/brownout are added to the list. 

But I am still not sure how you are able to get bit 2 set in the reset reason number. It should not be possible with an nRF, as there is no check in the hwinfo_get_reset_cause() that sets bit 2. 

Best regards,

Edvin