SBC V2-005i debugging: Garbled serial output

[Miss Argent]

So, I'm working on replacing my old SBC V2-003 board with a V2-005i full build that integrates some nicer parts and some of the soldering technique improvements I've made since. I'm apparently making it into RomWBW, but my serial console output is garbled at all possible baud rates (including the one I specified when I built the ROM). The corruption is consistent - no changes or variability across reboots.

I've checked my 16550, I've checked the 1.8432Mhz crystal, I've checked the MAX232, I've checked the caps supporting the 232 (all via parts swap with known good components), and I've reprogrammed my ROM with the known good older RomWBW build I was using on the original SBC. The remaining 74LS ICs have been tested out of circuit. None of these have affected the problem.

Next stop's the tuning fork (of all things), but I just wanted to ask - anyone else have issues here? is this a known problem with the V2-005i? Should I have gone for the V2-005c, the last tested revision provided on the Retrobrew wiki page?

Attached is my current configuration - the RTC isn't currently configured. (Also the DS1210 is soldered in the socket to mitigate a leg break - I'm planning on replacing this at a later date) None of the solder bridge jumpers on the underside are connected. I've also attached a screenshot of what I see on power-on - It's always perfectly consistent. Text always prints at the same speed, and there's no variety in the garbage between boots. I think it's probably safe to say this is a corrupted RomWBW signon?

[MxArgent]

Correction - When I say "The corruption is consistent", I mean that it always manifests the same way for each individual baud rate. I'm not seeing the same thing across all possible baud rates.

[Tom Storey]

Is parity enabled by any chance on either end?

Do you have a scope and can measure the transmitted bit times to ensure that there isn't a baud rate generation issue?

Other than checking for bad solder joints, broken/crossed traces, shorts etc, that is all that comes to mind immediately.

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/retro-comp/dc7f15d9-95cd-4ded-84d3-48e831a1b95fn%40googlegroups.com.

[Richard Deane]

Some of the cheap logic analysers (e.g. salae compatible) do auto baudrate sensing, they might extract some sanity in the messages to the serial console, especially if the rate is drifting to non standard. If they decode it, then you can focus on the implications of that.

cheers

richard

--

You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/retro-comp/75400fce-1fd1-440b-b43c-eaca225f1d85n%40googlegroups.com.

[MxArgent]

Oh, that's good to know! I've been meaning to dig my Tek scope out of storage and take some measurements, but I've also really been wanting something a little smaller and less unwieldy.

Parity settings are apparently not our culprit; next I'm gonna take a look at the tuning fork xtal. Decided to try and view the schematics in KiCad to help with debugging, too but I've never really used it or the gerber viewer before so I'm still learning how to sort out my layers.

On a different note, I discovered the DuoDyne and realized it might be a more rewarding project for me than revising my older ECB builds. Still gonna top off the V5, but after that I'm pivoting my attention to that prospective Duo build instead of moving on to build a backplane, the DiskIO-V3, and the Zilog Peripherals boards like I was initially going to. I'm interested in something more complex than a RC2014 or the SBC V2 series, but less complex than my S100computers stack.

[Jaap van Ganswijk]

I was also thinking about a parity-error, but can you try using two stop-bits in the sender? I assume you're using chrystals and not resonators. We had a problem using a system with up to 200 clients and the resonators drifted too much. We had to test all the clients and remove some of them or replace their resonators.

To view this discussion visit https://groups.google.com/d/msgid/retro-comp/d07a7c02-0565-432a-9c21-ee1457dbb27dn%40googlegroups.com.

[Jaap van Ganswijk]

Btw I see YyouckW or such three times. Can you see what the original text was? I see also another pattern repeated. I propose that you write out the bit-patterns.

[MxArgent]

Yeah, I had to repost that a few times. I think I was getting caught in some sort of filter? The other two had roughly the same contents, they were just worded slightly differently. 

Here're my oscillators:

8MHz -> ECS-2100AX-080 (CPU clock, but it doesn't hurt to include)

1.8432MHZ  -> ECS-2100A-018

32.7680KHZ -> ECS-.327-12.5-13X

The first two have been swap tested with identical parts from my V2-003, but the tuning fork remains a little suspicious since I can't recall what the part number on the V2-003 was and I had a leg break off while I was trying to desolder it. (d'oh)

[Greg Holdren]

There is group owner moderation for suspect/1st posting messages and google filtered message moderation (what criteria? who knows). I saw two messages that came through as "Pending" for moderation. I let the last version go through since it was the newest and deleted the first one. I figured the last one was the updated version as the two messages were similar.

You clear to post from now on as you can tell without moderation unless it cross some weird Google Group filter criteria.

Greg

[MxArgent]

Ah, that makes sense! Thanks for letting me know, and sorry about making you sort out the duplicates.

[Tom Storey]

I'd also thought about looking at the bit patterns, as Jaap van Ganswijk suggested, and wrote out some of the bit patterns just now out of curiosity.

The most telling feature is that bit position 0 is almost always set for the characters that are printed. It was looking like it might be always, until I saw an asterisk, which has a 0 in bit position 0. Still very odd though...

Clues are that you only ever see odd numbers, you can see both [] and {}, but only ever ) and never (, etc.

So I would perhaps look at bit 0, trace it back from the UART, and see whether this is bridged to a positive voltage rail, or a pin on this signal is not properly socketed, or perhaps try a different UART chip if that otherwise looks ok - perhaps yours has an internal fault that causes it to see bit 0 as high.

To view this discussion visit https://groups.google.com/d/msgid/retro-comp/b07d304b-1748-4fb3-87a6-a9634c818248n%40googlegroups.com.

[Alan Cox]

Check the signal isn't inverted if you are seeing that.

[MxArgent]

Ah, interesting observations! I do have a second known good 16C550 I did a swap test with, but that actually didn't change anything. I think something might be up with the PCB itself, though I still need to break my tools out and poke around.