unexpected SWI during softdevice startup

[Terry]

We are using a custom board with softdevice S132, sdk14, and freertos and ana nrf52832.

Our ble_app does:

1. init gpio put up a splash screen via a display on spi
2. initializes twi and does writes to it to turn on an led via a gpio expander
3. initializes the ble stack
4. starts the freertos scheduler
5. completes the boot and turns off the led
6. goes on to do the rest of the stuff

If we flash with the following sequence:

1) erase all
2) cycle power (and POR)
3) flash the softdevice
4) flash our ble_app

On the first a POR reset after flash, the app turns on the led and hangs. After about 3 POR's, the app completes the boot, turns off the LED, and operates exactly as expected. Once it is "healed", it continues to operate correctly from POR. If we make a change to ble_app and reflash just the ble_app, it works as expected on the first reset. If we start from "erase all" with the same updated ble_app we just flashed, we hang.

Debugging it through various incantations shows we hang on a configASSERT(xTasktoNotify) = for(;;); in vTaskNotifyGiveFromISR, following a SWI, that immediately follows the restoration of interrupts via a call to taskEXIT_CRITICAL() at the end of queue.c, that was the result of an xTimerStart.

Here is typical stack trace:

	Thread #1 57005 (Suspended : Signal : SIGTRAP:Trace/breakpoint trap)	
		vTaskNotifyGiveFromISR() at tasks.c:4,309 0x26532	
		SWI2_EGU2_IRQHandler() at nrf_sdh_freertos.c:65 0x28324	
		<signal handler called>() at 0xfffffff9	
		__sd_nvic_irq_enable() at nrf_nvic.h:287 0x28510	
		sd_nvic_critical_region_exit() at nrf_nvic.h:470 0x285ca	
		app_util_critical_region_exit() at app_util_platform.c:86 0x28604	
		SEGGER_RTT_Write() at SEGGER_RTT.c:862 0x2437a	
		SEGGER_RTT_vprintf() at SEGGER_RTT_printf.c:468 0x249ec	
		SEGGER_RTT_printf() at SEGGER_RTT_printf.c:511 0x24a1e	
		ble_init() at task_ble.c:127 0x23bb8	
		<...more frames...>	

The stack trace leading up to the signal handler call can vary, but we always crash after the SWI2 exception because the xTasktoNotify is null.

Again, after several power cycles, this goes away and everything behaves well.

Another symptom is that if we are debugging, once this hangs at the configASSERT, without a power cycle, we will hang at the SPI transaction for the display, and never even get to the BLE initialization. The display has a "device ready" signal that we poll for that never asserts ready, but we don't know if the display chip is confused about the SPI transaction itself (possibly hanging) or if that chip now needs its own power cycle for some reason (we do issues a "chip reset".

[Susheel Nuguru]

Hi

We found a bug that we fixed in SDK14.1

Please replace the function

/* This function gets events from the SoftDevice and processes them. */
static void softdevice_task(void * pvParameter)
{
    NRF_LOG_DEBUG("Enter softdevice_task.");

    if (m_task_hook != NULL)
    {
        m_task_hook(pvParameter);
    }

    while (true)
    {
        (void) ulTaskNotifyTake(pdTRUE,         /* Clear the notification value before exiting (equivalent to the binary semaphore). */
                                portMAX_DELAY); /* Block indefinitely (INCLUDE_vTaskSuspend has to be enabled).*/
        nrf_sdh_evts_poll();
    }
}

to

/* This function gets events from the SoftDevice and processes them. */
static void softdevice_task(void * pvParameter)
{
    NRF_LOG_DEBUG("Enter softdevice_task.");

    if (m_task_hook != NULL)
    {
        m_task_hook(pvParameter);
    }

    while (true)
    {
        nrf_sdh_evts_poll();

        (void) ulTaskNotifyTake(pdTRUE,         /* Clear the notification value before exiting (equivalent to the binary semaphore). */
                                portMAX_DELAY); /* Block indefinitely (INCLUDE_vTaskSuspend has to be enabled).*/
    }
}

There was a deadlock in the way we locked ourself in the ulTaskNotify. Now we will first poll for the events that already happened before the softdevice_task was created before suspending.

[Terry]

This change did not fix the problem. Still dies after SWI at tasks.c line 4309: xTaskToNotify is 0.

	Thread #1 57005 (Suspended : Signal : SIGTRAP:Trace/breakpoint trap)	
		vTaskNotifyGiveFromISR() at tasks.c:4,309 0x264de	
		SWI2_EGU2_IRQHandler() at nrf_sdh_freertos.c:65 0x282d0	
		<signal handler called>() at 0xfffffff9	
		memset() at 0x39d44	
		prvAllocateTCBAndStack() at tasks.c:3,136 0x2611e	
		xTaskGenericCreate() at tasks.c:562 0x2555e	
		nrf_sdh_freertos_init() at nrf_sdh_freertos.c:98 0x28352	
		ble_init() at task_ble.c:128 0x23b92	
		main() at main.c:63 0x39a0e

[Susheel Nuguru]

please help me reproduce this problem on a DK. I will debug this and give you a workaround if possible.

[Susheel Nuguru]

Hi Terry, did you solve this issue? if so, please update this thread.

[nevi]

Hi,

I also experienced this error on my custom board with nrf52832, sdk16.

The stack trace:

Thread [1] (Suspended: Breakpoint hit.)	
	11 app_error_handler() app_error_handler_gcc.c:49 0x0003ef46	
	10 assert_nrf_callback() b_le.c:226 0x0002add0	
	9 vTaskNotifyGiveFromISR() tasks.c:4796 0x00038642	
	8 SWI2_EGU2_IRQHandler() nrf_sdh_freertos.c:35 0x0005258c	
	7 <signal handler called>()  0xfffffff9	
	6 memset()  0x00052c7a	
	5 prvInitialiseNewTask() tasks.c:853 0x00036f3e	
	4 xTaskCreate() tasks.c:808 0x00036f02	
	3 nrf_sdh_freertos_init() nrf_sdh_freertos.c:68 0x00052640	
	2 bleInit() b_le.c:2793 0x0002e75c	
	1 main() main.c:210 0x00026606	

It is occured on the first power on reset, but not after software reset (NVIC_SystemReset()).

I also noticed that maybe the error doesn't appear after every compiling.

Did anyone figure out the cause of the error?