Beware of the TL16C2752 DUART

[ArnoldLayne]

Hello,

I recently had my butt kicked by the TL16C2752 DUART. I could not get it to work on the Steckschwein, despite having used a 16C550 for over 10 years without any problems. The DUART kept receiving corrupted bytes. After 2 months of pulling my teeth and hair and whatnot, I finally found an errata document by TI, describing a known flaw in the TL26C2752 and related UARTs with 64 byte FIFOs.


I documented my experience here, may it save someone's time: https://www.steckschwein.de/post/2026/0 ... e-trouble/

[BigDumbDinosaur]

ArnoldLayne wrote:

I recently had my butt kicked by the TL16C2752 DUART. I could not get it to work on the Steckschwein, despite having used a 16C550 for over 10 years without any problems. The DUART kept receiving corrupted bytes. After 2 months of pulling my teeth and hair and whatnot, I finally found an errata document by TI, describing a known flaw in the TL26C2752 and related UARTs with 64 byte FIFOs.

Quote:

TI classifies the severity of this behaviour as “moderate”.

Of course they do.  Can’t be admitting they are selling a defective product. 

Quote:

A suggested workaround is to use 1.5 oder (sic) 2 stop bits.

The “cure” is almost as deadly as the disease.

Quote:

Throwing the TL16C2752 in the bin and use a 16C2552 instead will very certainly work, too.

I’ve looked at the 16C2552 while considering the fading away of the NXP 28L92.  There seems to be little difference between the 2552 and the 16C2752 and it appears neither DUART is produced by anyone other than TI.

Maxlinear’s ST16C2550 appears to be a suitable substitute and I couldn’t find any errata sheet for it.

16c2550_exar.pdf

Maxliner 16C2550 DUART

(816.12 KiB) Downloaded 14 times

BTW, what frequency are you using to drive the DUART?  It appears from TI’s bit rate tables a higher frequency tends to produce smaller timing errors.  I’ve always run the NXP devices at 3.6864 MHz, which produces negligible errors with the odd-ball bit rates.  The 2550/2552/2752 appears to support 7.3728 MHz and 14.7456 MHz, either which would give you more granular timing to deal with runt stop bits.

[ArnoldLayne]

The TL16C2552 is not mentioned in the errata document, so it should be ok. I'm going to find out.

[BigDumbDinosaur]

ArnoldLayne wrote:

The TL16C2552 is not mentioned in the errata document, so it should be ok. I'm going to find out.

I edited my post to add some info gleaned from TI’s errata sheet.

I looked at Maxlinear’s offerings and noticed that while they have listed the 16C2552, the data sheet says it isn’t in production any more and it should not be used in new designs.  Caveat emptor, my friend! 

[ArnoldLayne]

Yep, everyone but TI seems to have retired them.

[BigDumbDinosaur]

ArnoldLayne wrote:

Yep, everyone but TI seems to have retired them.

When I see a mass EOL like that, I get suspicious.  Was it EOLed because it was a slow seller, or was it due to some design “feature” causing potential users to shy away from the part?

[BigEd]

Could be retiring some old process line.

[BigDumbDinosaur]

BigEd wrote:

Could be retiring some old process line.

Could be.  Although not like automobiles, electronic parts are not immune to planned obsolescence.

One thing about the 16Cxxx universe is that it has really expanded.  There are seemingly-countless versions of the basic device, ranging from the broken 16C450 and 16C550 (prior to A-suffixed) parts, to four- and eight-channel devices.  Unfortunately, none has a timer like that of the NXP 26xx/28xx parts.

As I optimistically look forward to developing my POC hardware to increasing capability (assuming my own “timer” doesn’t run out anytime soon), I am thinking about what to do in future designs with serial hardware.  If I switch to a 16Cxxx device, I will need something to replace the 28L92’s timer so I have a jiffy IRQ source and a HPET (I use the timer in POC V1.3’s second DUART as the HPET).  A somewhat-cursory search for something suitable for a PIT either turns up the old Intel parts, which are too slow to work with modern 65xx hardware, or timers that are integral to an MCU.

I’ve thought about making a PIT from a GAL, but GALs generally lack the needed logic fabric—and I shudder at the thought of devoting a CPLD just to act as a timer.  I’ll have to resolve this at some point.

[Sean]

Could you use a 65C22 for your PIT?

[BigDumbDinosaur]

Sean wrote:

Could you use a 65C22 for your PIT?

I could, but have no long-term design plans that include any 65xx I/O hardware.

[ArnoldLayne]

ArnoldLayne wrote:

The TL16C2552 is not mentioned in the errata document, so it should be ok. I'm going to find out.

Short update, swapping the TL16C2752 out for a TL16C2552 did help, of course.