From: David F. <dav...@ya...> - 2005-02-17 03:02:58
|
Bluetooth still dies.... My Bluetooth notes: Gumstix Build 387 I run the following script which alternates between two bluetooth devices. Only HCID is enable in /etc/defaults/bluetooth and the baud rate is 230400. # hcitest hcitool info 00:0C:41:E1:FC:A6 hciconfig l2ping -s 64 -c 1 00:0C:41:E1:FC:A6 cat /proc/tty/driver/"PXA serial" hcitool info 00:04:3E:A4:23:2D hciconfig l2ping -s 64 -c 1 00:04:3E:A4:23:2D cat /proc/tty/driver/"PXA serial" done within 30 minutes the link failed with h4_recv: Unknown HCI packet.... The last status checks show: from hciconfig: hci0: Type: UART BD Address: 00:80:37:1F:09:24 ACL MTU: 672:8 SCO MTU: 64:0 UP RUNNING PSCAN ISCAN RX bytes:178052 acl:330 sco:0 events:8595 errors:40 TX bytes:55614 acl:330 sco:0 commands:2999 errors:0 Extra junk shows up on the (minicom)console. Due to the console TTY port? \uffff....\u0465\uffff..\u0465\uffff...\uffff.\uffff5)\uffffserinfo:1.0 driver revision: from cat/proc/tty/driver/"PXA serial" 0: uart:FFUART mmio:0x40100000 irq:15 tx:428414 rx:791 brk:2 RTS|CTS|DTR|DSR|CD|RI 1: uart:BTUART mmio:0x40200000 irq:14 tx:0 rx:0 2: uart:STUART mmio:0x40700000 irq:13 tx:0 rx:0 3: uart:HWUART mmio:0x41600000 irq:0 tx:55645 rx:178052 fe:1 brk:7 RTS|CTS|DTR Notice the Framing error and breaks. This follows the tty port, failures show up the same on BTUART with the same test. I am very suspicious of the errors on FFUART (and the garbage on the screen) I think the one PXA serial driver manages all these ports, so there may be some influence from one port to the next. The garbage message on the console seems to be text from serial_core.c David. |
From: Craig H. <cr...@hu...> - 2005-02-17 16:04:26
|
David, thanks for this detailed info. This looks like a new, slightly different failure mode -- I haven't previously seen framing errors, though it was a possibility I'd considered and was watching out for. When you say the BTUART fails the same way -- you mean it's also seeing framing errors? C On Feb 16, 2005, at 7:02 PM, David Farrell wrote: > Bluetooth still dies.... > > My Bluetooth notes: > > Gumstix Build 387 I run the following script > which > alternates between two bluetooth devices. Only > HCID is enable in /etc/defaults/bluetooth and the > baud rate is 230400. > > # hcitest > hcitool info 00:0C:41:E1:FC:A6 > hciconfig > l2ping -s 64 -c 1 00:0C:41:E1:FC:A6 > cat /proc/tty/driver/"PXA serial" > hcitool info 00:04:3E:A4:23:2D > hciconfig > l2ping -s 64 -c 1 00:04:3E:A4:23:2D > cat /proc/tty/driver/"PXA serial" > done > > within 30 minutes the link failed with > h4_recv: Unknown HCI packet.... > > The last status checks show: > from hciconfig: > hci0: Type: UART > BD Address: 00:80:37:1F:09:24 ACL MTU: 672:8 > SCO MTU: 64:0 > UP RUNNING PSCAN ISCAN > RX bytes:178052 acl:330 sco:0 events:8595 > errors:40 > > TX bytes:55614 acl:330 sco:0 commands:2999 > errors:0 > > Extra junk shows up on the (minicom)console. Due > to the console TTY port? > \uffff....\u0465\uffff..\u0465\uffff...\uffff.\uffff5)\uffffserinfo:1.0 > driver revision: > > from cat/proc/tty/driver/"PXA serial" > 0: uart:FFUART mmio:0x40100000 irq:15 tx:428414 > rx:791 brk:2 RTS|CTS|DTR|DSR|CD|RI > 1: uart:BTUART mmio:0x40200000 irq:14 tx:0 rx:0 > 2: uart:STUART mmio:0x40700000 irq:13 tx:0 rx:0 > 3: uart:HWUART mmio:0x41600000 irq:0 tx:55645 > rx:178052 fe:1 brk:7 RTS|CTS|DTR > > Notice the Framing error and breaks. This > follows the tty port, failures show up the same > on BTUART with the same test. > > I am very suspicious of the errors on FFUART (and > the garbage on the screen) I think the one PXA > serial driver manages all these ports, so there > may be some influence from one port to the next. > The garbage message on the console seems to be > text from serial_core.c > > David. > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: David F. <dav...@ya...> - 2005-02-17 16:33:07
|
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. 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?' Maybe GCC optimizing is messing up something? 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. I also used to get the "interrupt triggered but no.." printk occasionally but you seem to have commented it out now. David. --- Craig Hughes <cr...@hu...> wrote: > David, thanks for this detailed info. This > looks like a new, slightly > different failure mode -- I haven't previously > seen framing errors, > though it was a possibility I'd considered and > was watching out for. > > When you say the BTUART fails the same way -- > you mean it's also seeing > framing errors? > > C > |
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 |
From: David F. <dav...@ya...> - 2005-02-17 17:05:42
|
Craig, One other note. The hex codes that appear with some HCI timeout messages converted to ascii on some occasion also seem to be from serial_core.c string constant space. David. --- Craig Hughes <cr...@hu...> wrote: > 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 > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT > Products from real users. > Discover which products truly live up to the > hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: David F. <dav...@ya...> - 2005-02-18 01:46:26
|
Craig, --- Craig Hughes <cr...@hu...> wrote: > On Feb 17, 2005, at 8:32 AM, David Farrell > > 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. Actually I was running at 400MHZ. I have also seen occasionally the error with the bluetooth address = all zeros. It will definately happen if you put the GPIO redirect in the S30bluetooth start since the gpio modules is not loaded yet. I can fix it by /etc/init.d/S30bluetooth stop & start. One other item. I don't see in pxa.c where the HWUART is treated differently. If the flow control is in hardware, the software should not try to do it. I am looking for my intel pxa book to find out if maybe intel took care of this. Also at one point I thought you switched the fifo from 32 bytes to 64? I know I had better results doing this and reducing the receive_chars max_count loop to 64. David. |
From: David F. <dav...@ya...> - 2005-02-18 02:23:00
|
Craig, Ignore my fifo to 64 comment, looked it up in the pxa book, it is set to max trigger of 32. max_count to 64 (or lower) still stands. It looks like the HWUART has to be set to auto flow mode though. AFE and RTS bit in MCR and pxa.c should not touch RTS for this port. David. --- David Farrell <dav...@ya...> wrote: > > Craig, > > --- Craig Hughes <cr...@hu...> > wrote: > > On Feb 17, 2005, at 8:32 AM, David Farrell > > > > 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. > > Actually I was running at 400MHZ. > > I have also seen occasionally the error with > the > bluetooth address = all zeros. It will > definately > happen if you put the GPIO redirect in the > S30bluetooth start since the gpio modules is > not > loaded yet. I can fix it by > /etc/init.d/S30bluetooth stop & start. > > One other item. I don't see in pxa.c where the > HWUART is treated differently. If the flow > control is in hardware, the software should not > try to do it. I am looking for my intel pxa > book > to find out if maybe intel took care of this. > > Also at one point I thought you switched the > fifo > from 32 bytes to 64? I know I had better > results > doing this and reducing the receive_chars > max_count loop to 64. > > David. > > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT > Products from real users. > Discover which products truly live up to the > hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Craig H. <cr...@hu...> - 2005-02-18 03:05:57
|
The HWUART-specific stuff is the 4-line patch at the tail of sources/kernel-patches/000-gumstix-hwuart.patch: --- a/drivers/serial/pxa.c +++ a/drivers/serial/pxa.c @@ -323,6 +323,10 @@ mcr |= UART_MCR_OUT2; if (mctrl & TIOCM_LOOP) mcr |= UART_MCR_LOOP; + if (port->line == 3) // HWUART + { + mcr |= UART_MCR_AFE; + } mcr |= up->mcr; which turns on AFE for the HWUART. RTS can be set or not, depending on what the higher-level driver wants to do. If RTS is not set higher up, then the HWUART will respect the other end telling it to shut up if CTS drops. If RTS is set higher up, then the HWUART will manage it in hardware. Essentially this gives the software an override on dropping RTS if it really wants to. The reason I don't want to do full flow control in HW is that if you're doing hw RTS on the PXA255, then the PXA will only accept 1 more byte after it drops RTS, regardless of how much room is left in the FIFO: "When autoflow is enabled, the remote device is not allowed to send data unless the UART asserts nRTS low. If the UART deasserts nRTS while the remote device is sending data, the remote device is allowed to send one additional byte after nRTS is deasserted. An overflow could occur if the remote device violates this rule." from 17.4.3 of the PXA doc. Unfortunately, the ROK104001 can send *two* bytes after RTS drops -- the way I read the PXA doc, that 2nd byte might cause an overflow, even if there's room left in the FIFO -- I don't know how else to interpret the quoted doc above, given that the threshold for HW dropping RTS is when there's a minimum of 32 bytes left in the FIFO. So the only alternative is to basically use HW for CTS control, and software for RTS control, since in sw-RTS mode, it'll let you use the full FIFO. As for the all-zeros bug, this happens when you just use things as they are in the default image -- ie using btuart not hwuart -- the module acts more or less as though it's not there. I think the problem could be that the modules on those gumstix have the ECP firmware loaded on them not the HCI firmware -- I just need to dig up the docs which tell me how to ask the module that question. C On Feb 17, 2005, at 6:22 PM, David Farrell wrote: > Craig, > > Ignore my fifo to 64 comment, looked it up in > the pxa book, it is set to max trigger of 32. > max_count to 64 (or lower) still stands. > > It looks like the HWUART has to be set to auto > flow mode though. AFE and RTS bit in MCR and > pxa.c should not touch RTS for this port. > > David. > > --- David Farrell <dav...@ya...> wrote: > >> >> Craig, >> >> --- Craig Hughes <cr...@hu...> >> wrote: >>> On Feb 17, 2005, at 8:32 AM, David Farrell >>> >>> 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. >> >> Actually I was running at 400MHZ. >> >> I have also seen occasionally the error with >> the >> bluetooth address = all zeros. It will >> definately >> happen if you put the GPIO redirect in the >> S30bluetooth start since the gpio modules is >> not >> loaded yet. I can fix it by >> /etc/init.d/S30bluetooth stop & start. >> >> One other item. I don't see in pxa.c where the >> HWUART is treated differently. If the flow >> control is in hardware, the software should not >> try to do it. I am looking for my intel pxa >> book >> to find out if maybe intel took care of this. >> >> Also at one point I thought you switched the >> fifo >> from 32 bytes to 64? I know I had better >> results >> doing this and reducing the receive_chars >> max_count loop to 64. >> >> David. >> >> >> >> >> >> > ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT >> Products from real users. >> Discover which products truly live up to the >> hype. Start reading now. >> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> > https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: David F. <dav...@ya...> - 2005-02-18 04:24:01
|
Craig, I saw UART_MCR_AFE init about 10 minutes after my post, thanks for the informative reponse. All this doesn't explain how the buffer data is corrupted. And in the case of the console, how it recovers. Will a module with ECP firmware respond to a capablities query on its own? It might be a way to confirm your suspicions. That is have a PDA or external bluetooth device check the capabilities of any device it may find. David. |
From: Daniel M. <dan...@gm...> - 2005-02-18 04:51:57
|
I can get mine to respond to BT queries but not a capability type query. I have the BT address from my XP box. Dunno if that helps any. On Thu, 17 Feb 2005 20:23:52 -0800 (PST), David Farrell <dav...@ya...> wrote: > Craig, > I saw UART_MCR_AFE init about 10 minutes after my > post, thanks for the informative reponse. All > this doesn't explain how the buffer data is > corrupted. And in the case of the console, how it > recovers. > > Will a module with ECP firmware respond to > a capablities query on its own? It might be a way > to confirm your suspicions. That is have a PDA or > external bluetooth device check the capabilities > of any device it may find. > > David. > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > -- Daniel A. Morrigan He who says it cannot be done is interrupting the one doing it. |
From: Craig H. <cr...@hu...> - 2005-02-18 07:13:36
|
I've done a bunch more work on BT and have found a number of things, which I'll post about in the morning. Meantime, answers to your Qs below: On Feb 17, 2005, at 8:23 PM, David Farrell wrote: > Craig, > I saw UART_MCR_AFE init about 10 minutes after my > post, thanks for the informative reponse. All > this doesn't explain how the buffer data is > corrupted. And in the case of the console, how it > recovers. Not sure. I was able to reproduce the framing errors and breaks on BTUART, and kill the HCI link using BTUART. I can do this reliably -- though it doesn't always show framing errors when it dies. It'll die at pretty well any speed if I'm sending a lot of data from the gumstix to the host. The way I've been testing this repeatably is to establish a connection to the getty on /dev/rfcomm0 on the gumstix, then use sz/rz to blast binary data over the rfcomm link. I can transfer as much data as fast as I want from host to gumstix (up to 230400 on the rfcomm over a 921600 /dev/ttyS1 hci link) with no problems; however even at 38400 on the rfcomm link, with 57600 on the HCI layer, I very quickly kills the connection when I send data from gumstix to host. At any speed, with any combination of flow control options on /dev/ttyS1 and /dev/rfcomm0. I have not been able to kill the link even once when using HWUART though. I've transfered tens of megs of /dev/urandom by sz/rz in both directions over rfcomm0 at 230400 on top of ttyS3 at 921600. I'll do some more testing using different methods of blasting data over the link than just rfcomm tomorrow. But I can sustain transfers of this type around 65kB/s, so it's making pretty full use of the link bandwidth. I'll try bnep and other things in the morning. > Will a module with ECP firmware respond to > a capablities query on its own? It might be a way > to confirm your suspicions. That is have a PDA or > external bluetooth device check the capabilities > of any device it may find. The apparently-dead modules do show up when powered up as being visible from other bluetooth-browsing hosts. I haven't looked into these units as much as Gordon has at this point though. We are increasingly convinced that we have ECP units though -- turns out we don't seem to have much in the way of ECP docs though, since we thought we had HCI modules so those are the docs we have. I'll be in touch with Infineon to try and figure out best way to reflash them all. It looks like the "bad" modules are all the connex gumstix with BT on them, as well as the most recently manufactured lot of basix BTs. All the ones I've found seem to have the manufacture date 0436 on them, where the "good" ones have 0426 (the bottom-most number on the module, dropping off the trailing digit 2). I think the "batch number" which is the longer number just above that varies a lot, despite the fact the modules all came off the same reel... If you do have a bluetooth unit which reports a MAC of 00:00:00:00:00:00 and you purchased it recently, please could you help us out by reporting the two numbers: (i) Infineon ROK 104 001/2 R1B xxxxxxx FCC ID Q23104001 nnnn2 The x's and n's are what we're after, as you look at the shiny silver BT module on the 'stix. Thanks C |
From: David F. <dav...@ya...> - 2005-02-18 14:32:02
|
Craig, I can partially confirm the same thing. If I let the gumstix sit and do dothing except respond to remote queries, HCI will run several days. As soon as I start sending (l2ping) from the gumstix I get the error. In your case of successfully sending data from remote to gumstix, isn't there a handshake going on where the gumstix has to periodically transmit? And this happens in the stack of the gumstix, right? The console error I see seems also related to transmitting, I dont get any indication that gumstix linux received any garbage by complaining about bad commands etc. David. --- Craig Hughes <cr...@hu...> wrote: > I've done a bunch more work on BT and have > found a number of things, > which I'll post about in the morning. > Meantime, answers to your Qs > below: > > On Feb 17, 2005, at 8:23 PM, David Farrell > wrote: > > > Craig, > > I saw UART_MCR_AFE init about 10 minutes > after my > > post, thanks for the informative reponse. > All > > this doesn't explain how the buffer data is > > corrupted. And in the case of the console, > how it > > recovers. > > Not sure. I was able to reproduce the framing > errors and breaks on > BTUART, and kill the HCI link using BTUART. I > can do this reliably -- > though it doesn't always show framing errors > when it dies. It'll die > at pretty well any speed if I'm sending a lot > of data from the gumstix > to the host. The way I've been testing this > repeatably is to establish > a connection to the getty on /dev/rfcomm0 on > the gumstix, then use > sz/rz to blast binary data over the rfcomm > link. I can transfer as > much data as fast as I want from host to > gumstix (up to 230400 on the > rfcomm over a 921600 /dev/ttyS1 hci link) with > no problems; however > even at 38400 on the rfcomm link, with 57600 on > the HCI layer, I very > quickly kills the connection when I send data > from gumstix to host. At > any speed, with any combination of flow control > options on /dev/ttyS1 > and /dev/rfcomm0. > > I have not been able to kill the link even once > when using HWUART > though. I've transfered tens of megs of > /dev/urandom by sz/rz in both > directions over rfcomm0 at 230400 on top of > ttyS3 at 921600. I'll do > some more testing using different methods of > blasting data over the > link than just rfcomm tomorrow. But I can > sustain transfers of this > type around 65kB/s, so it's making pretty full > use of the link > bandwidth. I'll try bnep and other things in > the morning. > > > Will a module with ECP firmware respond to > > a capablities query on its own? It might be a > way > > to confirm your suspicions. That is have a > PDA or > > external bluetooth device check the > capabilities > > of any device it may find. > > The apparently-dead modules do show up when > powered up as being visible > from other bluetooth-browsing hosts. I haven't > looked into these units > as much as Gordon has at this point though. We > are increasingly > convinced that we have ECP units though -- > turns out we don't seem to > have much in the way of ECP docs though, since > we thought we had HCI > modules so those are the docs we have. I'll be > in touch with Infineon > to try and figure out best way to reflash them > all. It looks like the > "bad" modules are all the connex gumstix with > BT on them, as well as > the most recently manufactured lot of basix > BTs. All the ones I've > found seem to have the manufacture date 0436 on > them, where the "good" > ones have 0426 (the bottom-most number on the > module, dropping off the > trailing digit 2). I think the "batch number" > which is the longer > number just above that varies a lot, despite > the fact the modules all > came off the same reel... If you do have a > bluetooth unit which > reports a MAC of 00:00:00:00:00:00 and you > purchased it recently, > please could you help us out by reporting the > two numbers: > > (i) Infineon > ROK 104 001/2 R1B > xxxxxxx FCC ID Q23104001 > nnnn2 > > The x's and n's are what we're after, as you > look at the shiny silver > BT module on the 'stix. > > Thanks > > C > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT > Products from real users. > Discover which products truly live up to the > hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Craig H. <cr...@hu...> - 2005-02-18 17:49:00
|
On Feb 18, 2005, at 6:31 AM, David Farrell wrote: > Craig, > > I can partially confirm the same thing. If I > let the gumstix sit and do dothing except respond > to remote queries, HCI will run several days. > As soon as I start sending (l2ping) from the > gumstix I get the error. In your case of > successfully sending data from remote to gumstix, > isn't there a handshake going on where the > gumstix has to periodically transmit? And this > happens in the stack of the gumstix, right? Yes, the gumstix is sending back little ACKs now and then, but by far the bulk of the bits are flowing in the opposite direction. There's just a tiny trickle coming the other way, and this seems to work fine. > The console error I see seems also related to > transmitting, I dont get any indication that > gumstix linux received any garbage by complaining > about bad commands etc. Hmm, ok so possibility that for some reason wires are getting crossed between the tty and the hardware uart somewhere. I have to say though, I haven't seen the random bytes on console thing. C |
From: David F. <dav...@ya...> - 2005-02-18 18:01:08
|
It doesn't appear to me that the garbage I see on the console is bluetooth data, or any other data I would expect going through serial. The garbage was a string constant from another file! I would guess that the tx routine buffer empty pointer is getting corrupted, I get the 32 bytes or so of garbage, then the pointer gets fixed. There is another possibility. Maybe there is RF getting into the cpu? I have an external bt antenna and shielding foam available, I'll try these later. David. > > The console error I see seems also related to > > transmitting, I dont get any indication that > > gumstix linux received any garbage by > complaining > > about bad commands etc. > > Hmm, ok so possibility that for some reason > wires are getting crossed > between the tty and the hardware uart > somewhere. I have to say though, > I haven't seen the random bytes on console > thing. > > C > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT > Products from real users. > Discover which products truly live up to the > hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: David F. <dav...@ya...> - 2005-02-19 02:29:03
|
Ok, I tried the external antenna and Eccosorb shielding. My ping test seems to run longer but still fails. Not conclusive. This failure brought out h4_recv: Uknown HCI packet type of a bunch of characters. There hex and ascii is as follows: FF 1D 06 1B 6C 6D 5F 73 63 68 65 64 75 6C 65 72 3A 20 33 35 32 2F 36 30 30 20 28 35 38 25 29 00 . . . . l m _ s c h e d u l e r : 3 5 2 / 6 0 0 ( 5 8 % ) I am not sure what lm_scheduler is, I tried to grep the source and uncompressed binaries and I have not found reference to it. There is one reference in google in what looks like a map file. It is adjacent to hci_ stuff. David. Once again the console displays "\uffff....\u0465\uffff..\u0465\uffff... \uffff.\uffff5)\uffffserinfo:1.0 driver revision:" Where is has not business of displaying it, --- David Farrell <dav...@ya...> wrote: > It doesn't appear to me that the garbage I see > on the console is bluetooth data, or any other > data I would expect going through serial. The > garbage was a string constant from another > file! > I would guess that the tx routine buffer empty > pointer is getting corrupted, I get the 32 > bytes > or so of garbage, then the pointer gets fixed. > > There is another possibility. Maybe there is > RF > getting into the cpu? I have an external bt > antenna and shielding foam available, I'll try > these later. > > David. > > > > The console error I see seems also related > to > > > transmitting, I dont get any indication > that > > > gumstix linux received any garbage by > > complaining > > > about bad commands etc. > > > > Hmm, ok so possibility that for some reason > > wires are getting crossed > > between the tty and the hardware uart > > somewhere. I have to say though, > > I haven't seen the random bytes on console > > thing. > > > > C > > > > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product > Guide > > Read honest & candid reviews on hundreds of > IT > > Products from real users. > > Discover which products truly live up to the > > hype. Start reading now. > > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT > Products from real users. > Discover which products truly live up to the > hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Craig H. <cr...@hu...> - 2005-02-18 07:14:21
|
Yeah, if it is ECP, it powers up in "nothing's on but the radio" mode, so it won't report any capabilities, but you will be able to see its MAC on the airwaves. C On Feb 17, 2005, at 8:51 PM, Daniel Morrigan wrote: > I can get mine to respond to BT queries but not a capability type > query. I have the BT address from my XP box. |
From: Daniel M. <dan...@gm...> - 2005-02-18 13:27:14
|
Last line on the BT module reads 04362. On Thu, 17 Feb 2005 23:14:28 -0800, Craig Hughes <cr...@hu...> wrote: > Yeah, if it is ECP, it powers up in "nothing's on but the radio" mode, > so it won't report any capabilities, but you will be able to see its > MAC on the airwaves. > > C > > On Feb 17, 2005, at 8:51 PM, Daniel Morrigan wrote: > > > I can get mine to respond to BT queries but not a capability type > > query. I have the BT address from my XP box. > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > -- Daniel A. Morrigan He who says it cannot be done is interrupting the one doing it. |