crashing from _start without even entering into main() function

[swetha Paladugu]

Hi,

I am using nrf52832 custom board and sdk17.2.0.

My application is a Freertos application. I see that my application is going to hardfault from _start without entering into the main() function.

Attached sdk_config.h , FreeRTOSConfig.h and the screenshot of the hardfault for reference.

Can someone please help me to resolve the issue?

8358.FreeRTOSConfig.h6215.sdk_config.h

[Susheel Nuguru]

Seems like it is happening inside the NRF_LOGs. 

1. If the function call stack can be trusted, then try to disable the logs to see if the issue goes away.
   1. If it does, then the log buffer might not be enough and we can focus more on looking a bit deeper into this NRF_LOG configuration issue. 
   2. If it does not help, then most likely the stack is corrupt and I wont be trusting this function call stack much.
2. If this is a stack corruption then could happen because your thread might have caused a stack overflow. Try to increase the stack size significantly for this thread and see if that helps.

[swetha Paladugu]

yes after disabling NRF_LOG_ENABLED the issue went away.

[swetha Paladugu]

Need urgent support, please reply fast.

[Susheel Nuguru]

Hi Swetha, I could try to reply to you within 24 hours of your query, 

swetha Paladugu said:

yes after disabling NRF_LOG_ENABLED the issue went away

 It looks like the NRF_LOG is taking too much stack and what you are seeing is a possible stack overflow and hence a memory corruption.

Normally in our examples we let logger run in its own thread so that we can calibrate the stack size it needs explicitly. For example in our SDK\examples\ble_peripheral\ble_app_hrs_freertos\main.c you can see that we create a logger thread.

#if NRF_LOG_ENABLED
    // Start execution.
    if (pdPASS != xTaskCreate(logger_thread, "LOGGER", 256, NULL, 1, &m_logger_thread))
    {
        APP_ERROR_HANDLER(NRF_ERROR_NO_MEM);
    }

If you have already done it, then try increasing the stack size for both logger thread and "Thread #2" from the screenshot

[swetha Paladugu]

Yes i'm already doing it. 

the call stack doesn't clearly say which task it is running. 

and one more thing i have added the log message in the main function itself not in the task before starting scheduler.

NRF_LOG_INFO("Current RTC time : %u",get_current_time());

// nrf_sdh_freertos_init(advertising_start, NULL);

nrf_sdh_freertos_init(NULL, NULL);

// Activate deep sleep mode.
SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk;
// Start FreeRTOS scheduler.
vTaskStartScheduler();

[Susheel Nuguru]

If increasing the task stack sizes did not help, then I am not sure what is causing this hardfault. if the hardfault_c_handler is not able to give any meaningful address and cause for this hardfault, then it must be a memory corruption that happened that during somewhere in the backend of nrf_log. Try to step through the debugger and try to pin point the exact line where the hardfault is happening. When you understand the context of this hardfault, we might get more hints on how to fix it.