6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 10, 2024 4:08 pm

All times are UTC




Post new topic Reply to topic  [ 132 posts ]  Go to page 1, 2, 3, 4, 5 ... 9  Next
Author Message
 Post subject: 28L92 not transmitting
PostPosted: Tue Apr 04, 2017 9:39 am 
Offline

Joined: Sat Jun 04, 2016 10:22 pm
Posts: 483
Location: Australia
In my build, I use a 28L92 DUART as my RS-232 chip.
I cannot get a peep out of it, either on the terminal or on a piezo. The terminal gets a $00 when I turn off the 6502, and the piezo clicks when I turn it on.
I was using Termite on Windows(I have Putty there and on Linux as well), and this FTDI cable. It ends in a 1x6 header socket connector, and I've matched the pinout on my board(with the appropriate null-modem connections), connected to the DUARTs channel B. Channel A is connected to two 3-pin headers, intended to go to the keyboard and display. One pin each for power and ground, and one for data(from the keyboard or to the display).
This is the code I used to try and get the thing going. It's written for the SB-Assembler, and all it's supposed to do is spew a stream of 'X's out channel B, using 300 8N1, no handshaking.
Code:
   .CR 65c02
   .TF duartTest.hex, INT
   .OR $8000         ;the address of the program for the 6502
   .TA $0000         ;the address of the program in the ROM
   .LF duartTest.lst

;This program sets up the DUART channel B for 300 8N1, and repeatedly outputs
;'X'. At least in theory.

DUART       = $5000
DUART.MRA   = DUART
DUART.CRA   = DUART + 2
DUART.IMR   = DUART + 5
DUART.MRB   = DUART + 8
DUART.CSRB  = DUART + 9
DUART.SRB   = DUART.CSRB
DUART.CRB   = DUART + $A
DUART.FIFOB = DUART + $B


   LDA #%00001010
   STA  DUART.CRB      ;disable channel B
   LDA #$B0
   STA  DUART.CRA      ;expose MR0A
   STA  DUART.CRB      ;expose MR0B
   LDA #$00
   STA  DUART.MRA      ;set baudrate mode/group to normal
   LDA #%00111000
   STA  DUART.MRB      ;no watchdog, 16B FIFOs, RxIRQ: 1+ full, TxIRQ: 16B empty
   LDA #%00010011
   STA  DUART.MRB      ;no HW Handshake, no parity, 8b/char, err per char
   LDA #%00000111
   STA  DUART.MRB      ;normal ch mode, 1 stop bit, no HW Handshake
   LDA #44
   STA  DUART.CSRB      ;set data rate to 300bps
   LDA #$00
   STA  DUART.IMR      ;no IRQs, I'm polling.
   LDA #%00000101
   STA  DUART.CRB      ;enable channel B
   
;Initialization done
;Now repeatedly send $58; 'X' in ascii
;fill until SRB[2] = 0
   LDX #$58

IfSpaceLeft:
   STX  DUART.FIFOB

IfNoSpaceLeft:
   LDA  DUART.SRB
   AND #%00000010      ;mask out everything except TxRDY
   BNE IfSpaceLeft
   BRA IfNoSpaceLeft

   .NO $FFF9
   RTI               ;dummy interrupt routine.

   .HS .F9.FF         ;NMI vector
   .HS .00.80         ;Reset vector
   .HS .F9.FF         ;IRQ vector

I think I'm doing something wrong(otherwise it'd work, right?) and I want to try going after software before I start thinking about hardware. That build is wires under a protoboard, and it's a royal pain to deal with PLCC sockets that way, so I really do not want to have to re-wire it. Does anyone have any suggestions?

I do want to go to a PCB eventually, but laying out the schematic in KiCAD is annoying, because I've already done that work. Doing it a second time in an uncooperative program is frustration that I don't want. I can lay out a circuit board on paper easily enough(I know because I did it), but getting the program to do anything gerber-related without a schematic is not possible, to my knowledge.


Top
 Profile  
Reply with quote  
PostPosted: Tue Apr 04, 2017 2:16 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
DerTrueForce wrote:
I want to try going after software before I start thinking about hardware.
Understood. Still, if you don't quickly find an obvious software problem then don't stay focussed there too long. It's worth checking for obvious hardware problems! (eg: check that the DUART is getting a chip-slect signal.)

DerTrueForce wrote:
getting [KiCAD] to do anything gerber-related without a schematic is not possible, to my knowledge.
Seems to me this is possible, although it's not the norm. Read what ElEctric_EyE had to say in this other thread.

-- Jeff

ElEctric_EyE wrote:
I needed to do a board layout without schematics. This seems to be a foreign concept to most people using KiCAD. [...] I believe the absolute minimum schematic required is one that represents the power(s)/ground(s) NETs

_________________
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  
PostPosted: Tue Apr 04, 2017 3:47 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
I forgot to ask: Are you confident the problem is confined to the DUART? IOW, is your new computer functional otherwise?

_________________
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  
PostPosted: Tue Apr 04, 2017 4:59 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8479
Location: Midwestern USA
In line with Jeff's question, please post a schematic so we can examine your interface of the 28L92 to the rest of the circuit. I'm busy right now, but will review your setup code later on. The order in which registers are written is important.

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


Top
 Profile  
Reply with quote  
PostPosted: Tue Apr 04, 2017 8:01 pm 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
DerTrueForce wrote:
...
I cannot get a peep out of it, either on the terminal or on a piezo.
...
I think I'm doing something wrong(otherwise it'd work, right?) and I want to try going after software before I start thinking about hardware. That build is wires under a protoboard, and it's a royal pain to deal with PLCC sockets that way, so I really do not want to have to re-wire it. Does anyone have any suggestions?

I mention a couple of questions which may help to isolate the bug:
0) Power supply and /RESET (at the DUART) checked?
1) Is the processor is running correctly? Have you some other sort of output (e.g. a blinking LED) to verify that the µP is working well?
2) You mentioned a mess of wires - have you take an ohmmeter or a beeper to verify that the wiring is correct?
3) Could you verify regular accesses (DUART CS = low) when looping inb IfnoSpaceleft?
4) Could you verify whether the bausrate oscillator is running?
5) The setup seems to be ok, allthough I haven't read all the datasheet, I would omit disabling channel B at the begin of your setup, as well as I won't touch channel A (STA DUART.CRA). The enable command at the end is ok.
6) What do you mean with "a piezo"? Is there a piezo connected to an output pin of the DUART? If so, have you try to get it beep?

Good luck!


Top
 Profile  
Reply with quote  
PostPosted: Tue Apr 04, 2017 10:47 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8479
Location: Midwestern USA
GaBuZoMeu wrote:
I mention a couple of questions which may help to isolate the bug...

I suspect the problem may be related to how the 28L92 is wired into the circuit, which is why I suggested he post a schematic. In particular, the 28L92 can be configured for use with a Motorola style bus (synchronous) or x86 style bus (asynchronous, which is what I use in my POC units). Each configuration mode has implications on what the device thinks is a hardware reset, as well as how chip select, read enable and write enable are used. Also, understanding the device's timing characteristics is essential to getting access to the configuration register to work as expected.

As for the software configuration steps, disabling the unused channel causes no harm and actually simplifies determining if the DUART is working, as fewer variables are into picture.

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


Top
 Profile  
Reply with quote  
PostPosted: Tue Apr 04, 2017 11:52 pm 
Offline

Joined: Sat Jun 04, 2016 10:22 pm
Posts: 483
Location: Australia
Dr Jefyll wrote:
I forgot to ask: Are you confident the problem is confined to the DUART? IOW, is your new computer functional otherwise?

Yes it is. I have a test program that counts up on a VIA port, and that works. I have not yet tested the 65SPI, but I know that the ROM, 'C02 and VIA all work together.

BigDumbDinosaur wrote:
In line with Jeff's question, please post a schematic so we can examine your interface of the 28L92 to the rest of the circuit.

I have attached a schematic. It is a touch out of date, as there are no 3.3V SPI-10 ports or 3v3 regulator, but the rest is pretty accurate. I have omitted some of the part numbers, but the GAL is a 16V8, and the DUART is the 28L92.

GaBuZoMeu wrote:
I mention a couple of questions which may help to isolate the bug:
0) Power supply and /RESET (at the DUART) checked?
1) Is the processor is running correctly? Have you some other sort of output (e.g. a blinking LED) to verify that the µP is working well?
2) You mentioned a mess of wires - have you take an ohmmeter or a beeper to verify that the wiring is correct?
3) Could you verify regular accesses (DUART CS = low) when looping inb IfnoSpaceleft?
4) Could you verify whether the bausrate oscillator is running?
5) The setup seems to be ok, allthough I haven't read all the datasheet, I would omit disabling channel B at the begin of your setup, as well as I won't touch channel A (STA DUART.CRA). The enable command at the end is ok.
6) What do you mean with "a piezo"? Is there a piezo connected to an output pin of the DUART? If so, have you try to get it beep?

Good luck!

0) I checked power and ground, and they have continuity up to the chip pin. So does the reset line, which is active-high for this device. I'm using the 16V8 to generate that from the normal reset line. I also measured the reset line voltage at the chip, and it coresponds with an active-high reset.
1) Yes, I have 8 blinking LEDs! :)
2) I did a big bout of electrical tests when I finished wiring it up, and I think I fixed all the problems that manifested. There was one, which I think was a transient error, that involved two of the data lines shorting. I don't know what caused it, but it doesn't pop up often, if at all.
3) I don't have a scope available to me, but my multimeter says there's 3.59V on that pin, so I assume that means it's being selected repeatedly.
4) I put that on an oscilloscope when I was at uni(just because), and it worked there. Probing the output pin on the oscillator can with a multimeter gives 2.51V, so it's probably working.
5) I disabled channel B at the beginning because I wanted to try and avoid any problems with configuring it while it was running. The channel A accesses are to ensure that the baudrate group is the one with 300 baud in it.
6) I have a piezo that I reclaimed out of a dead computer. It was serving as its internal speaker(back when BIOS beeps were a thing). I connected it between the DUART's output and ground. It clicked when I turned it on and off(hard to hear against the noise of the switch), but that was all the noise it produced.
BigDumbDinosaur wrote:
As for the software configuration steps, disabling the unused channel causes no harm and actually simplifies determining if the DUART is working, as fewer variables are into picture.

I don't disable channel A. That write to CRA is to get MR0A into focus so I can set the baudrate group, because the same bits in MR0B don't do that. I'll try disabling channel A in the same write(as the datasheet says you can), and see how that goes.


Attachments:
Ittiara Schematic v3.0.JPG
Ittiara Schematic v3.0.JPG [ 2.54 MiB | Viewed 2020 times ]
Top
 Profile  
Reply with quote  
PostPosted: Wed Apr 05, 2017 1:44 am 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
So far everything looks OK. More questions/suggestions:

The beeper may be of that kind that acts only like a speaker, so you have to toggle the output pin rapidly. Some of them require a parallel resistor to work. Perhaps you can give it a try. To be sure that it could beep, you may start using one pin of the VIA. 1KHz is good. And if this works with the VIA, then using the 28L92 could verify, that there is no addressing problem.

Did you checked the TxD pin of the 28L92 whether there something happens or did you look at the FTDI/Terminal only?

Again good luck!


Top
 Profile  
Reply with quote  
PostPosted: Wed Apr 05, 2017 3:57 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8479
Location: Midwestern USA
DerTrueForce wrote:
I have attached a schematic. It is a touch out of date, as there are no 3.3V SPI-10 ports or 3v3 regulator, but the rest is pretty accurate. I have omitted some of the part numbers, but the GAL is a 16V8, and the DUART is the 28L92.

I don't see connections for channel A's CTS and RTS pins. You need to assert CTS if you expect that channel to transmit.

Quote:
0) I checked power and ground, and they have continuity up to the chip pin. So does the reset line, which is active-high for this device. I'm using the 16V8 to generate that from the normal reset line. I also measured the reset line voltage at the chip, and it coresponds with an active-high reset.

What specifically is the voltage at the DUART's reset input when asserted?

Quote:
3) I don't have a scope available to me, but my multimeter says there's 3.59V on that pin, so I assume that means it's being selected repeatedly.

4) I put that on an oscilloscope when I was at uni(just because), and it worked there. Probing the output pin on the oscillator can with a multimeter gives 2.51V, so it's probably working.

You really need to use a logic probe (or scope) to ascertain that /CS is being pulled low and that you aren't seeing something else.

What are the logic equations for the GAL? I'm curious about how you are generating the DUART /CS, as well as the /RD and /WR signals.

Lastly, check the data sheet for the X1 clock generator and verify that it produces a CMOS output, not TTL.

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


Top
 Profile  
Reply with quote  
PostPosted: Wed Apr 05, 2017 4:35 am 
Offline

Joined: Sat Jun 04, 2016 10:22 pm
Posts: 483
Location: Australia
GaBuZoMeu wrote:
The beeper may be of that kind that acts only like a speaker, so you have to toggle the output pin rapidly.

It is that type, and I have gotten it to beep on a VIA before, so I know it works.

BigDumbDinosaur wrote:
I don't see connections for channel A's CTS and RTS pins. You need to assert CTS if you expect that channel to transmit.

What specifically is the voltage at the DUART's reset input when asserted?

I plan to disable hardware handshaking, as neither keyboard nor LCD has handshaking support. Is that going to be an issue?
The voltage at the DUARTs RESET pin is 4.81V when I'm holding the reset button. It isn't on the schematic, for some reason, but it's connected between the /RES line and GND.

BigDumbDinosaur wrote:
You really need to use a logic probe (or scope) to ascertain that /CS is being pulled low and that you aren't seeing something else.

What are the logic equations for the GAL? I'm curious about how you are generating the DUART /CS, as well as the /RD and /WR signals.

Lastly, check the data sheet for the X1 clock generator and verify that it produces a CMOS output, not TTL.

I tried to build a logic probe when I had my last issue with this build, but it never worked. Probably something about 74HC as opposed to 4000. I still have it lying about, but I don't really know why it isn't working.

I can't find the code I used for the GAL, but I remember how it works. The chip selects are all generated by the address lines and nothing else. I'm synthesizing /RD and /WR, both from Phase 2 and R/W. RES is generated by inverting /RES.

The X1 generator is an MXO45 can oscillator. The datasheet says it produces HCMOS/TTL signals. Looking at the actual numbers, the output with a CMOS load is 90% of Vcc. This one only has a single CMOS load, so that number should be good.


Top
 Profile  
Reply with quote  
PostPosted: Wed Apr 05, 2017 5:24 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8479
Location: Midwestern USA
DerTrueForce wrote:
I plan to disable hardware handshaking, as neither keyboard nor LCD has handshaking support. Is that going to be an issue?

It won't be as long as the 28L92 transmitter setup has been configured to not look at CTS. Bit 4 of MR2 of each channel must be set to 0 to disable transmitter hardware handshaking.

Quote:
The voltage at the DUARTs RESET pin is 4.81V when I'm holding the reset button. It isn't on the schematic, for some reason, but it's connected between the /RES line and GND.

4.81 volts is well above the minimum, so you should be okay with reset.

Quote:
I can't find the code I used for the GAL, but I remember how it works. The chip selects are all generated by the address lines and nothing else. I'm synthesizing /RD and /WR, both from Phase 2 and R/W. RES is generated by inverting /RES.

That logic sounds right, so I think you should be okay with chip select, etc.

Quote:
The X1 generator is an MXO45 can oscillator. The datasheet says it produces HCMOS/TTL signals. Looking at the actual numbers, the output with a CMOS load is 90% of Vcc. This one only has a single CMOS load, so that number should be good.

I'd say at this point your hardware should be good to go. Time to carefully examine your configuration.

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


Top
 Profile  
Reply with quote  
PostPosted: Wed Apr 05, 2017 5:39 am 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
DerTrueForce wrote:
GaBuZoMeu wrote:
The beeper may be of that kind that acts only like a speaker, so you have to toggle the output pin rapidly.

It is that type, and I have gotten it to beep on a VIA before, so I know it works.

Well then you could try let it beep. After setup the OPCR you only need to store a constant value first in SOPR then delay then same value in ROPR delay and loop. Perhaps you should set & reset simply all outputs (if you have wrongly counting the pins and the beeper is not connected to the expected one). If this would work, addressing, /CS, /WR would be ok. If not, you know where to seek in detail.


Top
 Profile  
Reply with quote  
PostPosted: Wed Apr 05, 2017 5:52 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10976
Location: England
BigDumbDinosaur wrote:
DerTrueForce wrote:
I plan to disable hardware handshaking, as neither keyboard nor LCD has handshaking support. Is that going to be an issue?

It won't be as long as the 28L92 transmitter setup has been configured to not look at CTS. Bit 4 of MR2 of each channel must be set to 0 to disable transmitter hardware handshaking.

Although, it's not generally a good idea to have floating inputs, even if you believe you don't care about their value. In some technologies there's a free weak internal pullup, but it still might be best to have a pullup resistor.


Top
 Profile  
Reply with quote  
PostPosted: Wed Apr 05, 2017 6:17 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8479
Location: Midwestern USA
BigEd wrote:
BigDumbDinosaur wrote:
DerTrueForce wrote:
I plan to disable hardware handshaking, as neither keyboard nor LCD has handshaking support. Is that going to be an issue?

It won't be as long as the 28L92 transmitter setup has been configured to not look at CTS. Bit 4 of MR2 of each channel must be set to 0 to disable transmitter hardware handshaking.

Although, it's not generally a good idea to have floating inputs, even if you believe you don't care about their value. In some technologies there's a free weak internal pullup, but it still might be best to have a pullup resistor.

Good thing you mentioned it. In the case of the 28L92, unless the input pins are configured to be active, meaning set to receive inputs, they may be floated. Of course, there's no harm of course in biasing them to ground or Vcc. Other than the two inputs acting as CTS for the two channels, I left all input pins as no-connects in POC V1.1. I have not observed any issues to date.

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


Top
 Profile  
Reply with quote  
PostPosted: Wed Apr 05, 2017 6:34 am 
Offline

Joined: Sat Jun 04, 2016 10:22 pm
Posts: 483
Location: Australia
That is what I should have done as well, but I put a couple of SPI-10 signals there. I'll change the AUX line when I do the PCB, and put it on the SS7 pin of the 65SPI, and connect the IRQ line in to the system IRQ. Splitting up one function into multiple chips is not such a bright idea.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 132 posts ]  Go to page 1, 2, 3, 4, 5 ... 9  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 13 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: