CC2540 HCI over UART0 using CC2540EB build.

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!

Hello,

I'm trying to make the CC2540 Dongle communicate via USART with a Stellaris MCU, and it doesn't work for now.

Is hardware (RTS/CTS) flow control mandatory? I only use TX/RX. Sorry if this is a newbie question, I never used RTS/CTS before.

Thank you!

Hi Fabien,

I've been attempting to use the CC2540 UART without CTS and RTS, so I'm in a similar situation.  I found that modifications to HAL code are needed.

On the CC2540, are you using the UART for your own data, or are you using the network processor configuration where the UART carries the HCI protocol?
 

If you're using the port for your own data, you must create a halUARTCfg_t structure before you call HalUARTOpen().  Disable flow control with the following code:

  halUARTCfg_t uartConfig;
  uartConfig.flowControl = FALSE;

When using TI's BLE stack in the network processor configuration, it appears that HalUARTOpen() is called from within the stack.  In the network processor configuration,  The halUARTCfg_t reference passed to HalUARTOpen() determines whether flow control is enabled or disabled. 

Stepping through the code, it is possible to modify the halUARTCfg_t settings before the HAL code actually configures the port.  If you're using TI's V1.2 stack for BLE, you can modify HalUARTOpenDMA() in _hal_uart_dma.c to disable CTS/RTS.

Add the following line to the beginning of the open function:
static void HalUARTOpenDMA(halUARTCfg_t *config)
{
  config->flowControl = HAL_UART_FLOW_OFF;

Note that if you need to change the baud rate, this is a good place to add that code too.

I noticed that when the DMA version of the HAL UART driver is used, the RTS line is controlled in software.  Comment out the following lines to prevent the toggle of RTS.
 
In HalUARTReadDMA(), comment out the following line:
//  PxOUT &= ~HAL_UART_Px_RTS;  // Re-enable the flow on any read.

In HalUARTPollDMA(), comment out the following line:
//    PxOUT |= HAL_UART_Px_RTS;

There may be other steps to configure the CTS and RTS port pins back to general I/O, but I haven't gotten that far.

Hope this helps!

Hi Chris,

Thank you for answering.
I am using HostTestRelease, which uses the network processor configuration, and, I think, USART 0 on pins P0_2 and P0_3.

I added, as you said, config->flowControl = HAL_UART_FLOW_OFF in HalUARTOpenDMA, but it doesn't change anything. I commented PxOUT &= ~HAL_UART_Px_RTS and PxOUT |= HAL_UART_Px_RTS but I think this is not necessary, as this is only an output (the system dosn't block waiting for acknowledgment).

On the Stellaris side (MCU communicating with the CC2540 dongle), I configured USART as following:

ROM_UARTConfigSetExpClk(UART4_BASE, ROM_SysCtlClockGet(), 57600,
(UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE |
UART_CONFIG_PAR_NONE));

On the MCU side, USART is working properly (I wired RX and TX just to try sending and receiving, and it works properly).

Then I wired the MCU to the USB dongle, and send a device init message as follow:

Ok, this is WORKING!

ROM_UARTCharPutNonBlocking was a huge mistake. I obviously need to use a blocking function.

config->flowControl = HAL_UART_FLOW_OFF is also needed, as Chris said.

Thank you!

Hi Fabien,

I'm glad you got it working.

Note that if you want to increase or decrease baud rates, you can add the line

config->baudRate = HAL_UART_BR_115200
in the same location where you modified the flow control.

With regards to commenting out the PxOUT assignment that control RTS, if you are not needing that pin for something else, then you are correct that leaving it enabled does not affect the functionality.  You would only need to comment that out if you want to reassign that port pin for a different I/O function unrelated to the UART.

Enjoy the weekend!

Chris Norris

Hi,

Chris, thank you for your answer.

I have another question about RTS. I am studying the code but I don't know enough about DMA and the CC2540 to find an anser for now.

Is PxOUT line only a hardware control, or is it also used for higher level information?

I explain myself:

On the MCU side, I receive  messages from the CC2540, but most of them are cut in several parts, which makes my life really complicated to retrieve information (is it a new message, is it the previous one going?). Which brings me to this question: How can I know a message is over, and a new one is beginning? Is it the purpose of RTS/CTS control?

Ok, this was a really dumb question...

CTS/RTS has nothing to do with this. On the contrary, data length field, in every message, may be related... :+). Sorry for that.

Hi Fabien,

You are correct that the data length value will be key in keeping synchronized with the messages that you receive.  The data sent from the CC2540 to your MCU will be HCI event packets.  Most (not all) of the event packets contain Texas Instruments vendor-specific events.

The first byte of an event packet is 0x4.  This value is HCI_EVENT_PACKET as defined in hci_controller.h.

The second byte is the event code.  This is usually a Texas Instruments vendor-specific event, identified by the value 0xFF.  This value is HCI_VE_EVENT_CODE as defined in hci.h.

For Texas Instruments vendor-specific events, the third byte is the data length.

If you always test the above three bytes in the HCI events, you can locate the start of each new HCI event and detect if your receiver has gotten out of sync.

I should mention one exception.  I have occasionally seen the CC2540 send some HCI events that are defined in the Bluetooth standard that are not the TI vendor-specific events.  The one I capture occasionally is HCI_COMMAND_COMPLETE_EVENT_CODE (0x0E) defined in hci.h.  This is why it is very important to test the second byte in every event, since the Bluetooth events you receive are not guaranteed to always be the TI vendor-specific event (0xFF).

Regards,
Chris

Hi Tyrell,

    I am using CC2540EB configuration for HostTestRelease. HCI over USB is working well with Btool, but it failed for HCI over UART. Is there any tricks?

Thanks

Jack Lam

We are working on an application that requires us to control the PAN1720 BT module by sending HCI commands over UART. In an effort towards this we are trying to get the hex files that need to run on the BT modules that use this interface(physical UART).

We are using the BLE v1.3 stack. The HostTestRelease project is being evaluated. When the CC2540USB configuration of this project is used and the hex files are generated and flashed on the PAN1720 EVM, then , upon connecting the EVM to the PC through USB, the PC recognizes the module as a virtual COM port( USB CDC device). When the Btool is run, we are able to see that the module is recognized and is able to scan the BT devices..

We wanted to achieve similar functionality now over the physical UART(and not the virtual COM port through USB). For this, as mentioned in this thread,  we used the CC2540EM configuration of the HostTestRelease project(as against the CC2540USB configuration) and flashed the binaries on the PAN1720 EVM. We then connected the EVM to the PC through a RS232 to USB converter instead of directly connecting it through the USB (The EVM is powered up separately). In this case, however the BTool is not able to recognize the module on the serial port and thus we are not able to get the BT communication going.(We get a GAP device intialization failed error and none of the BTool widgets are activated).

Could you kindly indicate what other changes needs to be done(in the configuration) so that we can get the UART communication to the modules working. Is the RTS/CTS mandatory(we do not have those connected in hardware). I also added the line to disable the flowcontrol in HweOpenDMA() but still there is no change. We tried both UART_0 and UART_1 modules of CC2540 (corresponding to HAL_UART_DMA = 1 or 2 respectively) but even then the module is not being recognized. We also see that the BLE v1.3 stack HostTestRelease has other configurations such as CC2540EM-EBL and  CC2540EM-SBL. What do these mean? Sould we use them?

What we are looking for is for two hex files that run on the BT modules, one that can acccept HCI commands from the master(controller) over UART and transmit the data to another BT module (over BT) which in turn sends this data to another controller through UART again. We need this end to end communication working for which we would first need the two hex files. Could you kindly indicate what hex files(from the B:LE stack) could be used for such applications?Or what changes have to be done in the source codes contained in the BLE stack. Would the changes involve just configuration changes or does it require us to do few other modifications in the stack?

Thanks in advance

Aravinda

We are working on an application that requires us to control the PAN1720 BT module by sending HCI commands over UART. In an effort towards this we are trying to get the hex files that need to run on the BT modules that use this interface(physical UART).

We are using the BLE v1.3 stack. The HostTestRelease project is being evaluated. When the CC2540USB configuration of this project is used and the hex files are generated and flashed on the PAN1720 EVM, then , upon connecting the EVM to the PC through USB, the PC recognizes the module as a virtual COM port( USB CDC device). When the Btool is run, we are able to see that the module is recognized and is able to scan the BT devices..

We wanted to achieve similar functionality now over the physical UART(and not the virtual COM port through USB). For this, as mentioned in this thread,  we used the CC2540EM configuration of the HostTestRelease project(as against the CC2540USB configuration) and flashed the binaries on the PAN1720 EVM. We then connected the EVM to the PC through a RS232 to USB converter instead of directly connecting it through the USB (The EVM is powered up separately). In this case, however the BTool is not able to recognize the module on the serial port and thus we are not able to get the BT communication going.(We get a GAP device intialization failed error and none of the BTool widgets are activated).

Could you kindly indicate what other changes needs to be done(in the configuration) so that we can get the UART communication to the modules working. Is the RTS/CTS mandatory(we do not have those connected in hardware). I also added the line to disable the flowcontrol in HweOpenDMA() but still there is no change. We tried both UART_0 and UART_1 modules of CC2540 (corresponding to HAL_UART_DMA = 1 or 2 respectively) but even then the module is not being recognized. We also see that the BLE v1.3 stack HostTestRelease has other configurations such as CC2540EM-EBL and  CC2540EM-SBL. What do these mean? Sould we use them?

What we are looking for is for two hex files that run on the BT modules, one that can acccept HCI commands from the master(controller) over UART and transmit the data to another BT module (over BT) which in turn sends this data to another controller through UART again. We need this end to end communication working for which we would first need the two hex files. Could you kindly indicate what hex files(from the B:LE stack) could be used for such applications?Or what changes have to be done in the source codes contained in the BLE stack. Would the changes involve just configuration changes or does it require us to do few other modifications in the stack?

Hi Chris Norris,

Me too working on CC2540 with external Controller (MSP430) via UART.

I read lot of forums everywhere they are saying that Hardware flow control (RTS/CTS) is mandatory. Luckily i find this thread where you have some progress without flow control.

Please let me know whether we can go ahead without flow control.

I am using Simple_BLE_pperipheral_Serial_interface project.

Best Regards,

Naveen Kumar

Hi Aravinda,

me too working with PAN1720 and i have a similar project to yours and the same problems.

Have you meanwhile solved the problems? and could give me some advice or add some code example?

Thanks & Regards Daniel

Hello Naveen,

We have a product on the market now with the CC2540 running with no flow control.  We modified TI's HAL UART code as I described in an earlier post to deactivate the flow control.

We did some work to profile the CC2540 application to make sure we don't overrun the UART.  Our data stream to/from the UART is full duplex.

I'm not sure why other forums say that the flow control is mandatory.

Chris Norris

hi Kaloza,

    Your message is very usefull for me. I want to connect the 2540 by the serial with bluez. But I see the bluez web, the version 5.0 can support BLE device, and it requires the kernel version more than 3.5. Why your kernel only 2.6? What's version bluez in your machine?

 HCI supported by CC2540 is not standard HCI with which Bluez works with. Hence bluez will not work with TI chips. Bluez would work with CSR`s chipsets and standard off the shelf USB BLE4.0 dongles.

You will have to port HostTestApp to Linux to work with TI chipset.