Key sdk_config.h items for FreeRTOS RTC operation

[RobMeades]

I need FreeRTOS operation in my build. I've adopted the FreeRTOS.h file from the blinky_freertos example, unchanged aside from a larger heap size and setting INCLUDE_xSemaphoreGetMutexHolder to 1 'cos I need that.  I have verified that the example build works as intended on my NRF52840-DK board; FreeRTOS running with tickless idle from RTC, LEDs flashing as intended.

The problem I have is that my build hangs after a few hundred milliseconds. If I change FreeRTOS.h so that it uses SysTick instead of RTC then no such problem occurs.  Disabling configUSE_TICKLESS_IDLE doesn't make things better.  If I run under the debugger and pause it once things have hung it shows that the code has entered the idle task then, for some reason, the SPIM2_SPIS2_SPI2_IRQHandler(), which is not something I've enabled or am using so I guess is an artefact of the debugger, and then done nothing afterwards.

I call nrf_drv_clock_init() in main(), just as the blinky_freertos example does, so the likelihood is that a setting in my sdk_config.h file is somehow different-in-a-bad-way from that of the blinky_freertos example.  My sdk_config.h, originally derived from a different example, has 1155 #defines in it, in a different order to that of the blinky_freertos example, so it is quite difficult to find the needle in the haystack.

Hence my QUESTION is: what are the key things one needs to configure in sdk_config.h to achieve stable FreeRTOS operation with RTC as time base?

In case it's useful, find below a complete ZIP file containing a standalone build which reproduces my problem.

test.zip

Rob

[Susheel Nuguru]

I would first like to understand why SPIM2_SPIS2_SPI2_IRQHandler interrupt is being triggered if the application has not enabled it, This is an application specific interrupt and neither softdevice nor freeRTOS should enable this.

[Susheel Nuguru]

Please start your code in the debugger and sniff the NVIC registers to find out at what point the SPIM2 NVIC interrupt bit is set, to know the context of your code that enabled the SPIM2 interrupt

[RobMeades]

OK, I've tried again this morning and this time it ends up in TIMER1 IRQ instead of SPIM2 IRQ; the blinky FreeRTOS example doesn't have any sdk_config.h entries at all for any TIMERs and I only use TIMER0, not TIMER1.  Below is a screen capture of the NVIC register status when it is in this state and the entirety of my code involved in this:

 

// The task within which testing runs.
void testTask(void *pParam)
{
    (void) pParam;

    NRF_LOG_RAW_INFO("\n\nCELLULAR_TEST: Test task started.\n");

    vTaskDelay(1000); // <- IT NEVER RETURNS FROM THIS CALL

    UNITY_BEGIN();

    NRF_LOG_RAW_INFO("CELLULAR_TEST: Tests available:\n\n");
    cellularPortUnityPrintAll("CELLULAR_TEST: ");
    NRF_LOG_RAW_INFO("CELLULAR_TEST: Running all tests.\n");
    cellularPortUnityRunAll("CELLULAR_TEST: ");

    UNITY_END();

    NRF_LOG_RAW_INFO("\n\nCELLULAR_TEST: Test task ended.\n");
    NRF_LOG_FLUSH();

    while(1){}
}

// Entry point
int main(void)
{
    TaskHandle_t taskHandle = NULL;

    NRF_LOG_INIT(NULL);
    NRF_LOG_DEFAULT_BACKENDS_INIT();

#if configTICK_SOURCE == FREERTOS_USE_RTC
    // If the clock has not already been started, start it
    nrf_drv_clock_init();
#endif

   // Create the test task and have it running
   // at a low priority
    assert(xTaskCreate(testTask, "TestTask",
                       CELLULAR_PORT_TEST_RUNNER_TASK_STACK_SIZE_BYTES / 4,
                       NULL, 14 /* Priority */,
                       &taskHandle) == pdPASS);

    // Activate deep sleep mode.
    SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk;

    // Start the scheduler.
    vTaskStartScheduler();

    // Should never get here
    assert(false);

    return 0;
}

[RobMeades]

A bit more detail: the previous step in the call trace would suggest that we're just at the point that interrupts have been re-enabled by FreeRTOS:

[Susheel Nuguru]

OK, it does not look like you are using BLE, Is this correct? Is it possible that you attach your code here and I can try to replicate the issue? I can make this case private if you do not want to make your code publicly visible.

[RobMeades]

No problem, original text of this ticket edited to include a standalone .zip file containing a build which reproduces my problem.  And no, I'm not using BLE.