Forums

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?