UART TX in particular seems to have a race condition with scheduler running

RE: UART TX in particular seems to have a race condition with scheduler running

ovrebekk — Fri, 04 Feb 2022 09:04:37 GMT

My point about the setNrfEvent() function was more on the naming. Events are a specific type of register, and if you are also using this function to access task registers it might have been better to name it setNrfRegister() or something like that.

Looking at the definition it seems generic enough to access any register.

[quote user="morpho"]

After further debugging, it seemed to me the following was causing an issue. I was creating a local copy of Uart instance inside the class instead of a reference.

Though I'm not sure as to how was Uart instance created when it doesn't match the constructor

[/quote]

That might explain the issue, at least it is something you should fix before doing further testing.

Possibly the compiler is implementing a default void constructor?

Best regards
Torbjørn

RE: UART TX in particular seems to have a race condition with scheduler running

morpho — Wed, 02 Feb 2022 23:55:11 GMT

[quote userid="2116" url="~/f/nordic-q-a/81718/uart-tx-in-particular-seems-to-have-a-race-condition-with-scheduler-running/350403#350403"]

Is StartTx() used in blocking or non blocking mode in Uart::PrintUart() ?

[/quote]

StartTx() does non blocking transfer via interrupts in Uart::PrintUart().

[quote userid="2116" url="~/f/nordic-q-a/81718/uart-tx-in-particular-seems-to-have-a-race-condition-with-scheduler-running/350403#350403"]I assume the function declaration in the header file has a default value, since you don't specify this parameter?[/quote]

That's right.

[quote userid="2116" url="~/f/nordic-q-a/81718/uart-tx-in-particular-seems-to-have-a-race-condition-with-scheduler-running/350403#350403"]

How have you implemented the setNrfEvent() function?

[/quote]

 void setNrfEvent(T reg, uint32_t value)
    {
        *((volatile uint32_t *)((uint8_t *)pUARTx + (uint32_t)reg)) = value;
        //volatile uint32_t dummy = *((volatile uint32_t *)((uint8_t *)reg + (uint32_t)reg));
        volatile uint32_t dummy = *( (volatile uint32_t *) ((uint8_t *)pUARTx + (uint32_t)reg) );
        (void)dummy;
    }

[quote userid="2116" url="~/f/nordic-q-a/81718/uart-tx-in-particular-seems-to-have-a-race-condition-with-scheduler-running/350403#350403"]

Is it intentional that you are using this to access both events and tasks?

[/quote]

are you saying why am I not using existing nRF UART driver and use my own functions? If so, it's just to be confident in understanding the driver part.

I really gotta add that it's uber hard to debug on nRF particularly cause as you step into each calls, at some point, it ends up at an Unknown function

After further debugging, it seemed to me the following was causing an issue. I was creating a local copy of Uart instance inside the class instead of a reference.

Though I'm not sure as to how was Uart instance created when it doesn't match the constructor

class NotificationManager : public Observer
{
    Subject *subscriptions[maxSubscriptions] = {nullptr};	// store references to Subject
    uint8_t subscriptionIdx = 0;
    Uart _uart;     // *** ISSUE *** a local copy
    BleCustomService &_bleCustSrv;
    Fifo<Notification> _notifications;

    public:
    
    // constructor
    template<typename ...Args>
    NotificationManager(BleCustomService &bleCustSrv, Uart &uart, Args ...args) : _bleCustSrv(bleCustSrv), _uart(uart), _notification{0}
    {
        ((subscriptions[subscriptionIdx] = args), ...);
        subscriptions[subscriptionIdx++]->attach(this);
    }

RE: UART TX in particular seems to have a race condition with scheduler running

ovrebekk — Mon, 31 Jan 2022 11:51:27 GMT

Is StartTx() used in blocking or non blocking mode in Uart::PrintUart() ?

I assume the function declaration in the header file has a default value, since you don't specify this parameter?

How have you implemented the setNrfEvent() function?

Is it intentional that you are using this to access both events and tasks?

Have you been able to figure out how many times the irqHandler is called as a result of a single UART transaction?

(say you try to send 4 bytes, how often will the interrupt happen?)

Best regards
Torbjørn

RE: UART TX in particular seems to have a race condition with scheduler running

morpho — Fri, 28 Jan 2022 20:22:02 GMT

devzone.nordicsemi.com/.../NotificationManager.cpp

devzone.nordicsemi.com/.../uart.cpp

it's the following lines in NotificationManager.cpp that's printing to UART being delayed

snprintf(_notification.msg, 50, "t=%uC", tmpValue);
_uart.PrintUart(_notification.msg);

here you go. thanks

RE: UART TX in particular seems to have a race condition with scheduler running

ovrebekk — Fri, 28 Jan 2022 14:59:38 GMT

I did, thank you 🙂

The whole project might not be necessary, but at least the source code for the implementation of the driver, and any files that use the driver.

Best regard
Torbjørn

RE: UART TX in particular seems to have a race condition with scheduler running

morpho — Fri, 28 Jan 2022 04:44:30 GMT

Hi. No worries. I hope you had a great time off.

My code hasn't really changed since the last time. Do you want me to attach the whole project?

RE: UART TX in particular seems to have a race condition with scheduler running

ovrebekk — Tue, 25 Jan 2022 13:01:48 GMT

Sorry for the slow response, I have been out in holiday for a while.

Are you still having issues with this?

If so, can you please share the current state of your code so I can have a look at it?

Best regards
Torbjørn

RE: UART TX in particular seems to have a race condition with scheduler running

morpho — Tue, 04 Jan 2022 04:27:07 GMT

UART interrupt is firing fine and so does the TxByte(). It's not that I don't see anything in terminal, but moreso the rate at which I see the output is waay too slow as you can see in the video shared above. And this only happens for the sensor data that I'm outputting over UART in a thread

RE: UART TX in particular seems to have a race condition with scheduler running

ovrebekk — Thu, 02 Dec 2021 07:05:53 GMT

Have you checked with the debugger if the UART interrupt is actually called?

And if it is called, will it get to the point where the TxByte() function is called to load the next byte?

If you only see one byte of data every time you try to write a string it seems like the UART interrupt is not working properly.

Best regards
Torbjørn

RE: UART TX in particular seems to have a race condition with scheduler running

morpho — Tue, 30 Nov 2021 17:18:02 GMT

No, _uart.PrintToTermina() is invoked within a thread context and not ISR I believe.
I am setting TWI_IRQ_PRIORITY as the interrupt priority for the I2C sensor and for UART, I'm passing in APP_IRQ_PRIORITY_LOWEST as the priority. So perhaps it causes the UART interrupt to be preempted by the I2C's?

Although I don't read I2C values until after 3 seconds and the UART transmission shouldn't take that long before the next I2C interrupt occurs no?

void twi_handler(nrf_drv_twi_evt_t const * p_event, void * p_context)	   
{
    MCP9808 *obj = static_cast<MCP9808*>(p_context);
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;

    switch (p_event->type)
    {
        case NRF_DRV_TWI_EVT_DONE:
            if (p_event->xfer_desc.type == NRF_DRV_TWI_XFER_RX)
            {
                // unblock the waiting thread (mainThread) once RX XFER is done
                vTaskNotifyGiveFromISR(obj->taskHandle, &xHigherPriorityTaskWoken); 
            }
            else if (p_event->xfer_desc.type == NRF_DRV_TWI_XFER_TX)
            {
                NRF_LOG_INFO("TX transfer done...\n");
                m_xfer_done = true; 
            }
            break;
        default:
            break;
    }
}

void MCP9808::mainThread()
{
    xferData(tmpBuffer, 1);  
    vTaskDelay(pdMS_TO_TICKS(2000));
    uint32_t notifiedValue;

    while(true)
    {   
        uint32_t val = i2cRead(); // invokes TWI interrupt

        uint32_t taskNotify = ulTaskNotifyTake(pdTRUE, portMAX_DELAY);  // blocks the current thread by decrementing ulNotifiedValue to 0 (taking a semaphore)
        if (taskNotify != 0)
        {
	        NRF_LOG_WARNING("Transmission ended as expected...\n");
        }
        else
        {
	        NRF_LOG_WARNING("The call to ulTaskNotifyTake timed out\n");
        }
        
        // if here, ISR is done executing and signalling to unblock this thread

        readTempInC();

        notify(this);       // calling _uart.PrintToTermina() within notify()
  
        vTaskDelay(pdMS_TO_TICKS(3000));
    }
}

RE: UART TX in particular seems to have a race condition with scheduler running

ovrebekk — Tue, 30 Nov 2021 08:43:35 GMT

Any chance you are calling _uart.PrintToTerminal() from interrupt context, with higher or equal interrupt priority to the UART interrupt?

Best regards
Torbjørn

RE: UART TX in particular seems to have a race condition with scheduler running

morpho — Mon, 29 Nov 2021 07:19:23 GMT

Thanks. It does make sense to clear the TXDRDY event inside StartTx so that when the interrupt is fired, it's already enabled which can be disabled then and it does seem to do the trick in this case.

However, I'm seeing an interesting behavior when I call PrintToTerminal() inside a sensor thread which is called as soon as a sensor value is read in a constant loop with a delay of 3 seconds.

That's how I'm invoking PrintToTermina().

snprintf(_notification.msg, 50, "temp: %u", tmpValue); // temp: 20 (for e.g)
_uart.PrintToTerminal(_notification.msg);

seems like every byte is printed every 3 seconds or so as opposed to the each message being printed rightaway so every 3 seconds, we should be seeing a new message. Do you see what could be going wrong here?

devzone.nordicsemi.com/.../ntfMgrPrintDelay.mov

in case you can't see the video: https://imgur.com/a/FKmEPrp

RE: UART TX in particular seems to have a race condition with scheduler running

ovrebekk — Fri, 19 Nov 2021 06:18:50 GMT

[quote user="morpho"]my understanding is: TxByte() sends the first byte only and is never invoked after since the first-byte transmission should enable the TXDRDY event which the interrupt should handle from then on.[/quote]

You call the TxByte() function inside the interrupt handler, as long as there is data in the FIFO. Wouldn't this mean it's called for every transmitted byte, except for the last?

[quote user="morpho"]why inside StartTx? What difference does clearing inside StartTx make than inside TxByte?[/quote]

Then you ensure that the TXDRDY event is cleared before you start a new transaction, but leave it up to the interrupt handler to clear it for every transmitted byte.

Technically it should be enough just to clear it in the interrupt handler, so this might also work.

Best regards
Torbjørn

RE: UART TX in particular seems to have a race condition with scheduler running

morpho — Wed, 17 Nov 2021 23:19:51 GMT

Understood your point about DMA but like you also mentioned, it's mostly used for stuff that requires high throughput like SPI.

Understood about being offered limited support for custom stuff and it's totally fair. It's just if you could see any issues with the logic and if not, it's fine and if so, great!

[quote userid="2116" url="~/f/nordic-q-a/81718/uart-tx-in-particular-seems-to-have-a-race-condition-with-scheduler-running/339453#339453"]I find the fact that you clear the TXDRDY event both in the interrupt handler and in the TxByte function a bit worrying. [/quote]

my understanding is: TxByte() sends the first byte only and is never invoked after since the first-byte transmission should enable the TXDRDY event which the interrupt should handle from then on.

[quote userid="2116" url="~/f/nordic-q-a/81718/uart-tx-in-particular-seems-to-have-a-race-condition-with-scheduler-running/339453#339453"]

Possibly it will work better if you only clear this in StartTx and in the interrupt.

[/quote]

why inside StartTx? What difference does clearing inside StartTx make than inside TxByte?

RE: UART TX in particular seems to have a race condition with scheduler running

ovrebekk — Wed, 17 Nov 2021 13:47:33 GMT

[quote user="morpho"]doesn't UARTE use DMA additionally? why would that ensure no bytes are lost?[/quote]

That's one of the main reasons to use DMA in the first place.

DMA allows UART TX and RX data to be read from and written to RAM in parallel, without the CPU having to be involved. This means that if the CPU is busy handling a high priority interrupt the UART data can still flow in and out of RAM seamlessly.

All the CPU has to do is to prepare the TX and RX buffers in RAM, and let the UARTE peripheral know the address and size of these buffers, before starting a TX or RX transaction.

Other advantages of DMA is less CPU usage and higher data throughput (more important for high speed peripherals like SPI).

[quote user="morpho"]i am actually writing my own driver. do you see whether there's a possibility of a race condition in my snippet?[/quote]

You are free to do that if you want, but please be aware that we can only offer limited support for custom driver implementations. If you are planning to enter production I would strongly discourage it, as the responsibility falls on you rather than Nordic to ensure the driver works satisfactorily.

As for race conditions of the code, I find the fact that you clear the TXDRDY event both in the interrupt handler and in the TxByte function a bit worrying.

Possibly it will work better if you only clear this in StartTx and in the interrupt.

Since UART transmission is controlled from the nRF52 side there shouldn't be any risk of losing bytes here, even without DMA. It is more of an issue for RX data, since this can occur outside the control of the nRF.

Best regards
Torbjørn

RE: UART TX in particular seems to have a race condition with scheduler running

morpho — Wed, 17 Nov 2021 04:32:20 GMT

Yes, this is nRF62840.

doesn't UARTE use DMA additionally? why would that ensure no bytes are lost?

i am actually writing my own driver. do you see whether there's a possibility of a race condition in my snippet?

RE: UART TX in particular seems to have a race condition with scheduler running

ovrebekk — Tue, 16 Nov 2021 10:17:05 GMT

Can you confirm that you are using the nRF52840 device?

First off you should use the UARTE peripheral rather than the UART peripheral in order to ensure that no bytes are lost.

Secondly, you should use the nrfx_uarte driver rather than using the peripheral directly. These drivers have been developed by us over time to configure the peripherals optimally, and have been thoroughly tested to ensure they work well in different applications.

Best regards
Torbjørn