This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC13XX UART_RETURN_NEWLINE

Other Parts Discussed in Thread: MSP430WARE, CC2640, CC1310

Hello - 

So we have been fighting with getting our UART read requests to process UART_RETURN_NEWLINE correctly.  We see the \n in binary.

After searching the example code from TI.  Everything seems to be being done in binary mode.  

*** this is from CC13xx EasyLink "Sample Code"

/* Create a UART with data processing off. */
UART_Params_init(&uartParams);
uartParams.writeDataMode = UART_DATA_BINARY;
uartParams.readDataMode = UART_DATA_BINARY;
uartParams.readReturnMode = UART_RETURN_FULL;
uartParams.readEcho = UART_ECHO_OFF;
uartParams.baudRate = 115200;
uart = UART_open(Board_UART0, &uartParams);

-------------------------------

However when we set (in our code) to:

writeDataMode = UART_DATA_BINARY;
readDataMode = UART_DATA_TEXT;
readReturnMode = UART_RETURN_NEWLINE; 
readMode = UART_MODE_CALLBACK;

it doesn't flush when reading when getting the /n.

Every code set (AtTerm.c, uartecho.c, etc.) it's always being set to UART_DATA_BINARY.

Do you have a code example of this working ?  on a CC13xx chipset?  I was thinking that we missed a setting, etc.  But nothing seems to be working.  

In uart.c  the default readReturnMode is UART_RETURN_NEWLINE... so it "should" work.  

/* Default UART parameters structure */   

const UART_Params UART_defaultParams = {
UART_MODE_BLOCKING, /* readMode */
UART_MODE_BLOCKING, /* writeMode */
UART_WAIT_FOREVER, /* readTimeout */
UART_WAIT_FOREVER, /* writeTimeout */
NULL, /* readCallback */
NULL, /* writeCallback */
UART_RETURN_NEWLINE, /* readReturnMode */
UART_DATA_TEXT, /* readDataMode */
UART_DATA_TEXT, /* writeDataMode */
UART_ECHO_ON, /* readEcho */
#if defined(MSP430WARE)
9600, /* baudRate */
#else
115200, /* baudRate */
#endif
UART_LEN_8, /* dataLength */
UART_STOP_ONE, /* stopBits */
UART_PAR_NONE, /* parityType */
NULL /* custom */
};

We have spent "hours" trying to resolve this.

*********** ALSO *******************

In the sample EasyLink Code it appeaers he is using binary data, and parsing it for a return character in code?  Do we think NEWLINE isn't working?  Possibly.

----------- From rfEasylinkTxRx.c --------------

Void echoFxn(UArg arg0, UArg arg1)
{
char input;
uint8_t charIndex;

/* Create a UART with data processing off. */
UART_Params_init(&uartParams);
uartParams.writeDataMode = UART_DATA_BINARY;
uartParams.readDataMode = UART_DATA_BINARY;
uartParams.readReturnMode = UART_RETURN_FULL;
uartParams.readEcho = UART_ECHO_OFF;
uartParams.baudRate = 115200;
uart = UART_open(Board_UART0, &uartParams);

if (uart == NULL) {
System_abort("Error opening the UART");
}


/* Loop forever echoing */
charIndex = 0;

uart_usage();

while (1) {

UART_read(uart, &input, 1);

/* Skip the line feed that appears after an enter as the first character of new line */
if (input == (char)CHAR_LINEFEED)
charIndex--;


if ((input == (char)CHAR_LINE_END_1) | (input == (char)CHAR_LINE_END_2)) // (charIndex < UART_SERIAL_LINE_SIZE))
{
uart_s.lineSize = charIndex;

/* Parse the input into command and arguments */
uart_get_command_and_arguments();

/* Process the commands recived */
/* If command_process returns 1, then process txTaskFunction */
if(command_process())
Semaphore_post(semaphore_txTask);

/* Print the response of the command processing */
UART_write(uart, uart_s.response, uart_s.responseMsgLen);

input = (char)CHAR_LINEFEED;
UART_write(uart, &input, 1);

/* reset index to zero to point to begining of the line */
charIndex = 0;
}
else
{
/* Store the input character */
uart_s.inputLine[charIndex++] = input;
}

}
}

  • If I follow this post from a different product: (CC2640) it clearly states that UART_RETURN_NEWLINE is not supported (as of Mar/2015).

    Could someone @ TI confirm that with the CC1310 the newline function is also not supported? All of your code examples do not use it. It would help save others time, energy and $ to get this confirmed and answered.

    e2e.ti.com/.../408160
  • The response in post e2e.ti.com/.../408160 applies to the CC13xx as they share he same UART driver. I can see that there is no support in the UART driver for UART_RETURN_NEWLINE in the latest GA. The UART driver is supplied in source at tirtos_cc13xx_cc26xx_<versions>\products\tidrivers_cc13xx_cc26xx_<version>\packages\ti\drivers\UART.c/h and tirtos_cc13xx_cc26xx_<versions>\products\tidrivers_cc13xx_cc26xx_<version>\packages\ti\drivers\uart\UARTCC26XX.c/h. I can also confirm that this has not been added to the next release of TIRTOS which is currently in test.

    I will check if we have any plan to add this in the feature. However as there is no HW support for this it would need to be done in SW, and I would suggest that you follow the advice in e2e.ti.com/.../408160.

    Regards, TC.

  • So why is it that in TI documentation, and in the UART.h and .c files you have written descriptions of functionality that do not work?

    This is from the latest UART.h - it's also in the CC1310 native uart.h driver libraries. It's in documentation, source, etc. Why are there not release notes of some kind that say ... the following functionality is not implemented, not supported...

    There's a gap in TI product delivery. If you read the message boards you see all sorts of posts where people are trying to make things work, but they don't work and it's causing headache and delay. But they have no idea if they are going down a path where the underlying driver/software/chip doesn't even support the functionality.

    TI needs a document that clearly outlines what works and what doesn't. So it's not just 'tribal knowledge'.
    ------------------------------------------------------------------------------------------------------------------------------------------

    @brief UART return mode settings
    *
    * This enumeration defines the return modes for UART_read() and
    * UART_readPolling(). This mode only functions when in UART_DATA_TEXT mode.
    *
    * UART_RETURN_FULL unblocks or performs a callback when the read buffer has
    * been filled.
    * UART_RETURN_NEWLINE unblocks or performs a callback whenever a newline
    * character has been received.
    *
    * UART operation | UART_RETURN_FULL | UART_RETURN_NEWLINE |
    * -------------- | ---------------- | ------------------- |
    * UART_read | Returns when buffer is full | Returns when buffer is full or newline was read |
    * UART_write | Sends data as is | Sends data with an additional newline at the end |
    *
    * @pre UART driver must be used in UART_DATA_TEXT mode.
  • I have also experienced this issue. Wasted quite a lot of time and money trying to figure out whats wrong.

    Checked the release notes, documentation and errata to see if it was not (properly) implemented but it was mentioned nowhere.

    The CC1310 is new but is noted as a active part. Documentation is lacking, nowhere it it stated precisely what 

    Will avoid new parts like this in the future until it it for certain these kind of things are implemented / documented correctly.

    Did not expect that anything like this would happen with a reputable brand like TI.

  • Yes - it's like coding by Brail... not fun when you are expecting functionality to be there and it in fact is not there at all. Very misleading on TI's part.
  • Hello guys,

    I am sorry you spent a lot of time on this topic.

    The cc13xx is basically the same platform as the cc26xx, this might not always be clear in the documentation - we are working to improve it.

    For all driver implementations it is important to look at the actual device implementation and not the overall UART driver (supprting many different platforms), in our case the the cc26xx/cc13xx UART driver is described here (for latest TI-RTOS release):

    C:/ti/tirtos_cc13xx_cc26xx_2_16_00_08/products/tidrivers_cc13xx_cc26xx_2_16_00_08/docs/doxygen/html/_u_a_r_t_c_c26_x_x_8h.html

    It does clearly state that this functionality is not supported:

    We will add a note on the UART driver level in the documentation to make this more clear, appreciate your feedback.

  • I understand your frustration at this not being implemented and apologies for any time wasted. UART.c/h are device independent API's for all the platforms supported in TIRTOS. The device specific layer is in uart/UARTCC26XX.c/h, the documentation for this can be found in the release notes:

    C:\ti\tirtos_cc13xx_cc26xx_<tirtos version>\products\tidrivers_cc13xx_cc26xx_<driver version>\release_notes_tidrivers_<driver version>.html

    Under the "Documentation" section click "Device Driver APIs (doxygen)". You will then see a link to UARTCC26XX.h under "CC13xx/CC26xx Implementations". In here UART_DATA_TEXT is present in the "Not Supported Functionality" section.

    Sorry this was not made clearer, we are very committed to continuously improving the documentation and usability of our SW and your comments are appreciated and taken on board. We have filed a bug to make it more obvious that this is not supported.

    Regards, TC.
  • Thanks for the clarification. That helps a ton. We figured it out that it didn't work and worked around it. What's strange is that i searched and searched on UART_REturn_newline() - but never searched on UART_DATA_TEXT - maybe it would have found it earlier. Somehow there has to be a way to provide reference / documentation around a feature/function and what works/what doesn't with each release (?). IDEAL Solution? PUT a reference statement in the header (as a note) - it will direct people to the correct area to look when they get stuck. (e.g. if you are looking @ UART.H - you could very easily point a developer to the HELP file section if they get stuck rather than just legal-eze.

    If the mapping to documentation is similar: you could easily put reference to help files here...


    /******************************************************************************
    * Filename: uart.h
    * Revised: 2015-09-21 15:19:36 +0200 (Mon, 21 Sep 2015)
    * Revision: 44629
    *
    * Description: Defines and prototypes for the UART.
    *
    * Copyright (c) 2015, Texas Instruments Incorporated
    * All rights reserved.
    *
    * Redistribution and use in source and binary forms, with or without
    * modification, are permitted provided that the following conditions are met:
    *
    * 1) Redistributions of source code must retain the above copyright notice,
    * this list of conditions and the following disclaimer.
    *
    * 2) Redistributions in binary form must reproduce the above copyright notice,
    * this list of conditions and the following disclaimer in the documentation
    * and/or other materials provided with the distribution.
    *
    * 3) Neither the name of the ORGANIZATION nor the names of its contributors may
    * be used to endorse or promote products derived from this software without
    * specific prior written permission.
    *
    * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
    * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
    * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
    * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
    * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
    * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
    * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
    * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
    * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
    * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
    * POSSIBILITY OF SUCH DAMAGE.