Forums

The "CC2540EM Master" and "CC2540EM Slave" configurations of the HostTestRelease project are made for use with a physical UART and not USB. The port settings are 57600 baud rate/N/8/1, with hardware (RTS/CTS) flow control.

Thanks for that, I actually sorted it out myself in the end. My board is a custom board that supports both USB and UART Hardware options. I have both going now, turns out all I had to to (which I missed) was just to select the CC2540EM workspace instead of the USB one. HCI over uart is working well with BTool.

Thanks,

Ed.

Hi Willis,

Hopefully you don't mind me piggybacking off this threa.  We've have recently designed a custom target OMAP3-based (OMAP3525) board on which we added the CC2540 chip for Bluetooth functionality.  The CC2540 is wired to the OMAP3 via UART0 (we'll be using serial to communicate with the CC2540).  I have been searching all over the web without luck for the source code to the CC2540 with which we can use on the Montavista Linux (2.6.29-6) or any open source OMAP3 Linux (GIT) currently running on our OMAP3-custom target.  Does you know where I can find the driver source code?  Sorry, I'm a newbie with BT comm; I have configured (PINMUX) the OMAP3 UART0 to "talk" to the CC2540.  If you can point me in the right direction to where I can find the driver code (if any), I would appreciate it.  Thanks!

Regards,

Andy 

Hi Andy,

if you install the BLE stack, the project in

C:\Texas Instruments\BLE-CC2540-1.1a\Projects\ble\HostTestApp\CC2540

Is exactly what are you searching for. Try to read the Internet about HCI commands. It should be also useful to you tu read some literature about BLE concepts like Advertising, Connection Events... which you can also find in the "Bluetooth Low Energy Software developer's guide" in order to identify which HCI commands will you need.

Good luck.

Hi Kaz,

Thanks a lot for your help and the links of resources you provided to me.  At this time, I haven't gone through all of them yet.  Yes, based on your response, we would want to use the BLE stack using the UART interface as the physical comm medium between our OMAP3-based target host and the CC2540 device.  We are currently checking out the custom hardware we just built; at a first step, I need to verify the CC2540 is powering up and running fine; what would you recommend doing just to see if I can talk to the CC2540.  Should I use the bluez utility hcitool to try to communicate with it?  I downloaded the BLE-CC2540-1.1a source code but the only utility available is BTool, which runs on Windows only.  Sorry for all these newbie questions as I'm a little overwhelmed now.  Thank you.

Regards,

Andy

Sorry for the delay in answering. I'm from Catalonia and perhaps we have some time differences. In fact, these are the "hciconfig -h" and "hcitool" outputs of my Linux Mint 11 system, kernel. 2.6.38. I've not slept a lot of hours but I think I've separated some classical BT commands from some BLE ones with the "..." symbol. The BTool output is useful, since would match the HCI command reference I gave you in other post.

kaz@?? ~/Baixades/bluez-4.95 $ hciconfig -h

Usage:

hciconfig [-a] hciX [command ...]

Commands:

up                 Open and initialize HCI device

down               Close HCI device

reset               Reset HCI device

iscan               Enable Inquiry scan

...

So perhaps you'll be able to do most of your work in your development machine, which I guess will be different of the OMAP one. Please have in mind the BLE work in Linux seems to not be completed. Please also have into account I'm just trying to help you, since I've not tested this commands or even if you can test CC2540 with this info, so it would also be nice by your side to attach the CC2540 via UART, test them, and post your success here, if any :). Check also this pdf.

http://www.jeremythompson.uklinux.net/RH8-0/bluezhowto.pdf

Good luck.

It seems the following link could also be useful to you, Andy:

base operations required to bring up UART Bluetooth

Look in the "start up the system" section.

Hi Kaz,

Thanks a lot for your help and quick responses.  Just to refresh, we have the CC2540 hooked up to our OMAP3525-based target board via the UART interface (/dev/ttyS1); the UART interface is the only physical medium they are talking to each other.  The tx/rx/cts/rts lines are hooked up between them.  So we recently got our target board from FAB and I'm in the process of just trying to get our OMAP3525 to talk to the CC2540 over /dev/ttyS1.  The PINMUX on the OMAP3525 are all configured correctly.  We're running Montavista Linux 2.6.29-6 on our OMAP3525.  I downloaded the latest bluez source and tried to cross-build for our OMAP3525 board but ran into problems (DBUS library not found, etc) so I gave up for the moment.  However, I was able to find the hciattach/hciconfig/hcitool/etc binaries from the latest Angstrom distribution which contains the full rootfs for the OMAP3 processor.  I uploaded those binaries and here's what I've tried so far but got a failure

# hciattach /dev/ttyS1 texas 115200 flow
Initialization timed out.  

I'm going to have our hardware guys make sure the tx/rx/cts/rts are hooked up correctly between the OMAP3525 /dev/ttyS1 and the CC2540.

If I can get past the initialization stage, I may be able to do some more stuff just to verify that the CC2540 is working electrically.

So I have another question for you: since the UART is the only physical medium (as opposed to USB or SPI) between the OMAP3525 and the CC2540, the bandwidth of any BT application running our our OMAP3525 target board is confined to the highest speed of the UART (/dev/ttyS0), is that correct?  In which case, it's 115200bps.  Does CC2540 support hi-speed UART (1-2Mbps)?

Regards,

Andy  

Hi Andy,

please remember from now on I'm only trying to answer things I have not tested. In fact, right now perhaps I'm more interested in what you are doing than you in whatever I can try to figure out to help you.

I strongly recommend you to take a look in hal_uart.h since it will provide you more information at once than the one I can give it to you :) This is a fragment of hal_uart.h, I think it can give you some clues about what you are asking for (look comments).

/* UART Ports */

/*

Good luck in your tests and don't forget to post your progress if you success.

Hi Kaz,

I was busy working on something else for the past 2 weeks and now I'm back on this.  So to refresh, we have the CC2540 hooked up to a OMAP3525 on our custom target board runing Linux 2.6.29-6 via the serial interface (/dev/ttyS1).  I installed some hci tool executables (hmiattach, hmitool, etc) on our OMAP3 board in order to try to initailize / attach to the CC2540 but am having no luck.  I use this link (http://www.spinics.net/lists/linux-bluetooth/msg09713.html) that you had me referred and issue the following command to establish communication with the CC2540 over serial:

hciattach /dev/ttyS1 texas 57600 flow

It keeps timing out and the initialization failed.  I tried it with 115200, 38400, 9600 and with the noflow option and still no luck.  So I have a few question that may helped us get the ball rolling to get our CC2540 up and running:

1) Does the CC2540 come with firmware already installed and it should just come up running?  Or do you have to flash/program firmware on it to get the 8501 MCU running?  How would you do so on a target board like ours?

2) If it does have software running when power is applied, what is the default speed on the serial interface (57600, 115200, etc)?  Besides having the 32MHz crystal hooked up and power applied to it, is there something we have to do to initialize it or can we just use hciattach to try to establish communication.  Is there any debugging log messages that come from the 8501 MCU on it we can look at to make sure it's powering up?

I'm not sure if we have our TX/RX/CTS/RTS lines/pins on this chip hooked up correctly with respect to the lines of the OMAP3525; the pins on the CC2540 are not labeled explicitly with its specific functions with respect to TX/RX/CTS/RTS; I have recommended to our hardware engineers to look at the schematic of the BLE CC2540 Mini Dev Kit to see how it's hooked up there.

I'm ready to recommend to our hardware engineers switch over to use the CSR BC6 ROM chip instead due to the lack of software driver/resources for the CC2540.  We were hoping just to use the CC2540 as is, power it up and have it running with the Linux software/driver support for it without any hassle.  This only software resource I can find is on this forum and it's really to a standalone development system (IAR) that comes with the Mini Dev Kit; I can't find any references to it being run in an embedded Linux system.  The CSR BlueCore chips (BC6 ROM included) have Linux software/driver support so we're seriously considering it.  Can any TI expert/employee help answer these questions also, point us to any Linux software/driver resources we can use?

We're going to spend until the end of this week to try to get the CC2540 going.  At this point, we're just trying to establish serial communication between the OMAP3 and CC2540.  I think we will need a lot more software port / development from the available IAR development code on the OMAP to get this working fully.  Please advise.  Thank you.

Regards, Andy

Hi,

1) I think the first CC2540 were not shipped with firmware. Perhaps it is your case. Try connecting with BTool to check. If not, I think you should flash HostTestReleaseFirmware to it. But I don't remember quite well.

2) If I don't remember wrong, 57600. Try Btool for this too.

I used a BC4  chip and it had memory issues when working with Extended Inquiry frames. I do not know if BC6 implement BLE since on CSR website, the only ones that state to do it are CSR uEnergy and CSR8000, which includes HD audio.

I am not aware of your company issues, I'm not a TI folk. Just trying to help. Indeed, I also think the learning curve is somehow difficult at the beggining due to the lack of examples and the strategy to go for similar examples in the ZigBee forum is not always valid since there is people that directly ignores what is ZigBee (and even IAR) at the beggining.

Thank for you quick response.

OK, some today we received the Mini Dev Kit and also the CC Debugger.  After one white wire, we were able to hook up the CC Debugger 10-pin BDM adapter to our OMAP3-custom board and was able to "communicate" withe CC2540 on our target board.  So here's where I'm lost; which hex file should I use to program the CC2540 on our target board (remember, the CC2540 talks to the ARM processor on the board via serial only (not USB to serial, just straight serial)).  I downloaded the BLE stack code and there are 5 hex images:

cc2540_ble1.1_keyfob_SimpleBLEPeripheral.hex

cc2540_ble1.1_USBdongle_HostTestRelease_Master.hex

cc2540_ble1.1_SmartRF_HostTestRelease_Master.hex

cc2540_ble1.1_SmartRF_SimpleBLECentral.hex

cc2540_ble1.1_SmartRF_SimpleBLEPeripheral.hex

The first 2 are probably not valid for our board (they are for the fob and USB dongle that come with the dev kit).  I tried to program the SmartRF_HostTestRelease_Master.hex but it said it's too large to fit on the cc2540 flash.  I was able to program SmartRF_SimpleBLECentral.hex and SmartRF_SimpleBLEPeripheral.hex but I'm not sure if those will have the serial interface enabled to talk to the ARM processor.

So I played around with the USB dongle in the dev kit; I programmed it with USBdongle_HostTestRelease_Master.hex and was able to use BTool to communicate with it via the serial (over USB).  This is my goal for our custom board, to use hciattach (or other hci tool) to communicate with the CC2540 across the straight serial interface.

So my question (anyone (besides Kaz, please help, including all the wonder TI employees):

1) What firmware file out of the 5 hex files included in BLE1.1a should I use for our custom board? Remember, we're using straight serial from the CC2540 to the ARM, not USB to serial

2) Are RTS/CTS necessary for hciattach to work? Our hardware engineer thinks we don't have it hooked up correctly

3) If we get hciattach to work eventually, do we need to develop software on the CC2540 or does TI have software/application we can program on the CC2540 that does all the standard BT2.1 profiles?   Our goal is to use the CC2540 as is on our custom OMAP3525 board, hopefully utilizing the Headset profile and PAN profile.  Hopefully, there will be Linux support for this in which we don't have to do any software development.  Thus far, from what I'm seeing and reading through this forum, it seems like we have to order the IAR software development system to do development for the CC2540, which we don't want.

Thanks!

Regards,

Andy

The "CC2540EM Master" and "CC2540EM Slave" configurations of the HostTestRelease project use a physical UART and not USB. The port settings are 57600 baud rate/N/8/1, with hardware (RTS/CTS) control. Enter hosttestrelease and choose cc2540em. But if you want to work with high dfintion headset audio you have to go for clasical bluetooth not cc2540, since it is not a dual mode chip.

I was also testing out UART communication against CC2540 usb dongle from Linux (Ubuntu).

Noticed this thread while I was searching for CC2540 running as Network processor mode (HostTestRelease firmware) and making it work with Linux over serial comm.

I took the Tx/Rx dump from the BTTool and wrote a small test python script that runs on Linux. (requires pyserial pkg)

It works, and I think it'd be trivial for other MCU's or scripts/applications to achieve the same thing using serial communication.

#!/usr/bin/env python

import sys
# sys.path.append('/nas/dev/c/uC/8051/projects/cc2540/scripts/pyserial-2.6')
# so our local copy always takes precedence
sys.path.insert(0,'/nas/dev/c/uC/8051/projects/cc2540/scripts/pyserial-2.6')

import re
import time
import serial

MSGS = {
  'gap_device_init' : [0x01,0x00,0xFE,0x26,0x08,0x05,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x00,0x00,0x00],
  'gap_getparam'    : [0x01,0x31,0xFE,0x01,0x15]
};

def printhex(tag, b):
  sys.stdout.write("%s: "%tag);
  [sys.stdout.write("%s "% hex(b[i]) ) for i in range(len(b))]
  sys.stdout.write("\n");

def readmsg(ser):
  b = bytearray();
  b += bytearray(ser.read(1));
  b += bytearray(ser.read(1));
  b += bytearray(ser.read(1));
  datalen = int(b[2]); # 3rd byte is the data length
  for i in range(datalen):
    b += bytearray(ser.read(1));
  printhex("RX", b);

def sendmsg(ser, msgid):
  msg = MSGS[msgid];
  b = bytearray(msg);
  printhex("%s TX" % msgid, b);
  # send HCI command over serial (UART)
  ser.write(b);

ser = serial.Serial(port='/dev/ttyACM0', baudrate=57600, timeout=None)
sendmsg(ser, 'gap_device_init');
readmsg(ser)

sendmsg(ser, 'gap_getparam');
readmsg(ser)

ser.flush()
ser.close()

The usb dongle responds my HCI commands with the same RX bytes I saw on BTTool. Hope this helps folks out there trying to get CC2540 work with external host controllers, linux OS, etc..

$ ./testhci.py
gap_device_init TX: 0x1 0x0 0xfe 0x26 0x8 0x5 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x0 0x0
RX: 0x4 0xff 0x6 0x7f 0x6 0x0 0x0 0xfe 0x0
gap_getparam TX: 0x1 0x31 0xfe 0x1 0x15
RX: 0x4 0xff 0x2c 0x0 0x6 0x0 0xff 0xff 0xff 0xff 0xff 0xff 0x1b 0x0 0x4 0x34 0xb4 0x9c 0xd4 0x5e 0x2a 0x72 0xb9 0xf8 0xa4 0x70 0x41 0xf8 0xa7 0x0 0x1 0x8e 0xea 0xeb 0x65 0x85 0xd 0xfb 0xa3 0x70 0x41 0x28 0x67 0xa9 0x9d 0xb1 0xbe

This is great!

Perhaps you can add this to this wiki entry:

http://e2e.ti.com/support/low_power_rf/f/538/t/143102.aspx

Thanks a lot!