app_timer_irq_priority interfering with UARTE0 & UARTE1

[sheddanl]

I am currently making a program that will interpret serial commands from UARTE1 and then send + read something from the other (UARTE0). Previously, when I have been using a single UARTE I have had no problem setting up an app_timer and waiting for it to expire while waiting for a full "message" from the UARTE (indicated by a newline).

static ret_code_t myTimerTimeoutSetup(uint32_t timeout_ms, my_timer_timeout_t* p_tout_ctx)
{
    uint32_t ticks = APP_TIMER_TICKS(timeout_ms);

    if (ticks < APP_TIMER_MIN_TIMEOUT_TICKS)
    {
        p_tout_ctx->expired = true;
        return NRF_SUCCESS;
    }

    ret_code_t ret = app_timer_create(&my_timer_id,
        APP_TIMER_MODE_SINGLE_SHOT,
        fc_adafruitFonaTimeoutHandler);

    APP_ERROR_CHECK(ret);

    // If the timer is failed to be created, return the error code
    if (ret != NRF_SUCCESS)
    {
        return ret;
    }

    return app_timer_start(my_timer_id, ticks, p_tout_ctx);
}

much like is done in nrf_serial, I then have a statement such as: if (tout_ctx.expired) break; in my while loop to break when time is up.

Now that I am using both UARTEs, both of them freeze (when they should transmitting data) until the timer has expired, on which they will finish transmitting (nrf_serial_write). I have also had trouble with the timer never expiring if the interrupt priority is set to the default 6.

Is this an IRQ priority issue?

Thanks very much

[Edvin]

NB: We are really short staffed due to Summer Holidays in Norway. You must expect some extra delay in technical questions these days, I am afraid. I am sorry for the inconvenience.

I will try to get back to this tomorrow. 

Note: It does sound like an IRQ issue. Something is blocked, waiting for the chance to run. If they are waiting for eachother, that may be the issue. 

1: Have you checked the SDK16\examples\peripheral\serial_uartes example?

2: Have you tried to use non-blocking calls with an event handler?

[sheddanl]

Update 1:

It appears to not be anything to do with the timer itself, but my use of while loops in the function.

sheddanl said:

I have also had trouble with the timer never expiring if the interrupt priority is set to the default 6.

This may also explain the strange behaviour I described above (using while (!tout_ctx.expired) as a delay)

Changing my serialFunction to only contain a while loop after the nrf_serial_write statements produces the same issue. Again, this has not been an issue when I have been using only 1 UART module.

serial_status_t serialFunction(nrf_serial_t serial, char* send_message, char* buffer, uint32_t timeout_ms, uint32_t serial_timeout_ms)
{
    (void)nrf_serial_write(&serial, send_message, strlen(send_message), NULL, serial_timeout_ms); // IS NOT PRINTED UNTIL TIMER EXPIRES, EXCEPT FOT THE FIRST CHARACTER
    (void)nrf_serial_write(&serial, "\r\n", strlen("\r\n"), NULL, serial_timeout_ms);
    (void)nrf_serial_flush(&serial, serial_timeout_ms);
    
    while(1)
    {
    // empty loop to demonstrate serial not finishing transmitting data
    }
}

Setting the UARTE priority to 2 makes no difference.

[Edvin]

Where do you call serialFunction() from? An interrupt?

[sheddanl]

Hi Edvin. I've only just got in. I realised yesterday this was the issue after taking a step back from the bug.

Thank you for your time :)