Create Account
Search
You are here: TDG Forum  >>  Texas Instruments SOMs and Development Kits  >>  OMAP35x, DM3730, AM3703 Torpedo SOM Development Kit  >>  how to change bluetooth module in kernel

Technical Discussion Group Forum

This forum is provided for user discussion. While Beacon EmbeddedWorks support staff and engineers participate, Beacon EmbeddedWorks does not guarantee the accuracy of all information within in the Technical Discussion Group (TDG).

The "Articles" forums provide brief Articles written by Beacon EmbeddedWorks engineers that address the most frequently asked technical questions.

To receive email notifications when updates are posted for a Beacon EmbeddedWorks product download, please subscribe to the TDG Forum of interest.

TDG Forum

PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 13 Apr 2015 08:03 AM by  Adam Ford
how to change bluetooth module in kernel
 10 Replies
Sort:
You are not authorized to post a reply.
Author Messages
mvly
Basic Member
Basic Member
Posts:104


--
06 Apr 2015 02:14 PM

    I am using a different bluetooth module for the NON-wireless SOM DM3730 module. Looking at the pin outs, it looks like I can use use the same UARTs to communicate with my new module which is the PAN1327 ANT+ bluetooth module. I don't plan to use the ANT+ for now.

     

    In the kernel after ./build.sh -K, I enabled HCI (H4 UART) to allow it to control the PAN1327.

     

    Here is what I think I need to do next but I have no idea where to start

    1) remove the wifi-bluetooth support from the driver for the TI wifi+bt module

    2) connect the UARTs of the old TI wifi+bt to this new driver

     

    1) is easy enough to do. But how do I do 2)? 

     

    Also is there anything else I am missing to get it to work?

     

    Thanks!
    Adam Ford
    Advanced Member
    Advanced Member
    Posts:794


    --
    07 Apr 2015 08:10 AM
    The hardware abstraction is a little confusing at times, but the TI driver references the HCI_UART which itself is abstracted to point to the hardware. If you're trying to write a driver yourself, I would examine how the original driver works and modify the functions as needed. Much (but not all) of the source located in kernel/drivers/bluetooth/btwilink.c. There are other drivers in the kernel/drivers/bluetooth directory as well, so you should be able to see how different vendors implement it.

    Since adapting a new driver is beyond our normal online support, I would highly recommend a services contract. We have some great software developers who would be very happy and eager to help you if you'd be interested in a services contract. They could do as little or as much work as you need. If you'd like me to have a sales person contact you.

    adam
    mvly
    Basic Member
    Basic Member
    Posts:104


    --
    07 Apr 2015 11:29 AM

    Adam,

    Thanks for the reply. As of now, it would be too costly both in time and money to get a service contract. The overhead required to make it happen is impractical. What you recommended was my next plan of attack. I'll see where I can go from here. Again thanks for the help.
    Adam Ford
    Advanced Member
    Advanced Member
    Posts:794


    --
    07 Apr 2015 02:03 PM
    Have to evaluated our Torpedo + Wireless module? It has Bluetooth capabilities already in it along with GPS and WiFi. It's FCC approved, Linux and Android BSP's have been tested to work with it. Is there something about that particular Bluetooth module accomplishes that our T+W does not? Because it's already FCC approved, you may save yourself some development costs and time there as well.

    If you want to develop a driver on your own to use a different Bluetooth module, you may want examine the other bluetooth drivers that are there to see if there is a common method of enabling the Bluetooth drivers. BlueZ is the Bluetooth stack. In it, there are some serial port settings, etc. You may need to patch that in addition to writing your own drivers.

    If you're struggling to get a bluetooth driver written, you might look around to see if someone has written a driver for a USB->bluetooth dongle already. IF you have our base board, it has some USB host ports that you could use to evaluation. If you have a USB->Bluetooth dongle, and you can find driver source code for it, it might be an easier solution. It's not officially supported by Logic, so we can't help you without a support contract, but the Open Source community has a lot of resources out there.

    adam





    mvly
    Basic Member
    Basic Member
    Posts:104


    --
    07 Apr 2015 04:40 PM

    It looks like btwlink is using the same HCI serial commands to control the bluetooth. My Bluetooth module should support the normal Bluetooth commands. However it does not look like the bluetooth UARTs are routed out. Maybe it is detecting the NON wireless version of the torpedo. Is there a way to force it boot with the Wireless version?
    mvly
    Basic Member
    Basic Member
    Posts:104


    --
    07 Apr 2015 05:08 PM

    Also FYI, I cannot seem to get the bluetooth to work on the Eval board using DM3730 + Wireless chip. The bluetooth would turn on, but it did not find any bluetooth device nor was it discoverable to any other bluetooth devices. I used my macbook and my android phone to try to detect it. Could it be I need a bluetooth antenna attached to it?

     

    THanks
    mvly
    Basic Member
    Basic Member
    Posts:104


    --
    07 Apr 2015 05:19 PM

    nvm. it turns out all I needed to do was turn off and turn on the bluetooth and everything started to work again. I also did use a RF connector to J7 just to make sure I have more range
    Adam Ford
    Advanced Member
    Advanced Member
    Posts:794


    --
    08 Apr 2015 06:57 AM
    The Bluetooth and the 2.4GHz Wifi share the same antenna. I would suggest using the antenna.

    As far forcing the module to recognize the non-wireless module as a Torpedo Wireless, I will have to investigate that. I beleive it's in u-boot and passed, but I'll dig around. I haven't had anyone ask that question before. :-)

    adam
    Adam Ford
    Advanced Member
    Advanced Member
    Posts:794


    --
    08 Apr 2015 07:14 AM
    In U-boot, there is a function called logic_identify(). It is located in the board/ti/logic/logic.c file.

    I think you should be able to force the value there, I haven't tried it, but that is my understanding. I believe u-boot passes the parameters to the Linux kernel, and I think Android uses the same mechanism. If that doesn't work, let me know and I can ask some of my colleagues.

    adam

    mvly
    Basic Member
    Basic Member
    Posts:104


    --
    08 Apr 2015 12:34 PM

    Thanks for the recommendation. It looks like I can only switch between the the OMAP7 (DM37xx) or the OMAP5. Or between the Torpedo module or the SOM-LV

    There isn't an option between the wifi or non-wifi version. Could the wifi vs non-wifi settings be set somewhere else?

     

    I use to get UART pulses on UART2 (UARTC) when the Torpedo +wifiBT is present, but no UART pulses on the regular Torpedo version. Any ideas on why this is the case?
    Adam Ford
    Advanced Member
    Advanced Member
    Posts:794


    --
    13 Apr 2015 08:03 AM
    I dug into the identification stuff, and it turns out the Torpedo + WiFi uses a newer ID style than the SOM-LV and the base Torpedo.

    The two kernel files that identify the board are:
    arch/arm/mach-omap2/board-omap3logic-old-productid.c
    arch/arm/mach-omap2/board-omap3logic-new-productid.c

    I'm putting in a question to one of the developers here to see if he has a simple solution to enable the UART on the Torpedo without wireless.

    adam
    You are not authorized to post a reply.

    Forums Texas Instruments SOMs and Development Kits OMAP35x, DM3730, AM3703 Torpedo SOM Development Kit