From: Craig H. <cr...@hu...> - 2005-02-17 16:53:06
|
On Feb 17, 2005, at 8:32 AM, David Farrell wrote: > Craig, > > I saw the same problem on the BTUART that I see > on the HWUART before switching pins. Also in my > testing I set the rate to 57600 with similiar > results. Hmm OK. I couldn't reproduce problems below 230400. I'll run longer tests and see what I see. > Note I also see the errors on the console uart! > All the messages from the bt status reads I do > create alot of console activity, further > stressing > the serial routines. The characters on the > console that come from serial_core.c, whats with > this, some pointer corruption?' The console UART doesn't have flow control enabled by default, nor parity enabled. I've seen corruption of data from gumstix<->serial host on a number of occasions. The apparent data slipping in there from somewhere in the bowels of the serial driver is an oddity though which does seem to argue in favor of some kind of heap and/or stack corruption. > Maybe GCC optimizing is messing up something? Possibly -- none of the code in the serial routines is particularly complex though, and if it were a GCC optimization bug, you'd expect it to fail a lot sooner. It could be that some other screwy thing is happening, like that the interrupt routine is non-reentrant somehow. I'll reread the code with my multithreaded glasses on. > One thing, I am not home now, it occurs to me > that I did not set the CPU to 400MHZ in the > svn build. I'll check later tonight on this. Ah -- I might have been doing most of my testing at 400MHz. Actually I think at 133bus, 266/400 CPU, using turbo mode. I'll double check that and do more testing at 200. > I also used to get the "interrupt triggered but > no.." printk occasionally but you seem to have > commented it out now. Yeah -- I realized what's happening there (or at least have a good theory which fits the evidence). I think what was happening is that (when flow control was asserted but also possibly at other times) data flow would stop for 4+ character cycles, leading to an interrupt being generated for a timeout. But then by the time the interrupt handler was entered, data had started flowing again, and the timeout was cleared, so when you read the interrupt status register to find out what the interrupt was, it reports no interrupt status. C |