WDC 65C51 chips defective

[GARTHWILSON]

floobydust wrote:

W65C22 with a 24-pin connector for ports/handshake lines

The closest standard IDC sizes are 20 and 26, so I would encourage using one of those if the connector you want to use is a pin header and IDC (as shown in the 65SIB spec.). Pin headers can of course be cut to any size, but that's not true of the IDCs that plug onto them. I recommend making the pinout such that nothing will be damaged if the IDC is accidentally put on backwards, as I show in the basic whole-computer schematic.

[BigDumbDinosaur]

floobydust wrote:

BDD - Thanks for the feedback. Good info on the earlier PC-based UARTs... I lived thru them all during the 80's.... I've also ordered some PLCC versions of the 2691 and a few DIP versions for initial prototyping.

The 2691 is "half" of a 2692. If it were me, I'd go with the 2692 (specifically, 26C92) so I'd have an extra TIA-232 port to connect a terminal or a PC to act as a console. You may find debugging your firmware to be...ah...interesting without some means of direct interaction between your SBC and you.

[BigDumbDinosaur]

GARTHWILSON wrote:

floobydust wrote:

W65C22 with a 24-pin connector for ports/handshake lines

The closest standard IDC sizes are 20 and 26, so I would encourage using one of those if the connector you want to use is a pin header and IDC (as shown in the 65SIB spec.). Pin headers can of course be cut to any size, but that's not true of the IDCs that plug onto them. I recommend making the pinout such that the IDC can accidentally be put on backwards without damaging anything, as I show in the basic whole-computer schematic.

In fact you could consider taking advantage of the extra pins and provide Vcc at one or two of them to power an external device if needed. Inserting a self-resetting fuse into the circuit would be prudent.

[nyef]

You might also consider the SST39SF0x0 family, for x in {1, 2, 4}. Mouser has the '040 in stock as PLCC-32 down to 55ns, and I bought a tube of 70ns DIPs from them not so long ago. Didn't really check the availability on the rest of the family. They're 8-bit parallel FlashROM, in 1, 2, or 4 megabits. Should be dead easy to rewrite in-system at 5v.

[floobydust]

Wow, many replies....

Garth, yes agreed on pin-outs as to not reverse polarity some voltages if the connector is plugged in reverse. I'm using shrouded/keyed connectors, so at least with the boards I'm building it's not an issue, but again.... just some good engineering. I'm planning to wire the dual-port connector mirrored more or less, so if you reverse it, you only reverse the ports

BDD, I'm already using a polyfuse on all of my boards, so agreed, a good idea. I'm choosing the 2691 to keep the size down as the board is quite small for this SBC. It's looking pretty packed so far, but it's still early in design. I have a 6551 running now as a console with the rewrite of SyMon code. I'll build a second I/O board for the 2691 chip and additional HW to interface it to the 65xx. So I won't be losing the existing console, just adding another I/O device, hence not flying blind.

Nyef, I did look at those other Flash memories some time back. Obviously larger than the 32KB I need for my small project, but they are inexpensive compared to the Atmel chips. I already wrote code to write the Atmel chips in circuit some time back so that's a small plus as well, but as noted probably quite simple to modify for these as well.

[GARTHWILSON]

Quote:

I'm using shrouded/keyed connectors, so at least with the boards I'm building it's not an issue, but again.... just some good engineering.

Those are nice, also because the ejector hooks make it easier to remove the IDC without bending header pins. They do take more room though.

[cbscpe]

Any news about the WDC 65C51 issue? I would prefer a small PDIP solution but I need a device for higher CPU speeds (8MHz). So my stock of old 6551 is out of questions. Or should I directly go ahead with a 2691?

[floobydust]

I've not heard anything from WDC on the 65C51 chip issue. I'm also just starting to build up a SCC2691 board so can't comment yet. Reading the datasheet however, it specifies 150ns for some minimum access timing, so it might have some issues running much higher than 6MHz. Other NXP chips, specifically the SC26C92 and the SC28L91/2 can handle higher clock rates on bus timing.

[cbscpe]

Normally no news are good news. But in this case it's rather not. Thanks for the update floobydust. So I will go with the SCC2691 as well. The CPU clock is not a problem as the SCC2691 does not require PHI2, so a simple wait-state generator will do the job.

[BigDumbDinosaur]

cbscpe wrote:

Any news about the WDC 65C51 issue? I would prefer a small PDIP solution but I need a device for higher CPU speeds (8MHz). So my stock of old 6551 is out of questions. Or should I directly go ahead with a 2691?

I recommend you use the SCC26C92, even if you presently don't have a need for dual serial ports. The 26C92's timing supports operation to at least 12.5 MHz (tested on my POC V1.1 unit), whereas the 2691's relatively sedate performance will max out around 6 MHz at most. Also, the 26C92 has an eight-deep FIFO on both receivers and transmitters, which feature can substantially reduce the interrupt processing load. Maximum standard baud rate is 230.4Kbps. The device is available from stock in PDIP40, PLCC44 and QFP44 packages.

ACIA_scc26c92_dual.pdf

NXP SCC26C92 DUART data sheet.

(221.65 KiB) Downloaded 247 times

[BigDumbDinosaur]

floobydust wrote:

I've not heard anything from WDC on the 65C51 chip issue. I'm also just starting to build up a SCC2691 board so can't comment yet. Reading the datasheet however, it specifies 150ns for some minimum access timing, so it might have some issues running much higher than 6MHz. Other NXP chips, specifically the SC26C92 and the SC28L91/2 can handle higher clock rates on bus timing.

Also NXP's SCC28C94.

ACIA_scc28c94_quad.pdf

NXP SCC28C94 QUART data sheet.

(231.41 KiB) Downloaded 256 times

[cbscpe]

Yes, thanks for the information. I definitively will consider the SC26C92, which is still available in PDIP. With my current technique using Verowire this is the easiest to handle. And I never needed more than 2 UARTs in my projects. I once built a card with Verowire and PLCC (the 5380 SCSI controller was only available in PLCC and I really needed a SCSI controller for my Three-Board-Computer) but this was really an eye-soring task. The problem is, in Switzerland it is prohibitively expensive to order PCBs. Local Companies add large surcharges for small batches or private persons and having it done in another country includes import tax and tax handling charges (we are not in EU), in either case even for a small project you end at a PCB price in the order of 200USD per batch.

[cr1901]

WDC updated their datasheet for the 6551 on October 24, 2014. It appears that the parts have been modified slightly so that the XMIT status bit is never set (I suppose cutting through silicon layers is one solution). To quote the October 24 datasheet, page 8:

Quote:

Note: The above text describes normal operation. The latest W65C51N part, there is an issue with Bit 4 not going to a 1. WDC does not recommend polling Bit 4 for transmission with the W65C51N part.

And page 34:

Quote:

The W65C51N will not properly set Bit 4 of the Status Register to indicate the Transmitter Data Register is empty. Determining when to send the next byte would need to be done by using the transmit interrupt or having a software delay loop based on the baud rate used.

Therefore, it appears interrupt-driven solutions in addition to software delays should work (the transmitter interrupt would need to be enabled/disabled in entry/exit from sending data).


Additionally, I have a 14MHz capable part, but timing diagrams only go up to 4MHz. I assume I should be fine running the chip at up to 14MHz? I get the impression this is a relatively recent speed increase.

[floobydust]

Unfortunately, WDC describes the problem in the datasheet incorrectly. I found the original problem, verified it and alerted WDC to it. It exists with the LOT number they are showing in the datasheet. They simply wrote it up wrong. I sent them email after finding this and have not heard back from them.

Again, the Xmit bit is stuck on and enabling xmit interrupts will endlessly generate interrupts. That's the problem, as when your code services the interrupt, the xmit bit shows that the transmit register is ready to accept another character for transmission. As soon as you write the character, the chip stops sending the current character which is in transmission and starts the new one, hence the garbage output. I wrote the small timing loop in the code that runs the chip in polled transmit mode as the only way to tell if the transmit register is read to accept another character is by polling the xmit bit in the status register. The timing loop needs to lose enough time to allow the chip to send a character which is tied directly to the baud rate. Based on this, the bad chips will not work with any existing code as nobody would use a delay loop for transmitting a character as that is the sole intent of having the xmit bit in the status register.

BTW, Receive mode works fine with interrupts. Also, Mouser had their PDIP stock depleted a while back but again have stock. I sent them an email about a week ago asking them if they could check the LOT number on the new chip... nothing yet.

[cr1901]

Well... that absolutely sucks. Having an RS232 UART was a hard requirement for me, and I don't think the 16550 is well suited to the 6502 bus without discrete logic that adds wait states . I suppose I'll have to write my RS232 drive to accommodate this. The worst part is that it's going to be very tedious to test the design because in order to slow down the UART transmit, I have to change the frequency of the loop and burn another EPROM. In any case, I have chips from the old lot, so they are affected. 26C92 requires too much discrete logic, and 6850 can't handle my intended clock speeds (10 MHz).

At least receive mode interrupts work. In any case, thanks for the sample code so I can bastardize- err, modify it to my own needs .