BLE capability without use of RTOS in CC2650

Thank you very much for your answer.

Because I have just realized that my post may was unclear, the question was about the use of Bluetooth stack without the TI-RTOS.

I have managed to debug with CC26xxWare libraries without RTOS very well but I do not know if I could use BLE stack without RTOS.

Is still the answer that I should build RTOS, in order to use somehow the BLE, but never start it with the BIOS_start()?

Thank you in advance.

Regards,
Yiannis

Yes, it is never an easy task to cook the stack (framework) from scratch.

But, another reason for me to do it is to build the entire framework in C++. Personally, I have used C++ in embedded systems for several years. And I found C++ is pretty useful if you can accept some overheads. The code will be much easier to understand and maintain.

In order to fully utilise the power of C++, I also make C++ native to my RTOS. That means, it is possible to create a C++ class with task's event-loop directly. For example,

class MyTask: public pos::Task
{
private:
    pos::Mutex mutex;
    ...

public:
    MyTask();
    ~MyTask();
    void run();
    ...
};

MyTask::run()
{
    while(1){
        mutex.lock();
        ...
        mutex.unlock();
       ...
    }
}

pos is namespace of my RTOS. Task is the class directly supported in my RTOS. run() is the event-loop function to be overwritten by user. As you can see, mutex (and semaphore) is also directly supported in C++.

So, in my system, you can organise everything in "object-oriented" way.

Robert,

how did you go building the BLE stack?

I was able to get a hacked up Zigbee stack going OK but am struggling with BLE.

I am able to advertise and receive a CONNECT_REQ,  swap channels and issue the TI radio command CMD_BLE_SLAVE. I get half of the first LL packet from the Master before the Slave times out.

Changing the slave timeout and end time seems to make no difference - the timeout still occurs almost straight away and then the master is disconnected before I can transmit anything.

There seems to be no information at all about the BLE stack. Its really unfortunate.

I had hoped to have a custom "Zigbee" stack and a custom "BLE" stack running on the device so you could press a button to configure the device/monitor readings using BLE and a smartphone or switch it back to Zigbee to transmit back to a base.

The "Zigbee" side is all good and I can sort of make the BLE work using the Manufacturer data in the advertisement and the data in the scan response. However it is far from ideal.

The things I noticed which may be of uses to someone with a better understanding of the CC2650 and feels like a challenge are:

1. If I use the Contiki overrides when configuring the radio in BLE mode all is good. If I use the TI driver overrides I sending the advertisement fails.

2. After receiving the CONNECT_REQ I was able to swap to the requested channel and connect briefly before the CC2650 timed out.

3. Applying the TI patches causes the connection to end unexpectedly rather than time out.

Anyway after several weeks of trying all sorts of things I have come to the conclusion that it is a pointless exercise and will probably just use an external BLE module.

Please TI surprise me and release some more information to make BLE possible without using the full blown stack.

Hi Venemo (4403184),

After trying to design my own BLE stack on CC2640 for several months, the ADVERTISING mode is working well. iOS App can receive the advertisement from my device. But there is a strange issue: The radio CPU will block if the overrides is assigned when executing CMD_RADIO_SETUP. If it is not assigned (set pRegOverride=NULL) then CMD_RADIO_SETUP works well. I have tested this issue on both my customized board and CC2650 LaunchPad. The result is the same.

Do you know what could be the reason?

Now I try to make CONNECTION mode work. OK, I let CC2640 to send advertisement over channels 37, 38, 39 every second. So, I get three TX_DONE interrupts for every second. By designing an iOS App (using Swift language) to discover the CC2640 device. When it is discovered, try to connect to the device as shown in the following code snippet.

// Connect to the discovered peripheral
func centralManager(_ central: CBCentralManager, didDiscover peripheral: CBPeripheral, advertisementData: [String : Any], rssi RSSI: NSNumber) {
	print(#function)
	print("  " + peripheral.description)
	print("  RSSI = " + RSSI.stringValue)
	connectingPeripheral = peripheral
	connectingPeripheral.delegate = self
	centralManager.connect(connectingPeripheral, options: nil)
}

I can see the print() log messages. At the same time, CC2640 gets RX_ENTRY_DONE and RX_DONE interrupts. Then, I try to read RX buffer entry which is in FINISHED state. I expect to get the CONNECT_REQ PDU in this entry. But what I got is an empty entry, length=0, type=ADV_NC_IND and channel=38 from the status byte.

From the advOutput data structure, nRxConnectReq=1. So I know the CONNECT_REQ PDU is already received by radio CPU. But how can I get it in system CPU?

The CONNECT_REQ PDU contains accessAddress which must be assigned in the CMD_SLAVE command to enter slave role. So, I am stuck here.

I think you may have studied and done experiments on CC2640 RFC. Hope that you can help me on this.