9-bit UART mode can not work properly

Kim Shieh

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:

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

Thanks,

Kimec Shieh

over 11 years ago

0 Petrei over 11 years ago

Guru 26105 points

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.

0 Andy Neil over 11 years ago in reply to Petrei

Guru 35415 points

Petrei said:
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 said:
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

0 Petrei over 11 years ago in reply to Andy Neil

Guru 26105 points

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.

0 Kim Shieh over 11 years ago in reply to Petrei

Prodigy 90 points

Hi Petrei,

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

Petrei said:

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.

0 Kim Shieh over 11 years ago in reply to Andy Neil

Prodigy 90 points

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.

0 Petrei over 11 years ago in reply to Kim Shieh

Guru 26105 points

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

0 Kim Shieh over 11 years ago in reply to Petrei

Prodigy 90 points

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.

0 Kim Shieh over 11 years ago in reply to Kim Shieh

Prodigy 90 points

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.

0 Petrei over 11 years ago in reply to Kim Shieh

Guru 26105 points

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

0 Kim Shieh over 11 years ago in reply to Petrei

Prodigy 90 points

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.

0 jussi.kilpelainen over 11 years ago

Prodigy 10 points

Kim Shieh said:
// // 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 ######################## //

Isn't that a clear bug in StellarisWare library and the function UART9BitAddrSend? Why is it not fixed? I tried to contact TI about this but I just received something like "We would like to help, but unfortunately there are over 100,000 under-graduates studying electronics and computer science or engineering in our region (Europe, the Middle East and Africa)."

Of course, one can use 9-bit UART by forcing the parity bits to one and zero manually, but I still think these functions should work as they are the first thing to try when implementing 9-bit UART and they create some confusion.

If it's something I've missed, I'm sorry I spammed my "help requests" through two channels.

Arm-based microcontrollers

Arm-based microcontrollers forum

9-bit UART mode can not work properly