RTOS/CC1310: Problems whith the UART callback mode / UART call back function not called

Noge

Part Number: CC1310

Tool/software: TI-RTOS

Hi all,

I used the UART driver from the 1_60_00_21 simple link package. The problem is that it seem, the call of the callback function from UART_write is not reliable:
here is coresponding code:

void InitUart(void)
{
    /*******************************************************************
     * Using the
     * e UART
     ******************************************************************/
    if (!UartHandle)
    {
        fUartReadEnable = true;
        UART_init();
        UART_Params_init(&uart_params);
        uart_params.baudRate = 57600;
        uart_params.writeDataMode = UART_DATA_BINARY;
        uart_params.readDataMode = UART_DATA_BINARY;
        uart_params.readMode = UART_MODE_CALLBACK;
        uart_params.writeMode = UART_MODE_CALLBACK;
        uart_params.readReturnMode = UART_RETURN_FULL;
        uart_params.readEcho = UART_ECHO_OFF;
        uart_params.dataLength = UART_LEN_8;
        uart_params.parityType = UART_PAR_NONE;
        uart_params.stopBits = UART_STOP_ONE;
        uart_params.readCallback = readCallbackFN;
        uart_params.writeCallback = writeCallbackFN;
        UartHandle = UART_open(HWDEF_UART0, &uart_params);
        //UartHandle = UART_open(0, &params);
        UART_control(UartHandle, UARTCC26XX_CMD_RETURN_PARTIAL_ENABLE, NULL);
        if (!UartHandle)
        {
            System_abort("UART did not open");
        }
        UART_read(UartHandle, ui8RxData, SIZE_OF_UART_RX_BUFFER);
    }
}

This function is called out of the task to write a buffer of chars:

uint16 WriteUartTXBuffer_CI(uint8 *pbUart_Msg, uint16 bLen)
{
uint8 i;

   if (fUart_EN)
   {
       while (ui16ProcessFlags & PROCESS_UART_TRANSMIT)
       {};
       UART_Counter[9]++;
       for (i=0;i<bLen;i++)
       {
           ui8UARTBuffer[i] = pbUart_Msg[i];
       }
       ui16ProcessFlags |= PROCESS_UART_TRANSMIT;
       UART_write(UartHandle, ui8UARTBuffer, bLen);
       return bLen;
   }
   else
   {
       return 0;
   }
}

here is the call backfunction:

 void writeCallbackFN(UART_Handle handle , void *ui8TXData, size_t size)
 {
	 UART_Counter[1]++;
     ui16ProcessFlags &= ~PROCESS_UART_TRANSMIT;
 }

What may be the reson, that writeCallbackFN() is not been called?

BR noge

over 5 years ago

0 IUsedToBeARealPerson (M-W) over 5 years ago

TI__Guru 58425 points

Hi Noge,

Do this happen all the time or sometimes? Have you tried to verify the return value of the UART_write (to know if it is returning an error status in this case)?

While at it, I would like to recommend you to move to the latest SDK version if possible, it includes important bug fixes for the UART driver (among other things).

0 Noge over 5 years ago in reply to IUsedToBeARealPerson (M-W)

Intellectual 755 points

Hi M-W,
it happens sometimes, not always. At the moment I do not verify the return value, because the UART.h says, it will always return 0. At the moment, I cannot switch easily to a new SDK because otherwise we also have to adapt and test a custom specific library.
Where can I find a detailed decription what was chan ged/fixed in the UART driver?
BR Noge

0 IUsedToBeARealPerson (M-W) over 5 years ago in reply to Noge

TI__Guru 58425 points

Hi Noge,

You can find these in the release notes of the SDKs. An alternative to changing the whole SDK is to simply pull in the UART driver of the new SDK in source and use that instead of the one provided by 1.60.

0 Noge over 5 years ago in reply to IUsedToBeARealPerson (M-W)

Intellectual 755 points

Hi M-W,
I will try it. I saw, there are two versions of the RF driver in the SDK. UARTCC26XX and UARTCC26X0.
Which one would you recomend? What is the main difference?
BR Noge

0 IUsedToBeARealPerson (M-W) over 5 years ago in reply to Noge

TI__Guru 58425 points

I would recommend you to go with UARTCC26XX which is the default one used. The other versions are available for users porting between the CC13xx/CC26xx and CC32xx/MSP432 devices.

0 Noge over 5 years ago in reply to IUsedToBeARealPerson (M-W)

Intellectual 755 points

Hi M-W,
I used the UARTCC26XX.c and UARTCC26XX.h File from the Simple Link V2.30 and I have still the same behaviour. Do you have another idea?
BR Noge

0 IUsedToBeARealPerson (M-W) over 5 years ago in reply to Noge

TI__Guru 58425 points

Hi Noge,

How did you add the new driver to your project, did you replace the SDK files or did you add the files directly to the project?

0 Noge over 5 years ago in reply to IUsedToBeARealPerson (M-W)

Intellectual 755 points

Hi M-W,
I added the source files to my Project.
BR, Noge

0 IUsedToBeARealPerson (M-W) over 5 years ago in reply to Noge

TI__Guru 58425 points

Hi Noge,

Could you put a break point down in the source file you added (inside UARTCC26XX_open or similar) to make sure this is pulled in as expected?

Also, could you try to add a simple return value check following UART_write() to verify that the return value is NULL? The only reason I could think of for you loosing the callback would be that you fail the UART_write() call, which would return -1.

0 Noge over 5 years ago in reply to IUsedToBeARealPerson (M-W)

Intellectual 755 points

Hi M-W,

i did like this but nothing changed:

What we can see here also (and I checked it) I used the UARTCC26XX file I copied into the Project, the UART.c is still from simple link 1.60.

Do you have any other Ideas ?

BR Noge

0 IUsedToBeARealPerson (M-W) over 5 years ago in reply to Noge

TI__Guru 58425 points

Hi Noge,

Can you add uartCC26XXObjects to your expressions and share a screenshot of the object when this happens? Also, can you verify the what the UART status is by checking the UART "FR" register, bit "BUSY"?

0 Noge over 5 years ago in reply to IUsedToBeARealPerson (M-W)

Intellectual 755 points

Hi M-W,

see my screenshot:

BR Noge

0 IUsedToBeARealPerson (M-W) over 5 years ago in reply to Noge

TI__Guru 58425 points

Hi Noge,

This is a tricky one, everything suggest you should have had an interrupt, but the fact that the TX module is still enabled points to the Swi never getting invoked for the write operation. There is two ways this Swi is posted, and as TX interrupts is not active I would suspect you are going straight into "startTxFifoEmptyClk()" in UART_write().

Could you open ROV and share the view of the "Clocks" and "Swi" with me as well?

0 Noge over 5 years ago in reply to IUsedToBeARealPerson (M-W)

Intellectual 755 points

Hi M-W,

here is the ROV Window, but at the time the breakpoint is it is the time before the next UART_write(). so no Interrupt is active. because the

(ui16ProcessFlags & PROCESS_UART_TRANSMIT) is still true the firmware thinks the uart is still transmitting.

So here is the Screenshot:

At the expressions UART_Counter[9] and UART_Counter[1] and also on the UART hardware lines I can see, that the UART write was done, but the TX was not called.

BR Noge

0 IUsedToBeARealPerson (M-W) over 5 years ago in reply to Noge

TI__Guru 58425 points

Hi Noge,

Could you also send a screenshot of the ROV view, showing Hwi, Swi and Clocks view?

0 Noge over 5 years ago in reply to IUsedToBeARealPerson (M-W)

Intellectual 755 points

Oh sorry, It was missed. Here is the corresponding ROV view:

BR Noge

0 IUsedToBeARealPerson (M-W) over 5 years ago in reply to Noge

TI__Guru 58425 points

Hi Noge,

looks like the clock module is messed up in this case as well (like in our other thread). I would suspect these two issues are related to each other.
Let's focus on the "Clock thread" and see if we can figure that one out.

Sub-1 GHz

Sub-1 GHz forum

RTOS/CC1310: Problems whith the UART callback mode / UART call back function not called