When UART enabled, BLE not working on CC2540.

How are you setting up the Preprocessors?

Hi Michael,

It turns out that the Keyfob keys are connected to P0 (P0_0, P0_1) and you are trying to use that port for the UART, you must see a warning about that on the compiler:

Warning[w52]: More than one definition for the byte at address 0x6b in common segment INTVEC. It is defined in module "hal_uart" as well as in module "hal_key"

Somehow when POWER_SAVING is disabled the warning goes away and the keys actually work. I think this is due how the hal uart driver manages the pin IO mapping, also if you want to use UART0 alt. 2 or UART1 alt.1 you will have to modify the driver. 

At the moment I would recommend you disable POWER_SAVING when using the UART, because there are other problems (like transmission freezes between bits) documented in the forum.

Best Regards.

Hi mando. 

I'm using the image below as reference and i'm using alt.2 P0_2 (rx) and P0_3 (tx) to connect to UART.

As i posted earlier, i got the keyfob working with UART and connecting up to the dongle using btool.

The thing i'm struggling with now, is how to get the RX UART data sent over to btool, and then later on over to an Motorola Razr.

I have tried using the GATT_notifications, but this only gives me "success" when connhandle = 0. When i try to write a command like this: 

if (GATT_notification (0,0, FALSE ) = success)

{

HalUARTWrite(SBP_UARTPORT, "works", 5);

}

This function never gets called even if btool gives me a "success" on event. 
The function is written in the serialAppUtil.c file from serialApp.  

Any help or other soultions here would be much appreciated.

Sincear, MIchael 

Hi again Mando.

You are of course correct. I use Alt.1 :) 

I tried your suggestion and it works in someway,

The thing is that i can't get it triggered from btool yet, but the keyfob sends data over BLE when i send a data-packet to the keyfob to it's rx. (sending a string from terminal program on pc to keyfob) 

I have used some cases just to check that the uart is working properly, and when i use one of these cases the keyfob sends the uint8 mybtes[20] packet. 

As image below shows: 

The cases i use is THESE.

probably the reason why it does this is because i put the sappSendNotification class to be called in the UART callback class. (going to check this out) 

But i still don't understand why the IF function gets called from the rx buffer and not from btool. 

Sincear, Michael.  

Hi Michael,

From what I understand you are saying that GATT_Notification is not returning the SUCCESS status? Or maybe it's indeed returning SUCCESS but you can't send data because the UART is blocked somehow? If you are calling the UART to write in it's own callback you should be falling in an infinite loop or something that hangs your device.

Confirm if you can send 2 or 3 notifications in the same connection using your cases. Normally I would say you to go into debug mode but you can't since you're using the debug header port for UART. Hope you can solve your problem.

Best Regards.

Hi Mando. 

Thanks for many good answers. 

I am now able to send data to btool with notification. (PC1 with terminal--> UART to keyfob ---> BLE from keyfob to dongle --> dongle to pc2 with btool) 

So now I can send a bit from the terminal and it gives a notifications to btool, which works fine now. 

But when I try to write out more bit on terminal the btool won't send out the correct data. (it just sends out some part of the content I want to send through uart)

What I need to do is to send 8 bit packets, and I have tried to configure as below:

Is there any mayor errors I have done since the UART wont pass out the correct data? 

Note: When I try to send out a hardcoded string as  HalUARTWRITE(SBP_UART_PORT, "works", 5);  

It sends this data correctly, but UART fails when reading on rx buffer and sends out wrong data. . 

Sincear, Michael.

Hello Michael,

I'm not trying to steal Mandos' thunder, he deserves all the credit, but I can help you on this little part.  The readbytes = ... is a return value from the function call.  It is 1. (You can double check this through debug.)  So you are only getting 1 byte read correctly because that is the length.  There is a sizeof() function that you can use to get the number of bytes.

Congratulations on your success!  But most importantly, thanks for sharing your hard work!

Thanks,

Hi again greenja. 

It's my pleasure to share what i have done, and I figured i'm not the only one out there who is still a little confused about how the cc2540 works. 

If this project is successful, I plan to set up a wiki page so people can get simple guides to configure the cc2540. 

I was not aware of the sizeof() function, so thank you. 

I have the keyfob to send two packet when sending 1 byte over ble. (Code  HERE)

I have tried multiple times, but can't get it to send 1 packet with 1 byte, it always gives me 2 packets and I don't know why. 

When using btool, I see that It dosen't send the packets as fast as I need. (approx 700 packets pr minute)

Since i'm having streaming of data to the rx on the keyfob, it dosent sent out a lot of data that is sent over UART. 

I have also tested with connecting Labview with dongle and this works great, but the graph I use to check the data is not close to what I need. 

Is there any more efficient method to send over UART than GATT_notification? 

i'm currently using baudrate = 2400 over UART, but I can't see where the baudrate for ble is defined? When using btool and/or Labview, apparantly I can set the baud to whatever I want and still get some data out. 

Sincear, Michael.

Hi Michael,

The throughput (payload data rate) is not defined explicitly in BLE since is very aplication dependent and greatly affects the energy consumption, something critical for low energy comm., so you need to make your own calculations for your application. The data exchange in BLE happens in "events" where master & slave meet each other, so let's say if your events are programmed to be every 1 sec. you will be unable to send 2400 bps (since BLE stack permits only 4 packets per connection event and a max payload about 20 bytes per packet).

If you want to adjust the connection event periodicity to your needs check this in your code:

// Minimum connection interval (units of 1.25ms, 80=100ms) if automatic parameter update request is enabled
#define DEFAULT_DESIRED_MIN_CONN_INTERVAL 80

// Maximum connection interval (units of 1.25ms, 800=1000ms) if automatic parameter update request is enabled
#define DEFAULT_DESIRED_MAX_CONN_INTERVAL 800

Note that the minimun connection interval in BLE is 7.5 ms.

One useful link and code for understanding BLE throughput is this:

http://processors.wiki.ti.com/index.php/CC2540_Data_Throughput 

Keep up your good work.

Best regards.

Hi Mando, 

Thank you for replying. 

I've been experimenting with the connection interval settings. When changing these the establishment between the keyfob and dongle, it sometimes get very unstable. I got some settings that it currently works fine with. I also send over BLE with burst mode to get as much data over as possible. 

I have been doing it all wrong when trying to read the data in labview. Since i first used it to just read the data right out of UART when using cable from the keyfob.

But as i understand the packets sent over BLE is in 128 bit packets? So when i'm now using labview it read all of the 128 bit packets and i think this is the reason why i get so much dummy data onto labview. 

I currently am testing with this code in my uart callback function.

So here the halUARTWrite function write out perfectly on the tx, but when sending over to ble it fails bigtime and sends a lot of dummy data. 

I still haven't understood the baudrate configutations over bluetooth. Is the simpleBLEperipheral on the keyfob and the Hosttestrelease on the dongle on 57600 default, or must i use 2400 in baud since i have configured the keyfob to read this on its UART? 

I must say that getting answers from you and greenja has helped alot for my progress in this proejct, so thanks to both.

Sincear, Michael.