cj7hawk
Veteran Member
The challenge I think you have is that your approach is that it is an end-to-end test of what you've built, which exposes the outcome to any one failure within the system. It may be that you need to test each element much as you did with the latch/read circuit earlier on.
If you use a PC to generate the RS232 signals, you can run a terminal which will show whatever is received and acts as a known constant against which to test the board. Also, if you managed to get a logic probe, it will quickly highlight unanticipated errors related to baud rate and signal framing. Making sure that you're communicating correctly with the chip is also useful. But even a logic probe will tell you when the pulses have left a TX line due to the start bit if nothing else. Using the PC will also tell you quickly whether your problem is with the TX or RX side of things.
Also, reading back a register you've written, or a bit status from the control lines will confirm you're talking to the chip correctly.
It sounds like you're most of the way there - with just a little troubleshooting to finish it.
If you use a PC to generate the RS232 signals, you can run a terminal which will show whatever is received and acts as a known constant against which to test the board. Also, if you managed to get a logic probe, it will quickly highlight unanticipated errors related to baud rate and signal framing. Making sure that you're communicating correctly with the chip is also useful. But even a logic probe will tell you when the pulses have left a TX line due to the start bit if nothing else. Using the PC will also tell you quickly whether your problem is with the TX or RX side of things.
Also, reading back a register you've written, or a bit status from the control lines will confirm you're talking to the chip correctly.
It sounds like you're most of the way there - with just a little troubleshooting to finish it.