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).

[rwl]

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.

[Sigurd]

Hi,

You could get the «Unknown function at 0x000008C8” when you try to step through the code after the SoftDevice have been enabled. When stepping through the code, or when setting breakpoints, the CPU will be halted. This will cause a hard-fault due to BLE timing being violated. This will result in a disconnected BLE link and the code will end up in the error-handler.  Alternative debugging approaches with the SoftDevice enabled includes using RTT or UART for debug messages and/or toggling GPIOs to indicate software states.

Also note that the systick is sourced by the same clock as the CPU, which is turned off when going to WFE/WFI (sd_app_evt_wait()). It is therefore not recommended to use systick. I would recommend using the RTCx peripheral (via app_timer for instance), or the TIMER peripheral instead.

 

[rwl]

Yes I understand about debugging while the soft device is enabled.  Do you see any issue with using both the Task Manager with the app_scheduler?  I'm using the app_scheduler to handle my timer events asynchronously. I found that I had to use the Task Manager to make the CLI work in conjunction with my app.  Without the Task Manager, things would fail miserably if I simply called nrf_cli_process() in my idle loops ( I also have a lot of log messages going out the UART).

As a side note, I am not calling sd_app_evt_wait() in my app, it is always fully running. I do recognize that systick clock stops when the processor sleeps.

[Jakub Rzeszutko]

Hi rluc,

I think that problem you are facing with is related to your debugger. Please take a closer look to function: task_manager_start in the task_manager.c file. It is significantly messing up stack and I guess it confuses your debugger.

Please start debugging after calling the function task_manager_start to see if you are still observing the isse.

[rwl]

Thank you Jakub, I suspected that.  I will try what you suggested.

[bale11]

I'm facing the same issue. Just a little different in my case. I'm using freertos so first it gets stuck at "0x000008C8" and when I resume it again , it points to "prvIdleTask();" which is an idle hook task in freertos. 

Are you able to fix this problem ? I tried using the serial monitor for debugging but the nrf52832 stops responding after an hour. 

I'm using sdk 15