RBC mesh timer 0 usage

RE: RBC mesh timer 0 usage

Oleh — Wed, 18 Mar 2015 14:03:27 GMT

that's interesting, thanks trond-snekvik!

RE: RBC mesh timer 0 usage

victor — Mon, 16 Mar 2015 11:26:32 GMT

I am not using the default GAP stuff, I am storing the data in a vector instead to avoid haveing a lot of characteristics. So I can use 255 hadle value pairs.

RE: RBC mesh timer 0 usage

Oleh — Mon, 16 Mar 2015 10:21:41 GMT

I see you are using handle_count at 255, the max value is 155. "The maximum number of handle-value pairs available to the application. May not be higher than 155 due to BLE namespace requirements" (from: rbc_mesh/rbc_mesh.h)

could you test it with lower count?

RE: RBC mesh timer 0 usage

Asbjørn — Thu, 26 Feb 2015 13:26:44 GMT

You can't use Timer0 outside the time slot. This timer is used by the softdevice and will hardfault if accessed outside the timeslot. I would recommend you to have a look at the shared resources table in the S110 softdevice specification. As you suggest yourself, try using a timer that's not controlled by the softdevice and you should at least not have the timer issue.

RE: RBC mesh timer 0 usage

victor — Thu, 26 Feb 2015 08:10:46 GMT

Thanks for you response I tried your solution but the problem remains. Stack trace:

Thread [1] (Suspended: Signal 'SIGTRAP' received. Description: Trace/breakpoint trap.) 13 error_loop() main.c:69 0x000161f4 12 HardFault_Handler() main.c:113 0x00016284 11 () 0xfffffff1 10 get_available_timer() timer_control.c:80 0x0001bb3a 9 timer_get_timestamp() timer_control.c:237 0x0001c0b2 8 timeslot_get_remaining_time() timeslot_handler.c:578 0x0001c9ce 7 trickle_step_callback() transport_control.c:191 0x0001cbd2 6 async_event_execute() timeslot_handler.c:229 0x0001c49e 5 SWI0_IRQHandler() timeslot_handler.c:323 0x0001c5c8 4 () 0xfffffff9 3 0x0001193e 2 0x0000116a 1 0x0000116a

The line that failed:

        NRF_PPI->CHENCLR = (1 << (TIMER_PPI_CH_START + i));

NRF_MPU->PERR0=0xc300f903 so even if I change to sdoftdevice compatible ppi calls the line 2 lines down will fail: TIMER0->EVENTS_COMPARE[i] = 0;

Can I change timer 0 to some other timer, will this help?

I think that with your solution the program craches sooner.

I will attach my rbc mesh code: rbc_mesh.zip

I start the rbc mesh with the following code: rbc_mesh_init_params_t init_params;

init_params.access_addr = 0xA541A68F;
init_params.adv_int_ms = 100;
init_params.channel = 38;
init_params.handle_count = 255;
init_params.packet_format = RBC_MESH_PACKET_FORMAT_ADV_COMPATIBLE;
init_params.radio_mode = RBC_MESH_RADIO_MODE_BLE_1MBIT;

error_code = rbc_mesh_init(init_params);
APP_ERROR_CHECK(error_code);

Note that I have changed the RBC mesh to suite my needs as I want 255 handles and dont want each handle to be a characteristic.

RE: RBC mesh timer 0 usage

Trond Einar Snekvik — Wed, 11 Feb 2015 16:42:47 GMT

Hi,

This is caused by the function being called outside of the RBC mesh timeslot granted by the Softdevice Timeslot API, and is probably the result of a race condition in the framework.

I am unable to reproduce the crash on my setup, are you able to produce a stack trace of the crash?

Assuming it happens in the SWI0_IRQHandler() context, this can (assumably) be fixed by avoiding calling the end_timer_handler() callback while an async_evt is being processed in SWI0. This could be solved by three minor changes in timeslot_handler.c:

Change both calls to

timer_order_cb_sync_exec(g_timeslot_length - TIMESLOT_END_SAFETY_MARGIN_US, end_timer_handler);

in timeslot_handler.c to

timer_order_cb(g_timeslot_length - TIMESLOT_END_SAFETY_MARGIN_US, end_timer_handler);

(notice the removed sync_exec from the function name). This will put the end_timer_handler in the async_evt queue, instead of interrupting any ongoing async events.

Delete the function end_timer_handler(void) at timeslot_handler.c, L290, and insert this alternative version instead:

timeslot_handler.c, L290:

 static bool g_end_timer_triggered = false;
 /**
 * @brief Timeslot end guard timer callback. Attempts to extend the timeslot. 
 */
 static void end_timer_handler(void)
 {
    g_end_timer_triggered = true;

    /* Fake a radio IRQ, making the SD call radio_signal_callback(), letting us end timeslot */
    NVIC_SetPendingIRQ(RADIO_IRQn);
 }`

Finally, put the following 10 lines right after the large switch-case in radio_signal_callback():

if (g_end_timer_triggered)
{
    uint32_t length_us = ((g_timeslot_length > 100000)? 100000 : g_timeslot_length);
    radio_request_earliest.params.earliest.length_us = length_us;
    g_ret_param.callback_action = NRF_RADIO_SIGNAL_CALLBACK_ACTION_REQUEST_AND_END;
    g_ret_param.params.request.p_next = &radio_request_earliest;
    
    g_next_timeslot_length = length_us;
    
    g_end_timer_triggered = false;
}

This is a dirty hotfix, and lacks some proper verification before it should be considered completely safe, but it does not introduce any immediate new errors on my setup. Does this solve your issue (preferrably without introducing new ones)?

If you could post this issue to the project's issue tracker on GitHub, I'll see if I can provide a cleaner fix in the next patch, as it appears to be a bug in the framework.