Setting up APP_TIMER results in hardware fault

RE: Setting up APP_TIMER results in hardware fault

RK — Thu, 04 Jun 2015 07:49:01 GMT

This is just code which hasn't been properly updated for the change in APP_TIMER_INIT() between SDK7 and SDK8. The parameter to that used to be a bool, it was changed to a function pointer but not much of the example code has been updated and in most cases you don't notice because false == 0 and it doesn't make a difference.

Using GCC with a reasonable set of warnings turned on I get a warning if I try compiling something like that. I don't know if Keil is just not very good at warning about such things or the warnings are turned off by default. I always turn warning levels way up to catch all these things.

I agree all the example code, most of which is 'wrong' should be properly updated for SDK8.

RE: Setting up APP_TIMER results in hardware fault

Karel_TandD — Thu, 04 Jun 2015 07:23:18 GMT

I am just starting out, and decided the best approach for me would be to start from scratch as you might say. The first thing I noticed was in code, here and there, was the line:

  APP_TIMER_INIT(APP_TIMER_PRESCALER, APP_TIMER_MAX_TIMERS,     APP_TIMER_OP_QUEUE_SIZE, false);

and in one place (as in the question above) I found a true (==> HARD FAULT)

  APP_TIMER_INIT(APP_TIMER_PRESCALER, APP_TIMER_MAX_TIMERS,     APP_TIMER_OP_QUEUE_SIZE, true);

A true will lead to m_evt_schedule_func being set to 1 and thus the code at
...\components\libraries\timer\app_timer.c(355) will call a function at address 0x00000001

if (m_evt_schedule_func != NULL) 
{
    uint32_t err_code = m_evt_schedule_func(p_timer->p_timeout_handler, p_timer->p_context);
    ..DEATH..
}

On investigating the parameters, I discovered that for the use of true / false , one should be using

APP_TIMER_APPSH_INIT(APP_TIMER_PRESCALER, APP_TIMER_MAX_TIMERS, APP_TIMER_OP_QUEUE_SIZE, true);

Please, everyone, check in the header files app_timer.h and app_timer_appsh.h yourselves.

I am currently working with SDK8.0.0, so I don't know if these 'typos' have been corrected in the latest release, but if not I would strongly recommend that the false be changed to a NULL, to avoid headaches in the future.

RE: Setting up APP_TIMER results in hardware fault

perceptron — Mon, 09 Feb 2015 22:28:29 GMT

I see that the debugger goes in to data_timeout_handler once and thereafter it does not. And it also seems like the debugger does not get into data_event_handler.

RE: Setting up APP_TIMER results in hardware fault

perceptron — Mon, 09 Feb 2015 21:57:39 GMT

@Stefan Birnir Sverrisson thanks for your reply! Here is how the data_timeout_handler looks,

static void data_timeout_handler(void * p_context)
{
    UNUSED_PARAMETER(p_context);
    data_event_handler(readData(0));
}

static void data_event_handler(uint16_t data)
{
    uint32_t err_code;
    err_code = ble_lbs_on_data_available(&m_lbs, data);
    APP_ERROR_CHECK(err_code);
}

RE: Setting up APP_TIMER results in hardware fault

Stefan Birnir Sverrisson — Mon, 09 Feb 2015 12:34:03 GMT

Have you defined your data_timeout_handler function? If so, what does the data_timeout_handler do? If you set a breakpoint in the data_timeout_handler, does the debugger stop there?

Update 10.2.2015

In order for you to efficiently debug the application code in Keil, the setting should be however Optimization: “Level 0” and “Optimize for Time” should be unchecked

Also check this thread when debugging with a softdevice enabled.

What SDK are you using?

RE: Setting up APP_TIMER results in hardware fault

perceptron — Sat, 07 Feb 2015 19:45:42 GMT

@RK, any clue ?

RE: Setting up APP_TIMER results in hardware fault

perceptron — Sat, 07 Feb 2015 07:10:13 GMT

"m_ldc_timer_id" and "m_timer_id" are the same, I made a typo there. Both should have been m_ldc_timer_id. HEART_RATE_MEAS_INTERVAL is set to 32767 (for 1 second).

The device does not go into hard fault while initializing the timer. The device initializes and goes on to execute the main loop (verified through debugger)

// Enter main loop
    for (;;)
    {
        app_sched_execute();
        power_manage();
    }

On a BLE Scanner App I can see that it broadcasts and advertises in the beginning and then goes in to a hard fault.

If I comment the timer initialization code, it seems to work fine. When I say works fine, I can see the device advertising and it appears on the BLE Scanner App. What is the best way to debug this ? Thank you.

RE: Setting up APP_TIMER results in hardware fault

RK — Sat, 07 Feb 2015 06:26:32 GMT

What's err_code in the timers_start() function? If not zero then APP_ERROR_CHECK() is sending you into an error.

Why is your variable called m_ldc_timer_id in the initialization and m_timer_id in the timers_start function? What is HEART_RATE_MEAS_INTERVAL?