On Thu, Sep 1, 2011 at 10:33 PM, parth shah <parthmshah2...@gmail.com> wrote:
> Hello Friends,
>
> I commented out below lines in hciattach.c and output is something like
> below.
>
> [ATH_INFO] (external/bluetooth/bluez/tools/hciattach.c) <init_uart>: Serial
> port is opened
> [ATH_INFO] (external/bluetooth/bluez/tools/hciattach.c) <init_uart>: Port
> settings is gotten
> [ATH_INFO] (external/bluetooth/bluez/tools/hciattach.c) <init_uart>: Port
> settings is set
> [ATH_INFO] (external/bluetooth/bluez/tools/hciattach.c) <init_uart>: Initial
> baudrate is set
> [ATH_INFO] (external/bluetooth/bluez/tools/hciattach.c) <init_uart>: Break
> is sent
> [ATH_INFO] (external/bluetooth/bluez/tools/hciattach.c) <init_uart>: Actual
> baud rate is set
> [ATH_INFO] (external/bluetooth/bluez/tools/hciattach.c) <init_uart>: Line
> discipline is set
> [ATH_INFO] (external/bluetooth/bluez/tools/hciattach.c) <init_uart>: Ioctl
> device is set
> [ATH_INFO] (external/bluetooth/bluez/tools/hciattach.c) <init_uart>: u->post
> is loaded
>
> Commented out lines given below:
>
> if( u->init && u->init(fd, u, &ti)<0)
>        return -1;

Those lines are very much required. If you happen to use "texas" (not
texasalt) as the manufacturer option, the flow would be into
texas_init() function in the hciattach_ti.c - which you might want to
debug.

This function reads the firmware version from the chip - forms the
firmware file name, expects it to be in /lib/firmware/ parses it (it
in not a .bin like fw, but a script) - and downloads over /dev/tty*
interface.

There is some post processing in texas_post() also - but depends on
various configuration of firmware.
So we need to get the chip ID/firmware version response - to be sure
that the communication between the host and the WL chip is fine.


> So the execution flow in hciattach.c is not going into hciattach_ti.c
>
> Any idea what if( u->init && u->init(fd, u, &ti)<0) does and how to solve
> this issue?
>
> Thanks,
> Parth
>
>
>
> On Wed, Aug 31, 2011 at 7:57 PM, Pavan Savoy <pavan.sa...@gmail.com> wrote:
>>
>> On Wed, Aug 31, 2011 at 9:46 PM, parth shah <parthmshah2...@gmail.com>
>> wrote:
>> > Hi Gil,
>> >
>> > Thanks for that response. Just before few minutes i tried that and i was
>> > surprised to know that even  after changing the baudrate i'm getting
>> > 8.06uS
>> > pulse width.
>> >
>> > which means even i'm trying hciattach /dev/ttymxc1 texas 9600 noflow but
>> > the
>> > UART packet is going out at baudrate of 115200(8.06uS).
>>
>> The initial baud-rate is supposed to be 115200, If the chip supports
>> something else,
>> then hciattach has an option to have a different initial baud-rate "-s".
>>
>> In this case the initial speed is supposed to be 115200 though...
>> That's why you see the first command - which is read chip version goes
>> out at 115200.
>>
>> >
>> > How can i make a change in this?
>> >
>> > Also how can i change settings of UART means how can i use different
>> > UART
>> > then what i'm using for BT? Where to make change for that?
>> >
>> > Other Observation:
>> > Is there any power up sequence i have to take care?
>> >
>> > Our Power up sequence says  " BT_EN should go high for 10ms then make it
>> > low
>> > and time between BT_EN high and HCI_RTS should be 100 ms".
>>
>> I suppose it should be high for it to be powered - and go low only
>> when it to be powered off.
>> The RTS is for it to be able to sample Rx - this might not matter in
>> this case - Since there would be some significant delay between the
>> BT_EN going high and you send the chip version read via hciattach.
>>
>> > How can i provide such small delays from U-boot?
>> >
>> > Thanks and Regards,
>> > Parth
>> >
>> >
>> >
>> > On Wed, Aug 31, 2011 at 7:27 PM, Gil Zhaiek <gilzha...@gmail.com> wrote:
>> >>
>> >> One more thing - try a different baud rate (using a different bts
>> >> file).
>> >> Try 115200 bts - because you see that this works.
>> >>
>> >> Gil
>> >>
>> >> On Aug 30, 11:42 pm, parth shah <parthmshah2...@gmail.com> wrote:
>> >> > Hi Pavan,
>> >> >
>> >> > We are using imx515 platform from freescale.
>> >> >
>> >> > We have pulled up connected with BT_EN with 1.8V. and BT_EN is
>> >> > connected
>> >> > to
>> >> > GPIO.
>> >> >
>> >> > We are making sure that before any BT activity BT_EN should go high.
>> >> >
>> >> > Is there any other reason?
>> >> >
>> >> > Thanks,
>> >> > Parth
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On Tue, Aug 30, 2011 at 7:31 PM, Pavan Savoy <pavan.sa...@gmail.com>
>> >> > wrote:
>> >> > > On Tue, Aug 30, 2011 at 9:26 PM, parth shah
>> >> > > <parthmshah2...@gmail.com>
>> >> > > wrote:
>> >> > > > Hello Friends,
>> >> >
>> >> > > > I'm using WL1271 WIFI/BT module.
>> >> >
>> >> > > > I'm getting below output while running hciattach /dev/ttymxc1
>> >> > > > texas
>> >> > > 30000000
>> >> >
>> >> > > > [ATH_INFO] (external/bluetooth/bluez/tools/hciattach.c)
>> >> > > > <init_uart>:
>> >> > > Serial
>> >> > > > port is opened
>> >> > > > [ATH_INFO] (external/bluetooth/bluez/tools/hciattach.c)
>> >> > > > <init_uart>:
>> >> > > > Port
>> >> > > > settings is gotten
>> >> > > > [ATH_INFO] (external/bluetooth/bluez/tools/hciattach.c)
>> >> > > > <init_uart>:
>> >> > > > Port
>> >> > > > settings is set
>> >> > > > [ATH_INFO] (external/bluetooth/bluez/tools/hciattach.c)
>> >> > > > <init_uart>:
>> >> > > Initial
>> >> > > > baud rate is set
>> >> > > > [ATH_INFO] (external/bluetooth/bluez/tools/hciattach.c)
>> >> > > > <init_uart>:
>> >> > > Break
>> >> > > > is sent
>> >> > > > Initialization timed out.
>> >> >
>> >> > > What platform is this ?
>> >> > > Have you powered the BT chip ? These chips tend to have a
>> >> > > BT_EN/NShutDown gpio which needs to be pulled up for it to be
>> >> > > powered
>> >> > > on.
>> >> >
>> >> > > > I have Firmware loaded at /lib/firmware/TIInit.... and BT_EN is
>> >> > > > high
>> >> > > before
>> >> > > > running hciattach
>> >> >
>> >> > > > Any idea why does it happen? Thanks in advance.
>> >> >
>> >> > > > Thanks,
>> >> > > > Parth
>> >> >
>> >> > > > --
>> >> > > > unsubscribe: android-kernel+unsubscr...@googlegroups.com
>> >> > > > website:http://groups.google.com/group/android-kernel
>> >> >
>> >> > > --
>> >> > > --Pavan Savoy
>> >> >
>> >> > > --
>> >> > > unsubscribe: android-kernel+unsubscr...@googlegroups.com
>> >> > > website:http://groups.google.com/group/android-kernel
>> >>
>> >> --
>> >> unsubscribe: android-kernel+unsubscr...@googlegroups.com
>> >> website: http://groups.google.com/group/android-kernel
>> >
>> > --
>> > unsubscribe: android-kernel+unsubscr...@googlegroups.com
>> > website: http://groups.google.com/group/android-kernel
>>
>>
>>
>> --
>> --Pavan Savoy
>>
>> --
>> unsubscribe: android-kernel+unsubscr...@googlegroups.com
>> website: http://groups.google.com/group/android-kernel
>
> --
> unsubscribe: android-kernel+unsubscr...@googlegroups.com
> website: http://groups.google.com/group/android-kernel



-- 
--Pavan Savoy

-- 
unsubscribe: android-kernel+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-kernel

Reply via email to