TL16C752C: Framing error in FIFO

Alvin Yeo

Part Number: TL16C752C
Other Parts Discussed in Thread: TL16C752D

Hi, I am currently using this 64 byte FIFO (TL16C752) with C6747 DSP. Currently I am using the FIFO to receive a periodic message of 26 bytes at 50Hz (20ms period). I have set an interrupt from INTA to trigger my read function. Below is the settings for the FIFO uart.

uart settings : 1 start bit, 1 stop bit, 8 data bit, baud 115200, no parity.

input clk is 24MHz (XTAL1)

baud rate = 24MHz (input clk) /1(rescaler) / 13 (DLL) / 16

= 115,385

/********************************************************/

void configureUart(void)
{

SK_TL16C752_LCR |= 0x80; // enable divisor register

SK_TL16C752_DLL = 13; // set divider value to 13

SK_TL16C752_DLH = 0;

Uint8 DLL = SK_TL16C752_DLL; // read back value of divider
Uint8 DLH = SK_TL16C752_DLH;
Uint16 divider = DLL | DLH <<8;

SK_TL16C752_LCR &= 0x7F; // disable divisor register

// Set word length to 8 bits,1 stop,no parity,no break ctrl,disable divisor latch
SK_TL16C752_LCR = 0x3;

SK_TL16C752_FCR |= 0x47; // trigger at 16 chars

// Enable RHR interrupt
SK_TL16C752_IER |= 0x01;

}

/*******************************************************************/

// receive function

void receive()
{

do
{
tLSR = SK_TL16C752_LSR; //get the status of register
LOG_printf(&trace, "tLSR : 0x%x", tLSR);

RECV_BUF[rdata_index] = SK_TL16C752_RHR;
LOG_printf(&trace, "0x%x %x" ,RECV_BUF[rdata_index], tLSR);
rdata_index++;

}while(((tLSR = SK_TL16C752_LSR) & 0x01));

LOG_printf(&trace, " >>>>>>>>>>>>>>>>>>>>>>>>> buf %d ",rdata_index);

}

/******************************************************************************/

results as follows:

1297 0x34 e1
1298 0x12 e1
1299 0xcd e1
1300 0xab e1
1301 0x16 e1
1302 0x0 e1
1303 0x11 e1
1304 0x0 e1
1305 0x1f e1
1306 0x1 e1
1307 0x0 e1
1308 0x0 e1
1309 0x0 e1
1310 0x0 e1
1311 0x80 e1
1312 0x80 e1
1313 0x80 e9
1314 0x80 e9
1315 0x80 e9
1316 0x80 e9
1317 0x80 e9
1318 0x80 e9
1319 0x80 e9
1320 0x80 e9
1321 0x3b e9
1322 0xe4 61
1323 >>>>>>>>>>>>>>>>>>>>>>>>> buf 26
1324 0x34 e1
1325 0x12 e1
1326 0xcd e1
1327 0xab e1
1328 0x16 e1
1329 0x0 e1
1330 0x11 e1
1331 0x0 e1
1332 0x20 e1
1333 0x1 e1
1334 0x0 e1
1335 0x0 e1
1336 0x0 e1
1337 0x0 e1
1338 0x80 e1
1339 0x80 e1
1340 0x80 e9
1341 0x80 e9
1342 0x80 e9
1343 0x80 e9
1344 0x80 e9
1345 0x80 e9
1346 0x80 e9
1347 0x80 e9
1348 0xc7 61
1349 0xfe 61
1350 >>>>>>>>>>>>>>>>>>>>>>>>> buf 26
1351 0x34 e1
1352 0x12 e1
1353 0xcd e1
1354 0xab e1
1355 0x16 e1
1356 0x0 e1
1357 0x11 e1
1358 0x0 e1
1359 0x21 e1
1360 0x1 e1
1361 0x0 e1
1362 0x0 e1
1363 0x0 e1
1364 0x0 e1
1365 0x0 e1
1366 0x80 e1
1367 0x80 e1
1368 0x80 e9
1369 0x80 e9
1370 0x80 e9
1371 0x80 e9
1372 0x80 e9
1373 0x80 e9
1374 0x80 e9
1375 0x3f e9
1376 0xf9 61
1377 >>>>>>>>>>>>>>>>>>>>>>>>> buf 26
1378 0x34 e1
1379 0x12 e1
1380 0xcd e1
1381 0xab e1
1382 0x16 e1
1383 0x0 e1
1384 0x11 e1
1385 0x0 e1
1386 0x22 e1
1387 0x1 e1
1388 0x0 e1
1389 0x0 e1
1390 0x0 e1
1391 0x0 e1
1392 0x0 e1
1393 0x80 e1
1394 0x80 e1
1395 0x80 e9
1396 0x80 e9
1397 0x80 e9
1398 0x80 e9
1399 0x80 e9
1400 0x80 e9
1401 0x80 e9
1402 0xdb e9
1403 0xbe 61
1404 >>>>>>>>>>>>>>>>>>>>>>>>> buf 26

My expected message is 0x34 0x12 0xCD 0xAB 0x16 0x00 0x11 0x00 (2 bytes of counter) (14 bytes of zero) (2bytes of checksum)

strangely I keep getting 0x80 in the middle of the message and my guess is that the 0x80 is the stop bit as there is framing error. Also the checksum at the end is also not correct. Any idea how to resolve this?

over 3 years ago

0 Tyler Townsend over 3 years ago

TI__Mastermind 47998 points

Hi Alvin,

Thank you for your questions about our device.

I had a few questions about your code you provided:

Are you conducting a loop back test via software or hardware?

Alvin Yeo said:
SK_TL16C752_FCR |= 0x47; // trigger at 16 chars

It looks like this line of code enables transmit and receive FIFO's, clears them, sets DMA Mode = 0, 8 spaces for TX FIFO, and 4 characters for RX FIFO. May I ask how you came up with "trigger at 16 characters?"

In your code:

1297 0x34 e1
1298 0x12 e1
1299 0xcd e1
1300 0xab e1.....

Is my interpretation correct?

[Line #] [RHR] [LSR]

0xE1 means you have at least 1 parity/framing/break indication in the FIFO.

0xE9 means the same as E1, but with framing errors in data being read - (received data did not have a valid stop bit)

0x61 is the only condition where there doesn't seem to be errors.

I want to highlight LSR = 0xE9. It seems that there is a stop bit framing error, in which the receiver did not receive a valid stop bit. This device does have a short-stop bit errata. You can find that errata here. One fix is to switch to the "D" version of this device (TL16C752D). Or you can attempt to follow the protocols in the errata to potentially fix the stop bit problem. Try decreasing the divisor by 1. Instead of divisor = 13, try divisor = 12. This will increase the baud rate, and attempt to sample the data a bit faster, possibly catching the stop bit.

Regards,

Tyler

0 Alvin Yeo over 3 years ago in reply to Tyler Townsend

Prodigy 10 points

Hi Tyler,

Thanks for the reply!

Tyler Townsend said:
Are you conducting a loop back test via software or hardware?

I am doing hardware test.

Tyler Townsend said:
It looks like this line of code enables transmit and receive FIFO's, clears them, sets DMA Mode = 0, 8 spaces for TX FIFO, and 4 characters for RX FIFO. May I ask how you came up with "trigger at 16 characters?"

That is correct. The trigger 16 chars is the lowest I can use that I am able to get the correct headers I need. In fact I tried 8 chars for RX and could not get my headers in the message so I used 16 chars.

I tried using divisor 12 but it messes up my headers in my message. Does this mean that only getting the "D" version will solve my issue?

below is the resulf of using divisor 12.

1767 0x34 e9
1768 0x12 e9
1769 0x8d e1
1770 0x6b e1
1771 0x16 e9
1772 0x0 f9
1773 0x11 e9
1774 0x0 f9
1775 0x8b e9
1776 0x1 e9
1777 0x0 f9
1778 0x0 f9
1779 0x0 f9
1780 0x0 f9
1781 0x0 f9
1782 0x0 f9
1783 0x0 f9
1784 0x0 f9
1785 0x0 f9
1786 0x0 f9
1787 0x0 f9
1788 0x0 f9
1789 0x0 f9
1790 0x0 f9
1791 0x6b e9
1792 0xf e9
1794 >>>>>>>>>>>>>>>>>>>>>>>>>>>>
1795 0x34 e9
1796 0x12 e9
1797 0x8d e1
1798 0x6b e1
1799 0x16 e9
1800 0x0 f9
1801 0x11 e9
1802 0x0 f9
1803 0x8c e9
1804 0x1 e9
1805 0x0 f9
1806 0x0 f9
1807 0x0 f9
1808 0x0 f9
1809 0x0 f9
1810 0x0 f9
1811 0x0 f9
1812 0x0 f9
1813 0x0 f9
1814 0x0 f9
1815 0x0 f9
1816 0x0 f9
1817 0x0 f9
1818 0x0 f9
1819 0x74 e1
1820 0xe7 e9

0 Tyler Townsend over 3 years ago in reply to Alvin Yeo

TI__Mastermind 47998 points

Hi Alvin,

Alvin Yeo said:
I am doing hardware test.

Ok. So TXD and RXD pins are electrically shorted on the 752C.

Can you make sure my interpretation of your code is correct?

1795 0x34 e9
1796 0x12 e9
1797 0x8d e1
1798 0x6b e1....

[Line #] [RHR] [LSR]

Alvin Yeo said:
That is correct. The trigger 16 chars is the lowest I can use that I am able to get the correct headers I need. In fact I tried 8 chars for RX and could not get my headers in the message so I used 16 chars.

I understand that you are trying to trigger at 16 chars. I see that you set FCR = 0x47h. This means that FCR[7:6] = 01 = 4 characters. Can you explain how you came up with the total of 16 characters?

Alvin Yeo said:
I tried using divisor 12 but it messes up my headers in my message. Does this mean that only getting the "D" version will solve my issue?

Looks like the code is throwing a lot more errors than before. Lets try moving divisor back to 13. This time, configure your UART frame to generate 2 stop bits instead of 1. "D" version could potentially solve your issue if our problem is a short-stop bit. "D" version of this device corrects the short stop bit errata. If your problem is not a short-stop bit, then ordering the "D" version wouldn't do much.

Regards,

Tyler

Interface

Interface forum

TL16C752C: Framing error in FIFO