WDC 65C51 chips defective

[BigDumbDinosaur]

Dr Jefyll wrote:

tradeoff. Having a separate pin for the timebase is handy if you need a fixed CPU speed, say, but want to experiment with using a non-standard baud rate.

At least in the case of the NXP UARTs, non-standard baud rates can be configured in software by using the counter/timer as the clock source for the baud rate generator. For example, the 26C92 DUART can be made to run at speeds up to 920 Kbps by having the internal baud rate generator slaved to C/T underflows. To achieve 920 Kbps, the C/T is programmed to free-run at its shortest periodic rate, which is X1 ÷ 4, where X1 is the 3.6864 MHz clock source. The result is that the baud rate generator sees a 921.6 KHz time base. Changing the count loaded into the C/T latches to a larger value can produce a slower baud rate. Almost any baud rate can be programmed, as long as it can be resolved to a 16 bit C/T latch value.

It's patent that with this capability the X1 clock can remain unchanged while operating the UART over a wide range of baud rates. The 920 Kbps maximum rate is intriguing, as the 26C92 (and its big brothers, the 28C94 QUART and 28L98 OCTART) can drive a TIA-485 link with suitable line drivers, making it possible to rig up a poor-man's network that would perform at a reasonable rate, though, of course, not as fast as 10Base-T Ethernet.

[malcnorth]

HELP!!

Does anybody know if this is resolved now, I have just bought 3 spanking new WDC 65C51s and feel cheated!

The current datasheet is still listing it as a bug.

Malcolm

[BitWise]

malcnorth wrote:

HELP!!

Does anybody know if this is resolved now, I have just bought 3 spanking new WDC 65C51s and feel cheated!

The current datasheet is still listing it as a bug.

Malcolm

I don't think its going to be fixed anytime soon -- too much stock of defective chips out there to run down first.

I use a VIA timer to provide an interrupt to schedule the refilling of the transmit buffer in my code.

If you're running at low speed then you could use an original 6551. If not then switch to a more modern chip.

[malcnorth]

Thanks, I kind of guessed that would be the case, all though I'm pretty upset with WDC for continuing to ship pretty useless parts. Especially as they cost me £7 each.

I have already put the code together to use a 6522 timer which works for one board but I don't have a spare timer.

I'm working at 4MHz with 10MHz planned so older ones are not an option. The SCC2691 is not fast enough as WRb time is 150nS so gating R/W with phi2 isn't going to work. I have taken a look at Andre's 16550 board and will probably use that as it will do 100nS, although shoe horning a 40pin device into the design is not going to be easy.

The other point I noted about the Data sheet is that although the parts are spec'd for 14MHz the AC characteristics are only specified at 4MHz.

[malcnorth]

Having read this post further I have decided to switch to the SC28L92 or SC26C92 DUARTs. which are 44pin PLCC unfortunately, but fast (10nS for SC28L92) WRb. Will take a closer look at the datasheet but really impressed with the content of this thread, so useful.

[BigDumbDinosaur]

malcnorth wrote:

Having read this post further I have decided to switch to the SC28L92 or SC26C92 DUARTs. which are 44pin PLCC unfortunately, but fast (10nS for SC28L92) WRb. Will take a closer look at the datasheet but really impressed with the content of this thread, so useful.

I am currently using the 28L92 in my POC V1.1 unit at 12.5 MHz, with both channels running at 115.2Kbps without error, using the built-in hardware flow control features. My driver code fully utilizes the RxD and TxD FIFOs to reduce the volume of IRQs during extended data transfers. The 28L92 replaced the 26C92 that I ran for several years—it was a drop-in replacement, with a minor code tweak.

The 28L92's counter/timer is programmed to generate a 100 Hz jiffy IRQ for timekeeping purposes. The interrupt service routine maintains a UNIX-style time_t date counter—the epoch is October 1 00:00:00 UTC 1752, so time_t is always a positive value—and an up-time counter. There also is a 16 bit down-counter for time delay functions. Long term timekeeping drift is pretty good, averaging no more than two seconds per month—stability is as good as the 3.6864 MHz oscillator driving the UART.

As far as the hardware interface goes, it's actually quite easy. The 28L92 has two possible bus modes: x86 and Motorola 68K. In one of those oddities that come up now and then, x86 is somewhat easier to correctly implement, though requiring an inverted reset signal, and the generation of separate /RD and /WD read/write signals (qualified by Ø2), which is easy to achieve with basic glue logic. The rest of it is the usual chip select and addressing.

[malcnorth]

BigDumbDinosaur wrote:

malcnorth wrote:

Having read this post further I have decided to switch to the SC28L92 or SC26C92 DUARTs. which are 44pin PLCC unfortunately, but fast (10nS for SC28L92) WRb. Will take a closer look at the datasheet but really impressed with the content of this thread, so useful.

I am currently using the 28L92 in my POC V1.1 unit at 12.5 MHz, with both channels running at 115.2Kbps without error, using the built-in hardware flow control features. My driver code fully utilizes the RxD and TxD FIFOs to reduce the volume of IRQs during extended data transfers. The 28L92 replaced the 26C92 that I ran for several years—it was a drop-in replacement, with a minor code tweak.

The 28L92's counter/timer is programmed to generate a 100 Hz jiffy IRQ for timekeeping purposes. The interrupt service routine maintains a UNIX-style time_t date counter—the epoch is October 1 00:00:00 UTC 1752, so time_t is always a positive value—and an up-time counter. There also is a 16 bit down-counter for time delay functions. Long term timekeeping drift is pretty good, averaging no more than two seconds per month—stability is as good as the 3.6864 MHz oscillator driving the UART.

As far as the hardware interface goes, it's actually quite easy. The 28L92 has two possible bus modes: x86 and Motorola 68K. In one of those oddities that come up now and then, x86 is somewhat easier to correctly implement, though requiring an inverted reset signal, and the generation of separate /RD and /WD read/write signals (qualified by Ø2), which is easy to achieve with basic glue logic. The rest of it is the usual chip select and addressing.

Thanks, I have been working on a schematic for a plugin 'debug' board tonight as you say all pretty straight forward so far. The only minor problem is I can only get PLCC44 packages but that's all.

As you everyone has said on here it's infinitely better than the 65c51 but TBH I just want it for debug whilst I bring the board up so it's total overkill for what I want. I'm not using any of the handshake lines so I've used them to switch some Low current LEDs, it means I can use them as debug indicators until I get the board working.

[BigDumbDinosaur]

malcnorth wrote:

Thanks, I have been working on a schematic for a plugin 'debug' board tonight as you say all pretty straight forward so far. The only minor problem is I can only get PLCC44 packages but that's all.

PLCC44 is not a real handicap. If you are doing wire-wrap you can get wire-wrap sockets. If doing a PCB, PLCC44 will consume less space than an equivalent DIP.

Quote:

As you everyone has said on here it's infinitely better than the 65c51 but TBH I just want it for debug whilst I bring the board up so it's total overkill for what I want. I'm not using any of the handshake lines so I've used them to switch some Low current LEDs, it means I can use them as debug indicators until I get the board working.

I started a separate topic on the NXP UARTs. Included is the 28L91, which is a single channel UART that I wouldn't consider to be overkill.

[kiaas]

this wouldn't happen to affect any of UARTs on the MCUs like the W65C256, would it?

[KC9UDX]

It's my understanding that it does. But since I can't recall where I read that, take it for what it's worth, which is not much.

[floobydust]

I'm fairly certain the xmit bug only affects the latest production run of the W65C51 chips. The 134 and 256 controllers should not be affected.

[LIV2]

Just noticed that the datasheet has been updated recently, i'm guessing from the wording that this isn't ever going to be fixed :/

[floobydust]

LIV2 wrote:

Just noticed that the datasheet has been updated recently, i'm guessing from the wording that this isn't ever going to be fixed :/

So they've updated the datasheet to rename the bug in the chip to a "feature". I think this basically seals the fate of the chip. I don't see them making any more chips as they likely had enough quantity made to fulfill expected needs going forward. Based on the newly discovered feature, I doubt they'll ever run out and as a result will never need to make another production run. That's too bad in my view, but it is what it is.

[BigEd]

I think this illustrates one aspect of the economics of chip design and manufacture: it's really cheap to make chips in quantity, but quite expensive to make a design in the first place. WDC seem to have discovered that they cannot afford to correct their bad design - they think they'd get insufficient revenue from a fixed part, so they won't fix it. It's not unusual for a first cut of a chip to have problems, in fact it's normal, so the cost of a second cut is usually priced into the project cost. But if you don't have the resources, or the techniques, or the culture, you have a risk of introducing a new bug when you fix an old one, or when you update a product to run on a different process. That can be expensive, as WDC has found it - it's clear that they would prefer not to have boxed themselves into this corner.

[BigDumbDinosaur]

LIV2 wrote:

Just noticed that the datasheet has been updated recently, i'm guessing from the wording that this isn't ever going to be fixed :/

This is the age in which we live. We can't come right out and admit that a product has a defect and won't correctly function.

BigEd wrote:

I think this illustrates one aspect of the economics of chip design and manufacture: it's really cheap to make chips in quantity, but quite expensive to make a design in the first place. WDC seem to have discovered that they cannot afford to correct their bad design - they think they'd get insufficient revenue from a fixed part, so they won't fix it.

Good analysis. Sales of the 65C51 have likely been extremely poor, not surprising when one considers that the design is out-of-date and quite limited when compared to newer UARTs. About all it has going for it is the ease of attachment to the 65C02 buses. It seems WDC has ended up with a chicken-and-egg situation in which they can't sell the defective devices they have in order to produce the revenue needed to redo the design and produce a fixed UART that will sell better. That's assuming they actually know where the defect lies in the present design.

The 6551 was never a good design, but at least the non-WDC parts worked as advertised. Being forced to use PIO during transmission should be a deal-breaker for anyone who values performance and code efficiency, especially since it is necessary to busy-loop the MPU just to accommodate a chip defect, or set up an overly-complicated timer-generated interrupt to tell the MPU when the 65C51 can accept another datum for transmission. With so many other UARTs readily available, devices that are capable of much higher speeds, have more fine-grained control features and no defects, why anyone would consider the 65C61 baffles me.