28L92 clock error

[jmthompson]

More fun as I continue to cobble together the prototype of my next SBC

So I've got a 28L92 UART wired in now, pretty much following BigDumbDinosaur's guide and using his init code, but I'm having some problems. Initially I was just trying to blast out a stream of 'J' at 115.2k bps, and although I could see the bits clocking out on the Tx line my PC (using a USB<->TTL serial dongle) wasn't showing squat except maybe the occasional garbage character. On rare occasions I would see a small burst of Js and then nothing. Nothing I could do would make it happen on demand though.

After a LOT of fiddling I decided to drop down to 9600 bps, and at that point I got my Js....mostly. Interspersed with them were random garbage chars, almost exclusively $F0 or $FF bytes, and one or two $F5 bytes. They would pop up every few dozen bytes and were seemingly randomly distributed.

Next, I decided to eliminate the SBC's role almost entirely and changed the init code to put the UART into automatic echo mode. It seems to work fine at 9600 bps, but I did not push enough bytes through fast enough to trigger the glitches, I think. At 115.k bps I still get nothing, and in fact based on the lights on the serial dongle it looks like the UART isn't even receiving because the transmit light is not blinking at all.

After all this I finally decided to program the UART to output its transmit clock on one of the OPx pins, and that's when I noticed the issue...when set at 115.2k bps the transmit clock is actually closer to 120k bps. At 9600 bps it's almost spot-on but I suspect it's got some occasional glitching that is causing the garbage characters.

The input clock is 3.6864 MHz from a half-can crystal oscillator. The UARTs are ebay buys but both were still sealed in pick-and-place tape. Power is 5V from my bench power supply and the input power seems stable. Everything also has bypass caps, etc. I've swapped out both the oscillator and the UART itself to no avail

I'm attaching jpegs of the input clock and serial clock waveforms; I can print up some schematics too but they're largely unremarkable and I don't think this is a wiring issue.

Has anyone seen something like this before?

[Dr Jefyll]

jmthompson wrote:

After a LOT of fiddling I decided to drop down to 9600 bps, and at that point I got my Js....mostly. Interspersed with them were random garbage chars, almost exclusively $F0 or $FF bytes, and one or two $F5 bytes.

Seems to me you'd do well to get the 9600 sorted out (and forget 115k for the moment). I think you said the 9600 clock is spot on, and that simplifies the puzzle.

Quote:

I can print up some schematics too but they're largely unremarkable and I don't think this is a wiring issue.

It's possible for the drawing on paper to be correct -- and match the prototype -- and yet still have a problem. I'm suggesting there may be some construction issues, although of course I'm only guessing. There's more than one way to attach a wire from point A to Point B. Ditto for ground connections, bypass caps etc. Have you posted any photos of your project? ETA: show us the schematic, too


cheers
Jeff

[jmthompson]

Dr Jefyll wrote:

jmthompson wrote:

After a LOT of fiddling I decided to drop down to 9600 bps, and at that point I got my Js....mostly. Interspersed with them were random garbage chars, almost exclusively $F0 or $FF bytes, and one or two $F5 bytes.

Seems to me you'd do well to get the 9600 sorted out (and forget 115k for the moment). I think you said the 9600 clock is spot on, and that simplifies the puzzle.

I don't mind leaving it at 9600 for now but I believe the problems with both speeds are related and fixing one will fix the other.

Quote:

I can print up some schematics too but they're largely unremarkable and I don't think this is a wiring issue.

It's possible for the drawing on paper to be correct -- and match the prototype -- and yet still have a problem. I'm suggesting there may be some construction issues, although of course I'm only guessing. There's more than one way to attach a wire from point A to Point B. Ditto for ground connections, bypass caps etc. Have you posted any photos of your project? ETA: show us the schematic, too

I'm attaching a snap of the project and the pdf of the schematic. Someone is going to scream at me now when they see that prototype construction... (I swear I started out with a beautiful planned layout to keep wires short!) And the PLCC44 to DIP44 adapter is too wide to fit on a single breadboard which is why it's way off to the side in such a hacky fashion. But aside from the serial clock being wrong it is initializing the UART correctly, and the board is running reliably at 1 MHz; I have code that is manually twiddling a VIA output pin to verify.

The only thing I can think of trying is to bump up to a 7.3728 MHz oscillator and run it through the other half of my 74AC74 to clean it up into a square wave, like I do for the CPU clock. Or I guess I can try that with the existing crystal and just run at 1/2 the baud rate for now.

[jmthompson]

Well it's a software issue, just not sure what yet...

If you look carefully at my scope pictures you'll see that's actually 1.2k bps (aka 1200 bps), not 120k bps. The UART baud rate generator is in normal mode, not extended mode II. It just happens that 9600 bps is the same CSR value in both modes, which is why it worked. But the setting for 115.2k in extended mode II is actually 1200 bps in normal mode. I finally caught this while playing around trying to get 19.2k bps and wondering why the transmit clock was 200 Hz.

Digging in to the code now...

[BigDumbDinosaur]

jmthompson wrote:

Well it's a software issue, just not sure what yet...

If you look carefully at my scope pictures you'll see that's actually 1.2k bps (aka 1200 bps), not 120k bps. The UART baud rate generator is in normal mode, not extended mode II. It just happens that 9600 bps is the same CSR value in both modes, which is why it worked. But the setting for 115.2k in extended mode II is actually 1200 bps in normal mode. I finally caught this while playing around trying to get 19.2k bps and wondering why the transmit clock was 200 Hz.

Digging in to the code now...

I'll read this topic in full and respond later. Gotta gig to go to.

[BigDumbDinosaur]

jmthompson wrote:

The UARTs are ebay buys but both were still sealed in pick-and-place tape.

Can you post a high resolution closeup photo of one of the DUARTs so I can read the markings and verify something?

Quote:

I'm attaching jpegs of the input clock and serial clock waveforms; I can print up some schematics too but they're largely unremarkable and I don't think this is a wiring issue.

Please post the entire schematic in monochrome. The first thing to settle is the design and if it has any "gotchas" that are behind your trouble. Is this running with a 65C02 or a 65C816? If the latter, did you include VDA and VPA in your chip select logic?

A somewhat-obscure note in the 28L92 data sheet mentions that the X1 clock (the signal from your 3.6864 MHz oscillator) should be pulled up to Vcc with a 470 ohm resistor (figure 17 on page 62, most recent data sheet attached). If you did not do so, that may explain the raggedy waveform you are seeing. Also, you did leave pin 37 (X2) unconnected, right?

Please post the code you are using to drive the DUART.

28L92.pdf

NXP 28L92 Data Sheet

(336.96 KiB) Downloaded 203 times

[jmthompson]

BigDumbDinosaur wrote:

Please post the entire schematic in monochrome. The first thing to settle is the design and if it has any "gotchas" that are behind your trouble. Is this running with a 65C02 or a 65C816? If the latter, did you include VDA and VPA in your chip select logic?

It's a 65816 build; I posted the schematic here: viewtopic.php?f=4&t=5385#p64619

VDA and VPA logic are included in my address decode GAL:

Code: Select all

IO1SEL = /A20 * /A19 * /A18 * /A17 * /A16 * A15 * A14 * A13 * A12 * /A11 * /A6 * /A5 * /A4 * VDA * !VPA
IO2SEL = /A20 * /A19 * /A18 * /A17 * /A16 * A15 * A14 * A13 * A12 * /A11 * /A6 * /A5 *  A4 * VDA * !VPA
IO3SEL = /A20 * /A19 * /A18 * /A17 * /A16 * A15 * A14 * A13 * A12 * /A11 * /A6 *  A5 * /A4 * VDA * !VPA
IO4SEL = /A20 * /A19 * /A18 * /A17 * /A16 * A15 * A14 * A13 * A12 * /A11 * /A6 *  A5 *  A4 * VDA * !VPA

Just in case that was somehow broken however I did write a script that turned your initialization table into linear code (complete with a couple NOPs after every write) and the behavior is the same; the BRG is still in normal mode as opposed to extended mode II.

BigDumbDinosaur wrote:

A somewhat-obscure note in the 28L92 data sheet mentions that the X1 clock (the signal from your 3.6864 MHz oscillator) should be pulled up to Vcc with a 470 ohm resistor (figure 17 on page 62, most recent data sheet attached). If you did not do so, that may explain the raggedy waveform you are seeing. Also, you did leave pin 37 (X2) unconnected, right?

The resistor is not in my schematic but I did add it to the build after I took a look at your POCv2 schematic. You can actually see the resistor in the picture I posted of the breadboard build; it's next to the crystal at the bottom middle of the board. And yes X2 is unconnected.

FWIW I did check the waveform without the resistor and the only change I noticed was that the ringing at the bottom of the wave form was pulled up closer to 0V. The waveform did bother me at first, at least until I got far enough along to discover that the problem wasn't the BRG being off-frequency but rather being in the wrong mode.

BigDumbDinosaur wrote:

Please post the code you are using to drive the DUART.

It's pretty much the same code you posted in another thread back in October, except I tweaked the constants in one or two spots for testing (like having it send the Tx/Rx clocks out the OPx pins).

Code: Select all

        ldy     #s_nxptab-2         ;DUART setup table index
@loop:  ldx     nxpsutab,y          ;get register
        lda     nxpsutab+1,y        ;get parameter
        sta     nxp_base,x          ;write to register
        nop
        nop
        nop
        nop
        nop
        dey
        dey
        bpl     @loop           ;next register

I attached my copy of the nxp constants file instead of posting inline, since it's kind of long.

I'll take pictures of the DUARTs when I get home from work. I tried pulling up something from the original hi-res photo of the breadboard (the original is 4096 (!) pixels wide) but some of the markings are smudged and hard to read. Are you thinking maybe these aren't 28L92s but something else, like 28C92s?

[BigDumbDinosaur]

jmthompson wrote:

It's a 65816 build; I posted the schematic here: viewtopic.php?f=4&t=5385#p64619

That schematic would have to be printed out page by page to be readable—all the pages are rotated 90 degrees and are difficult to read on-screen. As I have relatively poor vision I'd have to print them on my large-format printer to make them big enough to read.

Quote:

VDA and VPA logic are included in my address decode GAL:

Code: Select all

IO1SEL = /A20 * /A19 * /A18 * /A17 * /A16 * A15 * A14 * A13 * A12 * /A11 * /A6 * /A5 * /A4 * VDA * !VPA
IO2SEL = /A20 * /A19 * /A18 * /A17 * /A16 * A15 * A14 * A13 * A12 * /A11 * /A6 * /A5 *  A4 * VDA * !VPA
IO3SEL = /A20 * /A19 * /A18 * /A17 * /A16 * A15 * A14 * A13 * A12 * /A11 * /A6 *  A5 * /A4 * VDA * !VPA
IO4SEL = /A20 * /A19 * /A18 * /A17 * /A16 * A15 * A14 * A13 * A12 * /A11 * /A6 *  A5 *  A4 * VDA * !VPA

What operation does the * symbolize? Is that ABEL you used to write your logic?

Quote:

It's pretty much the same code you posted in another thread back in October, except I tweaked the constants in one or two spots for testing (like having it send the Tx/Rx clocks out the OPx pins).

Code: Select all

        ldy     #s_nxptab-2         ;DUART setup table index
@loop:  ldx     nxpsutab,y          ;get register
        lda     nxpsutab+1,y        ;get parameter
        sta     nxp_base,x          ;write to register
        nop
        nop
        nop
        nop
        nop
        dey
        dey
        bpl     @loop           ;next register

That's the setup code. What I'd like to see is the driver code, that is, the code being used to talk to the DUART.

Quote:

I'll take pictures of the DUARTs when I get home from work. I tried pulling up something from the original hi-res photo of the breadboard (the original is 4096 (!) pixels wide) but some of the markings are smudged and hard to read. Are you thinking maybe these aren't 28L92s but something else, like 28C92s?

I'm starting to suspect you were sold 26C92s that were re-marked to look like 28L92s. It is eBay, after all.

The setup for the 26C92 is not exactly the same as the 28L92. According to the NXP data sheet, the 28L92 comes out of reset looking like a 26C92. However, I discovered that isn't quite the case, which led to me concocting a new data table for setup. I subsequently determined that a 26C92 would choke if fed the 28L92's setup values.

[floobydust]

Not to hijack the current diagnosis being done. There is a 65C22 VIA shown in the schematic as well. Perhaps a simpler program to toggle one of the VIA port pins and blink a LED might be beneficial to see if the basic logic decoding is working. Just a thought...

[Chromatix]

Quote:

What operation does the * symbolize?

I assume it's AND. This is consistent with the mathematical notation for Boolean logic, in which multiplication is AND and addition is OR.

[jmthompson]

floobydust wrote:

Not to hijack the current diagnosis being done. There is a 65C22 VIA shown in the schematic as well. Perhaps a simpler program to toggle one of the VIA port pins and blink a LED might be beneficial to see if the basic logic decoding is working. Just a thought...

It is doing that actually; the loop that sends out the Js toggles port B bit 7 on every iteration of the loop regardless of whether or not the UART was ready for a new character, and I am indeed seeing that square wave coming out of the VIA. Everything more or less appears to be working with the exception of the baud rate setting (ie, I know the UART is at least partially configured, because it is being programmed to output its tx/rx clocks on output pins, and I'm seeing those too.)

[BigDumbDinosaur]

Chromatix wrote:

Quote:

What operation does the * symbolize?

I assume it's AND. This is consistent with the mathematical notation for Boolean logic, in which multiplication is AND and addition is OR.

I'm also think it means AND, but am not assuming that until I know the language that was used to program the GAL.

[jmthompson]

BigDumbDinosaur wrote:

jmthompson wrote:

It's a 65816 build; I posted the schematic here: viewtopic.php?f=4&t=5385#p64619

That schematic would have to be printed out page by page to be readable—all the pages are rotated 90 degrees and are difficult to read on-screen. As I have relatively poor vision I'd have to print them on my large-format printer to make them big enough to read.

I know the feeling, mine's getting kinda poor these days too. Probably doesn't help that I'm putting off buying new glasses because they're so danged expensive, even with vision insurance.

I tried to make the printout better but KiCad wouldn't cooperate (no matter what pages I said to print it always wanted to print the wrong page, or all pages. And I couldn't get the rotation to a usable state.) Does your PDF reader not do zoom/rotate? I operate almost entirely on Linux for everything except gaming so I don't use the "official" reader, and my system's native reader will let me rotate the pages and zoom in. I think the best I can do is try to pull up the PDF and re-print to PDF or maybe screenshot the relevant bits.

BigDumbDinosaur wrote:

jmthompson wrote:

VDA and VPA logic are included in my address decode GAL:

Code: Select all

IO1SEL = /A20 * /A19 * /A18 * /A17 * /A16 * A15 * A14 * A13 * A12 * /A11 * /A6 * /A5 * /A4 * VDA * !VPA
IO2SEL = /A20 * /A19 * /A18 * /A17 * /A16 * A15 * A14 * A13 * A12 * /A11 * /A6 * /A5 *  A4 * VDA * !VPA
IO3SEL = /A20 * /A19 * /A18 * /A17 * /A16 * A15 * A14 * A13 * A12 * /A11 * /A6 *  A5 * /A4 * VDA * !VPA
IO4SEL = /A20 * /A19 * /A18 * /A17 * /A16 * A15 * A14 * A13 * A12 * /A11 * /A6 *  A5 *  A4 * VDA * !VPA

What operation does the * symbolize? Is that ABEL you used to write your logic?

It's GALasm code; * is AND, + is OR and / is negation. GALasm runs native on Linux and saves me the trouble of convincing WinCUPL to run under Wine.

BigDumbDinosaur wrote:

That's the setup code. What I'd like to see is the driver code, that is, the code being used to talk to the DUART.

My bad. Here's what is doing the output; it's just an infinite loop to send out the Js. The accesses to $f000 are toggling VIA port B so I can verify that the loop is actually running.

Code: Select all

@full:  lda     $f000
        eor     #$80
        sta     $f000
        lda     nxp_base+nx_sra
        and     #%00000100
        beq     @full

        lda     #'J'
        sta     nxp_base+nx_fifoa
        bra     @full

BigDumbDinosaur wrote:

I'm starting to suspect you were sold 26C92s that were re-marked to look like 28L92s. It is eBay, after all.

The setup for the 26C92 is not exactly the same as the 28L92. According to the NXP data sheet, the 28L92 comes out of reset looking like a 26C92. However, I discovered that isn't quite the case, which led to me concocting a new data table for setup. I subsequently determined that a 26C92 would choke if fed the 28L92's setup values.

This should be simple enough to test with some minor changes to the initialization table and the constants.

EBay is definitely hit-or-miss (so many bad GALs...) I prefer ordering stuff new from Mouser but it kinda sucks when I need say $5 worth of parts and the minimum shipping cost is something like $8...so I only buy new when I have a decently-sized order.

I'll try the 26C92 route tonight once I figure out what I broke last night tinkering with the ROM. Looks like somehow I am losing a data bus bit between the ROM and the CPU now, based on what I'm seeing on the scope, but I can't for the life of me find anything physically wrong (continuity test between the ROM all the way to the outward-facing side of the '245 buffer is good).

[jmthompson]

Prototype is back up and running, so I tried modifying the init table for a 26C92 (specifically I changed the MR0 constant to not set the bit for a 16-byte FIFO, and that was the only thing I could find in the constants that said was specific to the 28L92). I'm getting the same behavior though; the UART is still running at 1200 bps despite asking for 115200.

I tried photographing the chips but the writing on them is kinda faded and didn't come out well in the photo at all. Hell I can barely read them here under my very bright magnifying lamp. They appear to read as:

PHILIPS
SC28L92A1A
CD8369
T1N0505A

[floobydust]

Having read thru this thread a few times, I'm starting to think you may have an access problem between the CPU and the UART. It appears that MR0 is not getting set correctly for the extended baud rates per the datasheet. I had a similar problem writing my BIOS routines and setup for the SCC2691 last year. MR0 wasn't getting configured correctly due to a odd bug in the 65C02. While that bug should not exist in the '816 (provided VPA and VDA are being used properly), it's worth checking to see if this might be the case. BDD remembered this odd behavior with the 'C02 from an earlier thread. For some additional background, see the following thread:

viewtopic.php?f=2&t=4992

Some additional diagnostic coding might help... i.e., just do load and store instructions with no indexing to set the UART up.