• Not Answered

9-bit UART mode can not work properly

Hello,

I am attempting to use UART in 9-bit mode for our RS485 network. The following text is written in the chip's (LM4F232H5QC) datasheet:

■ EIA-485 9-bit support

All the slaves check for the address qualifier in the place of the parity bit and, if set, then compare the byte received with the preprogrammed address. If the address matches, then it receives or sends further data. If the address does not match, it drops the address byte and any subsequent data bytes. If the UART is in 9-bit mode, then the receiver operates with no parity mode.

So I enable the hardware feature and test the function with the following code (master and slave):

// ...
ROM_UARTConfigSetExpClk(RS485_UART_BASE, ROM_SysCtlClockGet(), RS485_BAUD,
	UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE | UART_CONFIG_PAR_ONE);
UARTFIFOLevelSet(RS485_UART_BASE, UART_FIFO_TX4_8, UART_FIFO_RX4_8);
UARTIntEnable(RS485_UART_BASE, UART_INT_TX | UART_INT_RX | UART_INT_RT | UART_INT_9BIT);

// Master address is 0x01,slave is 0x02
UART9BitAddrSet(RS485_UART_BASE, 0x01, 0xFF);
UART9BitEnable(RS485_UART_BASE);

// ...

// Send the address byte to start a transmit
UART9BitAddrSend(RS485_UART_BASE, 0x02);

// Send packets in the interrupt function
UARTCharPutNonBlocking(RS485_UART_BASE, data[i]);

I run the code, and block in the function UART9BitAddrSend():

void
UART9BitAddrSend(unsigned long ulBase, unsigned char ucAddr)
{
    unsigned long ulLCRH;

    //
    // Check the arguments.
    //
    ASSERT(UARTBaseValid(ulBase));

    //
    // Wait until the FIFO is empty and the UART is not busy.
    //
    while(HWREG(ulBase + UART_O_FR) & (UART_FR_TXFE | UART_FR_BUSY))
    {//#################### Block here, the logic seems to be error ########################
    }//#################### UART_FR_TXFE bit set when FIFO is empty ######################## 

    //
    // Force the address/data bit to 1 to indicate this is an address byte.
    //
    ulLCRH = HWREG(ulBase + UART_O_LCRH);
    HWREG(ulBase + UART_O_LCRH) = ((ulLCRH & ~UART_LCRH_EPS) | UART_LCRH_SPS |
                                   UART_LCRH_PEN);

    //
    // Send the address.
    //
    HWREG(ulBase + UART_O_DR) = ucAddr;

    //
    // Wait until the address has been sent.
    //
    while(HWREG(ulBase + UART_O_FR) & (UART_FR_TXFE | UART_FR_BUSY))
    {
    }

    //
    // Restore the address/data setting.
    //
    HWREG(ulBase + UART_O_LCRH) = ulLCRH;
}

I try to correct the mistake and send out the address byte. But the slave receive all bytes sent by master, includding the address byte, even if the address is NOT match!

My question is:

  1. Is something wrong in function UART9BitAddrSend() in StellarisWare library?
  2. How can I use UART in the hardware 9-bit mode? Some samples?

 

Thanks,

Kimec Shieh

 

11 Replies

  • Hi, 

    I have successfully used 9-bit UART in one of my projects, but with Cortex-M3 and I got many useful information from the application note AN01280.pdf. There is also a software package for that.

    Now some comments about your code: it seems OK, although it needs some more insight using the debugger. I suppose you have initialized the slave to be ready to receive an address first, and then it will receive the data. But you must realize that there is no possible synchronization between master and slave at start-up, so you can get some junk bytes first, so this can explain your received bytes, but you must confirm/infirm the presence of a complete in-order frame, use a debugger and look also to the other bits received in each word - these will tell you if the respective word was junk or not.    

    Petrei.

  • In reply to Petrei:

    Petrei
    I have successfully used 9-bit UART in one of my projects, but with Cortex-M3

    I didn't think any Stellaris Cortex-M3s supported 9-bit mode?

    Petrei
    application note AN01280.pdf

    That is a purely-software, "bit-banged" UART - because none of the Stellaris Cortex-M3s has hardware for 9-bit mode

    http://www.ti.com/tool/spma032

  • In reply to Andy Neil:

    Stick parity bit detection/generation was an indication that 9-bit UART is possible, even this is not so much automatized as it is in LM4F or other (microcontroller) brands.

    Petrei. 

  • In reply to Petrei:

    Hi Petrei,

    Thanks for your advice and suggestions, these experience will be useful for my project.

    Petrei

    But you must realize that there is no possible synchronization between master and slave at start-up, so you can get some junk bytes first, so this can explain your received bytes, but you must confirm/infirm the presence of a complete in-order frame, use a debugger and look also to the other bits received in each word - these will tell you if the respective word was junk or not.    

  • In reply to Andy Neil:

    As Andy Neil said, application note AN01280 is a purely-software implementation, and I have used it in project. TI LM4F is support hardware 9-bit mode. Using hardware means high efficiency and low power.

     We have contact with the local technical support, but they did not have a solution.

  • In reply to Kim Shieh:

    What means for you "purely-software implementation"? if you mean by toggling GPIO pins to realize the function then this is not, since you use UARTDTR register to send/receive data and EPS bit is the 9-th bit extension which is added/used when transmitting/receiving and this is hardware. Looking to the UART registers inside both LM3S and LM4F they appear to be the same, except LM4F can offer you a nineth-bit interrupt when the sent address is the same as the slave's. After that anyway you must modify the settings to further accept data (9th bit=0). I also wish to have it set automatically by hardware, but I haven't seen that even on other micro controllers (I do not mention here their names).

    Petrei    

  • In reply to Petrei:

    Petrei,

    Thans for your reply.

    I read the LM4F datasheet again and I imagine that, once the address byte is set in UART9BITADDR register and 9BIT-mode is enabled in slave, the hardware module should recognize the address. If the address matches, it receives the following data; if NOT,  it should drop the address byte and any subsequent data bytes, without notifying the caller. These work should be done by hardware, not by upper software.

  • In reply to Kim Shieh:

    We use UART6 for RS485 transmission(SN74LV123ADR, SN65HVD3088ED) in the beginning, but it works unexpectedly.

    We try to test the function with UART0 (without 485 driver chip), and something changed. Master sends an address byte and some subsequent data bytes. Slave receive the address byte, and UART_INT_9BIT interrupt is triggered indeed, but slave cann't receive any data.

  • In reply to Kim Shieh:

    Hi,

    OK, you are at half way to succeed - what I would do is the following (from the slave point of view):

    • set only the UART_INT_9BIT first and when the interrupt triggers, disable UART_INT_9BIT since this deserves only the address; (this is why I said in a previous post "not fully automatized") ;
    • change the EPS bit to receive data
    • enable receiver interrupts

    When you received the whole frame and need to transmit, then enable only transmit interrupts and send first an address then data (this means to play with EPS bit). After transmission enable again the UART_INT_9BIT. 

    Petrei

  • In reply to Petrei:

    Hi Petrei,

    Thank you for your reply. We now use it like that way you suggest, it seems working properly at present. But I think it's just a temporary solution, because the logic is complex and error-prone.