6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Tue Nov 12, 2024 6:18 am

All times are UTC




Post new topic Reply to topic  [ 41 posts ]  Go to page Previous  1, 2, 3
Author Message
 Post subject: Re: 28L92 clock error
PostPosted: Mon Nov 26, 2018 2:54 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8482
Location: Midwestern USA
Dr Jefyll wrote:
To rule out flow control issues and other factors you could tie the UART handshake lines high or low as required and then just let the project "talk" to your oscilloscope (ie, not a dongle or another computer).

In fact, a temporary loopback could be used to see if what comes out of the receiver agrees with what goes into the transmitter, all the while watching activity on the 'scope. All it would require would be to wire pins 33 (TxD) and 35 (RxD) together, with that junction the pickoff point for the 'scope. Hardware handshaking should be disabled for this test.

The test code would execute as follows:

  1. Poll TxRDY until it is set.

  2. Write datum to transmitter FIFO.

  3. Poll RxRDY until it is set.

  4. Read datum from receiver FIFO and compare to what was written to the transmitter.

  5. If the comparison in step 4 fails, halt and indicate an error in some fashion.

  6. If the comparison in step 4 succeeds, return to step 1 and repeat.

Failure would the result of improper setup (bit rate and/or data format), a faulty UART, faulty X1 clock, or glue logic errors. You could try this testing on the second channel if failure does occur.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: Re: 28L92 clock error
PostPosted: Mon Nov 26, 2018 3:46 pm 
Offline

Joined: Sat Dec 30, 2017 3:19 pm
Posts: 116
Location: Detroit, Michigan, USA
BigDumbDinosaur wrote:
Dr Jefyll wrote:
To rule out flow control issues and other factors you could tie the UART handshake lines high or low as required and then just let the project "talk" to your oscilloscope (ie, not a dongle or another computer).

In fact, a temporary loopback could be used to see if what comes out of the receiver agrees with what goes into the transmitter, all the while watching activity on the 'scope. All it would require would be to wire pins 33 (TxD) and 35 (RxD) together, with that junction the pickoff point for the 'scope. Hardware handshaking should be disabled for this test.

The test code would execute as follows:

  1. Poll TxRDY until it is set.

  2. Write datum to transmitter FIFO.

  3. Poll RxRDY until it is set.

  4. Read datum from receiver FIFO and compare to what was written to the transmitter.

  5. If the comparison in step 4 fails, halt and indicate an error in some fashion.

  6. If the comparison in step 4 succeeds, return to step 1 and repeat.

Failure would the result of improper setup (bit rate and/or data format), a faulty UART, faulty X1 clock, or glue logic errors. You could try this testing on the second channel if failure does occur.


I've had this running for about 30 minutes so far and it's not reporting any errors. Here's the code I'm using:

Code:
@txrdy: lda     nxp_base+nx_sra
        bit     #%00000100          ; check TxRDYA
        beq     @txrdy
        lda     #'J'
        sta     nxp_base+nx_fifoa
@rxrdy: lda     nxp_base+nx_sra
        bit     #%00000001          ; check RxRDYA
        beq     @rxrdy
        lda     nxp_base+nx_fifoa
        cmp     #'J'                ; did we get back what we sent?
        beq     @txrdy              ; if yes, keep looping
        sei
        sta     $f001               ; put what we got back on PA
        lda     $f000
        ora     #%00100000          ; signal error condition on PB5
        sta     $f000
        cli

@dead:  bra     @dead


I was really hoping this test would fail...


Top
 Profile  
Reply with quote  
 Post subject: Re: 28L92 clock error
PostPosted: Mon Nov 26, 2018 4:26 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
What does the scope say? Is the UART outputting a steady stream of properly formed characters at the expected baud rate?

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html


Top
 Profile  
Reply with quote  
 Post subject: Re: 28L92 clock error
PostPosted: Mon Nov 26, 2018 6:15 pm 
Offline

Joined: Sat Dec 30, 2017 3:19 pm
Posts: 116
Location: Detroit, Michigan, USA
Dr Jefyll wrote:
What does the scope say? Is the UART outputting a steady stream of properly formed characters at the expected baud rate?


Yup, scope looks decent (a bit of ringing, but that's an artifact of the breadboard, and doesn't show up nearly as much when I probe the tx line when it's connected to the serial dongle). It's still going too...been running the test for a couple of hours now and no errors detected. To make sure all eight bits are coming through I've also run the test with three additional values: $FF, $55, and $AA. All tests have passed and the scope looks good on all three.

So based on this test it looks like all the control and bus signals between the to/from the UART are functioning. At this point the only real difference between the test code and the real code is that the former is waiting for the byte to be received again before sending another, instead of just sending whenever TxRDY is set. It's interesting to note that TxRDY is bit $04, which is also the bit that should be set on MR0 to enable the extended baud rate II mode. At one point I thought maybe something was wrong with that particular data line, but the fact that all the loopback tests are working kills that idea.

I'm going to attach all the code that prints my banner just in case I missed something. Things to note:

    - Everything of interest is still running out of bank $00, in the F800-FFFF "LOWROM" window.
    - The CPU is in 8-bit native mode, because all of this code came from my previous, 65C02-based build.

First, here's my serial output code:

Code:
putc_serial1:
        pha
        lda     #%00000100
@wait:  bit     nxp_base+nx_sra
        beq     @wait
        pla
        sta     nxp_base+nx_fifoa
        rts


At startup this subroutine is placed into the console_write vector, which is what everything calls to send text to the console (the idea being that at some point I'll have a real video output and can send there instead):

Code:
        lda     #$5c        ; JML
        sta     console_read
        sta     console_write

        lda     #<getc_serial1
        sta     console_read+1
        lda     #>getc_serial1
        sta     console_read+2
        lda     #^getc_serial1
        sta     console_read+3


(The vector users JML but everything is still calling this via JSR from bank $00, and the function still returns with RTS.)

Finally, here's the string print function. It's the same as on the previous board, except it uses a 24-bit pointer.

Code:
writeln:
        sta     ptr
        stx     ptr+1
        sty     ptr+2

        ldy     #0
@loop:  lda     [ptr],Y
        beq     @exit
        jsr     console_write
        cmp     #CR
        bne     @notcr
        lda     #LF
        jsr     console_write
@notcr: iny
        bne     @loop
@exit:  rts


There is a 100 Hz jiffy IRQ from the VIA that also toggles PB7 so I can verify that the board is still running even when the UART is bonkers. Just in case there was a problem with the IRQ handler code I've also tried wrapping writeln in a sei/cli pair; it didn't make a difference.


Top
 Profile  
Reply with quote  
 Post subject: Re: 28L92 clock error
PostPosted: Mon Nov 26, 2018 10:13 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8482
Location: Midwestern USA
jmthompson wrote:
Code:
@txrdy: lda     nxp_base+nx_sra
        bit     #%00000100          ; check TxRDYA
        beq     @txrdy
        lda     #'J'
        sta     nxp_base+nx_fifoa
@rxrdy: lda     nxp_base+nx_sra
        bit     #%00000001          ; check RxRDYA
        beq     @rxrdy
        lda     nxp_base+nx_fifoa
        cmp     #'J'                ; did we get back what we sent?
        beq     @txrdy              ; if yes, keep looping
        sei
        sta     $f001               ; put what we got back on PA
        lda     $f000
        ora     #%00100000          ; signal error condition on PB5
        sta     $f000
        cli

@dead:  bra     @dead

I was really hoping this test would fail...

That it didn't fail eliminates the DUART as the prime suspect. You need to take another look at your serial interface. If it were me, I'd be rigging up a serial transceiver (1488/1489 or MAX23*) and directly driving the serial port of a PC, dumb terminal or similar. If you were to do this and get a coherent display then you will have the direction needed to solve this problem.

Also, since your computer is connected with a big mess 'o wires, pay attention to lead dress and the quality of the connections. You may have one flaky connection that is giving you grief.

Incidentally, a slightly more efficient way to poll the receiver is as follows:

Code:
         lda #%00000001        ;RxRDY flag bit  <—— should be symbolically defined, not hard-coded
;
@rxdrdy  bit nxp_base+nx_sra   ;RxD have a datum?
         beq @rxdrdy           ;nope
;
         lda nxp_base+nx_fifoa ;read datum

          ...etc...

A similar technique for processing the transmitter could also be used.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Last edited by BigDumbDinosaur on Tue Mar 17, 2020 6:55 am, edited 2 times in total.

Top
 Profile  
Reply with quote  
 Post subject: Re: 28L92 clock error
PostPosted: Mon Nov 26, 2018 10:57 pm 
Offline

Joined: Sat Dec 30, 2017 3:19 pm
Posts: 116
Location: Detroit, Michigan, USA
BigDumbDinosaur wrote:
That it didn't fail eliminates the DUART as the prime suspect. You need to take another look at your serial interface. If it were me, I'd be rigging up a serial transceiver (1488/1489 or MAX23*) and directly driving the serial port of a PC, dump terminal or similar. If you were to do this and get a coherent display then you will have the direction needed to solve this problem.


As I mentioned in another post I really haven't got anything that does native serial lying around anymore. I do think I have a true RS-232 serial dongle that I used to use to talk to switches & routers when I was a sysadmin, and I have over a dozen MAX232s in my parts box, so I can at least rig something up with that and see what happens. I'd love to have a dumb terminal but I'm already pretty cramped for space.

The bad serial dongle theory, however, still doesn't explain why I cannot get the BRG to flip to extended mode II. As far as I can tell that is the only thing in the setup table that's not working, and it's consistently not working (eg i have yet to have the board randomly boot up and be in the proper mode, and I can reliably set any bit rate I want as long as it's from the normal mode table). I can't even get extended mode I to work; it still ignores that piece of the initialization sequence.


Top
 Profile  
Reply with quote  
 Post subject: Re: 28L92 clock error
PostPosted: Sat Dec 01, 2018 12:28 am 
Offline

Joined: Sat Dec 30, 2017 3:19 pm
Posts: 116
Location: Detroit, Michigan, USA
Good progress to report. The replacement crystals and UARTs arrived yesterday, and after swapping out the crystal I got an immediate improvement. I'm now getting a pretty solid 38.4k with no missing characters! I have no idea what was wrong with my ebay crystals; on the scope the waveform looks the same as what i'm getting from my ECS-branded crystal, but obviously they weren't up to snuff for this. I think I only paid a buck each for them, so no big loss.

Unfortunately I'm only getting 1200 bps when i request 115.2k, and I've even swapped out to a brand new NXP-branded version of the UART, so obviously there is something wrong with my driver that I need to find. I'm going to keep poking at that as I feel like it, but as long as I'm getting 38.4k for now then I'm happy. :) If this is the only remaining problem I end up having I will declare this prototype build a success and move on to designing the actual PCB and building a final version.

Thanks everyone for your help. You guys were awesome as always!


Top
 Profile  
Reply with quote  
 Post subject: Re: 28L92 clock error
PostPosted: Sat Dec 01, 2018 12:37 pm 
Offline
User avatar

Joined: Thu May 14, 2015 9:20 pm
Posts: 155
Location: UK
I don’t know if this is relevant to your problems, but crystals are available in series or parallel resonant types. If the wrong type of crystal is used, it can oscillate at a slightly different frequency to that marked on it. Alas, that is the limit of my knowledge on this. It would be good if someone who knows more can jump in with more details. NB “crystals series parallel resonant” gets plenty of hits in a search engine.

And of course, it is always buyer beware with trading sites like eBay. Maybe the crystals that were sold to you were cheap because they did not meet the specifications that a normal component supplier would require.

Mark


Top
 Profile  
Reply with quote  
 Post subject: Re: 28L92 clock error
PostPosted: Sat Dec 01, 2018 8:49 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8482
Location: Midwestern USA
jmthompson wrote:
...The replacement crystals and UARTs arrived yesterday...

Crystals?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: Re: 28L92 clock error
PostPosted: Sun Dec 02, 2018 4:10 am 
Offline

Joined: Sat Dec 30, 2017 3:19 pm
Posts: 116
Location: Detroit, Michigan, USA
BigDumbDinosaur wrote:
jmthompson wrote:
...The replacement crystals and UARTs arrived yesterday...

Crystals?


Sorry, oscillators. I sometimes mess up the two terms.


Top
 Profile  
Reply with quote  
 Post subject: Re: 28L92 clock error
PostPosted: Sun Dec 02, 2018 7:02 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8482
Location: Midwestern USA
jmthompson wrote:
BigDumbDinosaur wrote:
jmthompson wrote:
...The replacement crystals and UARTs arrived yesterday...

Crystals?

Sorry, oscillators. I sometimes mess up the two terms.

Was wondering.

I suspect you got some oscillators whose outputs either weren't swinging rail-to-rail or were grossly asymmetric—or both. I know from my piddling around with the NXP UARTs that an oscillator with TTL output instead of CMOS will not drive the UART hard enough to make it "happy."

Now that you've got the circuit apparently working you can now refine your driver to run both channels using IRQs and take advantage of the FIFOs.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 41 posts ]  Go to page Previous  1, 2, 3

All times are UTC


Who is online

Users browsing this forum: No registered users and 12 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: