Thingy 52 twi_manager current_int_priority_get quandary.

[Jared]

On the included Thing52 example, the LED fires m_ioext_osc_status_change from an interrupt. Eventually, when it comes to requesting use of the TWI this comparison happens in twi_manager.c:

uint8_t current_context = current_int_priority_get();

if (current_context < s_context_limit){
...

Where s_context_limit is = APP_IRQ_PRIORITY_HIGHEST

It seems like as the current example code stands, even when executing in a timer context, current_int_priority_get() returns 15. When running SDK14 it returns a 7 (as expected as far as I can tell) causes this to return false and thus asserts.

I'm obviously missing the magic piece here or maybe there were some changes in the SDK to make current_int_priority_get() return a different value despite being exactly the same between SDK13 and SDK14.

Any help here would be greatly appreciated!

[jublin]

s_context_limit may not be what you expect. Look at what is calling twi_manager_init.

In the thingy app: 

err_code = twi_manager_init(APP_IRQ_PRIORITY_THREAD);

uint32_t twi_manager_init(app_irq_priority_t context_limit)
{
    s_context_limit = context_limit;
    s_collisions    = 0;

    return NRF_SUCCESS;
}

 

So APP_IRQ_PRIORITY_HIGHEST means nothing.

Prio_thread would be either 4 or 15, from the app_util_platform.h

I just spent two hours tracking this crap down for a project of my own that suddenly stopped working.