On my net5501 I get double characters and corruption on the freebsd boot loader and boot menu, however once the actual freebsd kernel starts it all works properly. wierd
regards, Philip On 05/06/12 08:32, Mouse wrote: >>>> 3. Scrambled: many high-bit characters >>> is a given character either always corrupted or never corrupted? >> I appreciate the help, Mouse. Unfortunately, the answer is No. :-( > > Oh well, it was a nice theory while it lasted. :/ > >>> s\000\332ow\000LX\000\000\264\233\000\000n\000\000\262 = 9600\015 >> ConLock = Enabled\015 >> ConMute = Disabled\015 >> [...rest of output looks good...] >> \015 > >> Note that the first letters of the output from the "show" command -- >> "Speed", I think -- are garbled. After that it's clear. The "h" in >> "show" is ruined, but OK in "ShowPCI". > > This looks to me as though output is corrupted in the presence of input > occurring at the same time. Does the speed with which you type "show" > matter? For example, if you do it manually versus pasting it, does it > affect the syndrome? Looking at the bit patterns from what you quote, > there are some tantalizing similarities between what you got and what > should be there, but I haven't formed a coherent theory for them. > > While it's a very vague feeling, this feels to me like a ground bounce > issue or some such. If you have a 'scope, I'd be inclined to put it > across power and see what you get. Another thing that might be worth > scoping out is the difference between shield ground and signal ground. > It also might be worth trying shorting the Soekris's ground to the > other computer's ground with a separate wire - the Soekris's power > supply probably provides reasonably good isolation from mains ground, > whereas most desktops deliberately earth the case and many power > supplies also earth the 0V line as well. I'm thinking the difference > between desktop<->desktop and desktop<->Soekris could be that the > desktops have a fairly low-impedance path between their grounds because > they're both connected to mains earth. > > Of course, it could also be that something's fried in the serial port > circuitry, too, though I have trouble thinking of a plausible fault > that would produce perfectly clear output when no input is occurring. > Perhaps one of the power rails isn't reaching the serial chip, and, > provided the input pin is at mark, it powers the chip through the > protection diodes? I actually had something similar occur in a circuit > I'd built; it could lead to corruption of output only when input is > also occurring - and, because it's affecting the output driver and > nothing else, explains the "input characters work" part. > > Looking at "show"'s bits, I note... > > s 01110011 > h 01101000 > o 01101111 > w 01110111 > > ...that the three characters that worked have a lot of 1 bits (the same > voltage level as an idle line), and that the characters that got > corrupted occurred when characters with relatively long periods of 0s > (h, \n, and/or \r) were being sent, or had recently been sent. (I'm > assuming the "show" was manually typed, so there's substantial delay > between the h and the o.) > > If you have some way to generate output over a significant time, do you > get clear output with nothing but signal ground and the > Soekris->desktop data line connected (in particular, no desktop-driven > lines connected)? Do you have any other desktop-driven lines which are > driven to the same level as an idle data line connected? > > (I realize that some/all of these may not be easy for you to test....) > > /~\ The ASCII Mouse > \ / Ribbon Campaign > X Against HTML [email protected] > / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B > _______________________________________________ > Soekris-tech mailing list > [email protected] > http://lists.soekris.com/mailman/listinfo/soekris-tech _______________________________________________ Soekris-tech mailing list [email protected] http://lists.soekris.com/mailman/listinfo/soekris-tech
