Hello, I’m using the FreeRTOS+IO (v1.0.1) on LPC1759. In my project I use several UARTs which work on different baud rates.
I have modified the BSP from Demo provided on official web to work for now only with one UART (UART0) and everything works fine when the UART is opened with

boardDEFAULT_UART_BAUD

. (default baud is 9600). When change the default baud (to 19200) and I try to change baudrate right after

FreeRTOS_open()

with

xReturned = FreeRTOS_ioctl( xUARTPort, ioctlSET_SPEED, (void *) 9600 );

the communication doesn’t work anymore on any baud rate (19200 nor 9600). Am I doing something wrong here?

xUARTPort = FreeRTOS_open( boardUART_0, ( uint32_t ) cmdPARAMTER_NOT_USED );
xReturned = FreeRTOS_ioctl( xUARTPort , ioctlSET_SPEED, (void *) 9600 );

So 9600 works when it is the default, but does not work when it is not the default but gets set to 9600 using FreeRTOS_ioctl()? The default baud rate is set up with the following code:

xUARTConfig.Baud_rate = boardDEFAULT_UART_BAUD;
xUARTConfig.Databits = UART_DATABIT_8;
xUARTConfig.Parity = UART_PARITY_NONE;
xUARTConfig.Stopbits = UART_STOPBIT_1;
UART_Init( pxUART, &xUARTConfig );

The baud rate is set up within ioctl() using the following code:

xUARTConfig.Baud_rate = ulValue;
xUARTConfig.Databits = UART_DATABIT_8;
xUARTConfig.Parity = UART_PARITY_NONE;
xUARTConfig.Stopbits = UART_STOPBIT_1;
UART_Init( pxUART, &xUARTConfig );

so provided ulValue is 9600 it would appear the code snippets were the same. Is it possible that the 1759 does not allow the baud to be changed when the UART is active (the code was created on a 1768, which I would image would have the same UART IP as the 1759, but I don’t know for sure). Regards.

Hello Richard, Thank you for your fast reply. Yes, as I was tracking the code from the ioctl() and open() finctions I came up to those code snippets. By setting the break pionts on them I checked that the value ulValue is set to 9600, but strange thing that happens after ioctl() is that the UART stops to respond. I also suspect that “on-the-fly” baud change is the cause for this. Do you have any suggestion how to confirm this?
I have checked some older posts where you have mentioned that FreeRTOS_close() will not be supported. Is there some legal licencing in question if I implement something like this by my self? The IPs should be the same for 1759 and 1768 (it’s the same manual and there are not any exeptions in UART chapter). I will try my code on 1769 also to check this. Best regards

As you are using the code on an LPC17xx you are covered by the commercial license terms, so there is no problem with you implementing the functions yourself.  Of course it would be nice if you shared the modifications in the FreeRTOS interactive site (http://interactive.freertos.org). To make a quick test you can just add a few lines into the existing code to disable the UART, make the change, then enable it again.  In fact, you could disable it manually by calling the UART driver code directly (not through FreeRTOS+IO) before calling the ioctl() function. Let us know what you find. Regards.

Dear Richard, I have finally came back to this issue. The problem was that Tx was disabled after the UARTInit() call. The solution is to call the UARTTxCmd(). I have made this change in FreeRTOSUARTioctl() function, like this:

case ioctlSET_SPEED :

        /* Set up the default UART configuration. */
        xUARTConfig.Baud_rate = ulValue;
        xUARTConfig.Databits = UART_DATABIT_8;
        xUARTConfig.Parity = UART_PARITY_NONE;
        xUARTConfig.Stopbits = UART_STOPBIT_1;
        UART_Init( pxUART, &xUARTConfig );

        /* Enable Tx. */
        UART_TxCmd( pxUART, ENABLE );
        break;

I havent tried this on 1769 as I promissed, but for 1759 this solves the problem. Thanks again for your help, Best regards