Starting idle task using Task Manager library frequently throws error "Unknown function at 0x000008C8" when running with the debugger (often takes several restarts until it runs). I am using SDK14.2.0 and SES 3.34.
The failure occurs at line 263 in task_manager.c where a jump to the idle task is performed:
idle_task(p_idle_task_context);
In my project I am using CLI library with task manager and I also have timers running which post events to the scheduler that then calls a specific handler for the timer event. My idle loop looks like this:
void idle_task(void * p_context)
{
for (;;)
{
app_sched_execute();
NRF_LOG_PROCESS();
task_yield();
}
}
The timers that post to the scheduler do not seem to be the issue. If I don't start any of them I still see this issue quite often.
My main startup code looks like this:
int main(void)
{
ret_code_t err_code = NRF_SUCCESS;
// logging and cli init
err_code = NRF_LOG_INIT(systick_getTickCount);
APP_ERROR_CHECK(err_code);
nrf_drv_uart_config_t uart_config = NRF_DRV_UART_DEFAULT_CONFIG;
uart_config.pseltxd = 4;
uart_config.pselrxd = 30;
uart_config.hwfc = NRF_UART_HWFC_DISABLED;
err_code = nrf_cli_init(&m_cli_uart, &uart_config, true, true, NRF_LOG_SEVERITY_INFO);
APP_ERROR_CHECK(err_code);
// init clocks
err_code = nrf_drv_clock_init();
APP_ERROR_CHECK(err_code);
nrf_drv_clock_lfclk_request(NULL);
systick_init();
APP_SCHED_INIT(SCHEDULER_MAX_EVENT_SIZE, SCHEDULER_QUEUE_SIZE);
// App timer uses the scheduler (APP_TIMER_CONFIG_USE_SCHEDULER=1 in sdk_config.h)
err_code = app_timer_init();
APP_ERROR_CHECK(err_code);
APP_ERROR_CHECK(nrf_cli_task_create(&m_cli_uart));
// initialize BLE stack and services
ble_stack_init();
ble_peripheral_init();
// Start execution
NRF_LOG_INFO("===== Application Started =====");
task_manager_start(idle_task, NULL);
}
Any help would be greatly appreciated. I have an approaching deadline and have spent alot of time trying to see what could be going wrong. I don't "think" this issue occurs with Release build but I have not tried enough to be sure, but nonetheless this shouldn't happen when running the debugger.