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.

Stellaris LaunchPad - UART flow control with and without FIFO

I've got a strange (to me) issue with UART flow control on LM4F120XL (on Stallaris LaunchPad, using CCS 5.3).

For testing purpouse I use the UART1 both with FIFO enabled and disabled. When FIFO is enabled I use hardware flow control, when FIFO is disabled I'm trying to use the RX interrupt to perform software flow control (I assert and deassert RTS by code insider the interrupt handling routine).

The thing is the I would like to test various RTS behaviours:
1) RTS off after 2, 4, 8, 12, 14 characters when FIFO is enabled
2) RTS off after every char when FIFO is disabled

But what I see is that when FIFO is enabled (with HW flow control enabled) everything works fine. When I disable FIFO (HW flow control disabled), I continue to see RTS behaves exactly as FIFO was ON. This is very strange to me since I verified that UARTLCRH.FEN and UARTCTL.RTSEN are both 0. I'm also sure that RTS is software handeld, because if I comment the RTS assert/deassert lines inside the UARTIntHandler1 routine RTS stays still. This seems to suggest that the RX interrupt is generated accordingly to FIFO trigger level also if FIFO is disabled while I expect that when FIFO is disabled it will work as a one byte register. Could this be possible?

Maybe I've misinterpreted the UART functional description?

Thanks,

  • Daniele,

    First, kudo's for testing everything to such a level, its really awesome to see someone getting this involved with the hardware, go you!

    Second, take a look at the datasheet, under UART Fifo Operations (section 14.3.8) it says
    "Out of reset, both FIFOs are disabled and act as 1-byte-deep holding registers. The FIFOs are
    enabled by setting the FEN bit in UARTLCRH"
    So yes, the when you turn the FIFO's "off" your really just limiting them to 1 byte, the incoming and outgoing data has to have somewhere to start from / go to, from an architecture standpoint this makes sense.

    Hope that clears things up.

    -Austin

  • Thanks Austin,

    the thing is that what I see is that, also if I've disabled FIFO, the rx interrupt is generated upon the trigger level set in UARTIFLS instead of being generated after 1 byte have been received. This is different of what is said in section 14.3.10: "If the FIFOs are disabled (have a depth of one location) and data is received thereby filling the location, the RXRIS bit is set."

    This is my configuration code:

        //
        // Configure the UART1
        //
        GPIOPinConfigure(GPIO_PB0_U1RX);
        GPIOPinConfigure(GPIO_PB1_U1TX);
        ROM_GPIOPinTypeUART(GPIO_PORTB_BASE, GPIO_PIN_0 | GPIO_PIN_1);
        GPIOPinConfigure(GPIO_PF0_U1RTS);
        GPIOPinConfigure(GPIO_PF1_U1CTS);
        ROM_GPIOPinTypeUART(GPIO_PORTF_BASE, GPIO_PIN_0 | GPIO_PIN_1);
        ROM_UARTConfigSetExpClk(UART1_BASE, ROM_SysCtlClockGet(), 115200,
                                (UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE |
                                 UART_CONFIG_PAR_NONE));
        ROM_UARTFIFODisable(UART1_BASE);
        UARTFlowControlSet(UART1_BASE, UART_FLOWCONTROL_TX);
        ROM_UARTEnable(UART1_BASE);

        ROM_IntEnable(INT_UART1);
        ROM_UARTIntEnable(UART1_BASE, UART_INT_RX | UART_INT_RT);

    Then I handle RTS inside the interrupt handling routine.

  • Hi,

    Take care - UARTEnable() enables also the FIFO so the right sequence should be:

    UARTEnable();

    UARTFIFODisable();

    The content of this function can be seen in driverlib/uart.c. ROM_xxx functions can be the same, you can check this by setting a breakpoint after ROM_UARTEnable() and see the content of LCRH register - if FEN bit is set...

    Petrei

  • Dear Petrei, many thanks for you answer! Sometimes the issue is so simple... :-D

    I did not verify well bits inside registers and had not read with all my attention the complete description of UARTEnable... thought it was a simple functions and made the assumption that only UARTEN, TXE, and RXE are affected.

    Many many thanks for having pointed this out!

  • And - if your green pen still at the ready - beware PF0!  On many LX4F (may they rest in peace) PF0 defaults into NMI - and must be "unlocked" via special procedure.

    This may impact your attempt to "steer" PF0 into UART1 compliance.  MCU manual will detail - our group has no experience w/that "crippled" (not a single PWM Generator in residence) MCU.