RoadTest: TI SimpleLink™ Bluetooth® LE CC2640R2F LaunchPad
Author: Fred27
Creation date:
Evaluation Type: Evaluation Boards
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: TI's CC2650
What were the biggest problems encountered?: The constantly changing SimpleLink device portfolio. Compatibility with Nexus 6 (BLE 4.1)
Detailed Review:
I'm going to start this review by giving you a summary of the CC2640R2F Launchpad. It's not going to be an unboxing in the traditional sense, because I think there's limited value in showing you what the product looks like in and out of a cardboard box. If you really want one, there a photo coming up of it leaning on the box at a jaunty angle. What I'm going to try in part 1 is an sort of unboxing of the hardware, software and development environment. That is in my opinion what the product is about - not just a piece of silicon on a PCB, but something that lets you prototype a Bluetooth-enabled device.
If you've ever worked with any other Texas Instruments LaunchPad then you won't be too surprised what's in the box. You get just what you need, which is the LaunchPad, a sheet with the pinout for the GPIO headers, and a micro USB cable. The box design seems to have had a little love and attention from a graphic designer but little else has changed over the years.
There are some links on the enclosed leaflets to take you to the software you'll need to get up and running. The first think you'll need to do is download and install TI's IDE - Code Composer Studio. Luckily from version 7.0 it's completely free. It runs on Windows or Linux so should keep most people happy. Later you'll also need to download (from within CCS) the SimpleLink CC2640R2 SDK and optional training material.
With the exception of the early MSP430 G2 LaunchPad, TI have stuck with a standard configuration and layout. The top half of the board is the debugger - in this case a XDS110. The TM4C1294 microcontroller used for the debugger dwarfs the little CC2640R2F on the bottom half of the board. As with other LaunchPads, the debugger can be electrically separated from the CC2640R2F below. Whilst some of the earlier boards could be physically separated along a dotted line I doubt it's possible with this one and you'd certainly be brave to try. There is a row of 0.1" jumpers to isolate the debugger from the CC2640R2F. There are also two standard 10-pin 0.05" pitch ARM Cortex debug headers. One you could use to connect the XDS110 to a different board; the other allows you to connect an external debugger to the microcontroller. Electrically if not physically, you have two separate devices on one PCB.
The CC2640R2F part is essentially a breakout board for the microcontroller. It has a couple of LEDs and buttons, a crystal oscillator and probably more GPI/O than you would need. 40 pins are broken out in the standard LAUNCHXL format which means that any of TI's range of booster packs will fit. A more important question though is, will they work? Luckily TI have a Booster Pack checker which will not only tell you whether a Booster Pack will work with your LaunchPad (29 of 50 will in this case) but also if a combination of Booster Packs will work together or clash. Try it out here before starting work on your Bluetooth-enabled NFC reader.
The CC2640R2F is TI's latest Bluetooth-enabled MCU. Well, I say the latest but it's not quite - more on that later. Rather than having a MCU and a seperate Bluetooth Controller (such TI's CC2564) it's all rolled into once "Wireless MCU". To some extent is supersedes the CC2650, before that the CC2640, and before that the 8051-based CC2540. There's been quite a range over the years and they've had confusingly similar names so forgive me if I've missed one or got one muddled up. They're all still active designs too.
It contains a very nice ARM Cortex-M3 16-bit microcontroller that runs up to 48MHz. It has 128K of Flash and 20K of RAM, the usual comprehensive array of peripherals that you'd expect on a modern microcontroller - all of which can be routed to any pin. No more pin clashes! Some of the more interesting peripherals are capacitive touch and a ultra-low power sensor controller that lets the rest of the MCU and radio remain powered down. If you need any more details then the datasheet is here, but I'm willing to bet it is probably up to the job of whatever you have in mind.
In addition to the main M3 processor, the radio itself is a Cortex-M0 and the sensor controller is an undisclosed 16-bit MCU. You certainly get a lot inside that one tiny square of plastic.
Whilst the hardware is very nice, I'm of the opinion that any microcontroller or SBC will live or die depending on the support and the software for it. It doesn't matter how great it is if you can't code for it.
CCS is TI's primary development IDE. The great news is that as of version 7.0 it's now completely free. It's an Eclipse-based IDE so may be familiar to some developers. As you'd expect, it integrates very nicely with the hardware and it has great debugging features. On some devices (not the CC2640R2 unfortunately) it has the awesome EnergyTrace feature which lets you monitor power consumption.
CCS can be downloaded here. You do unfortunately have to register with TI and promise you're not going to use it in North Korea which may annoy some people, but that's a small price to pay for a well-integrated IDE in my opinion. You can also run CCS online without any download. That approach doesn't really appeal to me so I've not really tried it.
TI have quite a range of wireless MCUs. If you just include the latest versions then you have the following:
| MCU | Wireless capabilities |
|---|---|
| CC3220 | WiFi |
| CC2640R2F | Bluetooth Low Energy (including Bluetooth 5) |
| CC1310 | Sub-1GHz |
| CC1350 | BLE, Sub-1GHz |
| CC2650 | BLE, ZigBee, RF4CE, 6LoWPAN |
The SimpleLink™ umbrella is an attempt to simplify software development for these. Libraries are provided for radio operation and it's all based on a Real Time Operating System - TI-RTOS. This broad range of products under one umbrella is generally a good thing. It lets you port concepts and experience (and code if relevent) between these devices.
However, there are some issues. The fact that things move on quickly can make things confusing. The CC2650 was their go-to Bluetooth device fairly recently but has now been sort of superseded by the CC2640R2. They're not exactly the same as you'll see from the table above but you do get the impression that the latest device gets all the love.
The constantly moving range of devices and the fact that lots of the shared examples only seems to refer to the device of the day can get a little frustrating. For instance when previously working with the CC2650, I have frequently found that documentation and examples refer to the CC2640. The main page for the CC2650 Launchpad even has videos about Sub-1Ghz that apply to the CC13x0 family. Things generally seem to be improving with each new device, but it's still messy.
Remember I said that the CC2640R2F wasn't quite the latest and greatest? To prove my point about the changing range, look what I stumbled across waiting in the wings - the not-quite-available-yet CC2642R1, CC2652R1 and a CC26x2R1 LaunchPad. The CC2642R1 is BLE 5, so potentially a replacement for the CC2640R2F. The CC2652R1 is not quite the same - it's designed for BLE 5 and Thread/ZigBee.
In order to use your chosen Wireless MCU in CCS, you'll need to download the SDK. You do this using CCS's Resource Explorer. Here I've shown where you can download both the SDK and examples. You don't actually have to download these. You can just work with them online if you just want to have a peek. However, if you've got a board you're very likely to want to have these available locally.
You'll also be asked if you want to download the appropriate SimpleLink Academy to go with your SDK. Once again, I'd suggest that you do. The Academy contains quite a few Labs that walk you through compiling and running the sample projects that are supplied.
Now, at this point many road tests would probably walk you through creating your first application. Whilst this is really useful, I feel I'd probably be trying to duplicate the work that TI have done creating the SimpleLink Academy. If you click through to the academy in Resource Explorer (shown above) then you 'll see that the labs range from Project Zero all the way through to using the Sensor Controller to really keep your power consumption down. Very thorough stuff.
I'm not finishing the road test here. I'll be running through these myself and getting back here with a "Part 3". However, you can be certain that TI have done a better job than I would getting you started with the CC2640R2F and documenting what it can do. For now, I'd suggest you continue exploring the CC2640R2F there. If you don't have CCS installed then you can checkout the SimpleLink Academy online.
So, the obvious place to get started is where the SimpleLink Academy suggests that you start - Project Zero. The instructions for this are simple and clear. All you need to do is browse to it in resource Explorer. If you can't find it, it's under Software / SimpleLink CC2640R2 SDK [version] / SimpleLink Academy [version] / Labs / Bluetooth LE / Projects / Project Zero. Then you click the button that looks like the Code Composer Studio icon to import the project and its dependencies into your workspace. Then click the "bug" button in the taskbar to deploy and debug your project. It may take a little while to build first time and you may be prompted to update the firmware on your XDS110 first, but you should soon see CCS waiting at a breakpoint on the first line of your code. Hit F8 to continue.
The lab tells you to open up BLE Scanner on your Android phone or LightBlue explorer on iPhone and interact with your shiny new BLE enabled board. Here is where this road test started to hit a few potholes. Whilst me phone could see the Bluetooth device, it refused to connect to or interact with it. I assumed that I'd done something wrong or missed a step. Perhaps I'd managed to deploy the application without the BLE stack that it depends on. As you can imagine I sent quite a few hours rebuilding, debugging, trying both my phone and my wife's, etc.
I tried running the same project Zero on an older CC2650 board. This turned out to be a little tricky to find. As I mentioned in Part 1, earlier devices isn't quite abandoned, but it does tend to drop off the radar a little. Project Zero for the CC2650 is no longer accessible in Resource Explorer. Googling for "CC2650 project Zero" came up with this page, but it appears to be orphaned. I ended up having to download teh deprecated SimpleLink Academy 1.11, open it in resource Explorer Classis and import the project as usual. It worked just fine. Very odd. In teh screenshots you can see the the CC2650 (Project Zero) has connected but the CC2640R2F (Project Zero R2) has not.
My Nexus 6 is Bluetooth 4.1 but I tried "Project Zero BLE5" anyway. No difference. Whilst working on this, SimpleLink Academy for the CC2640R2F was updated from 1.13.02.07 to 1.13.03.11. Maybe a bug had been fixed. No difference. Then I persuaded a work colleague to install BLE Scanner and try to connect. Success! He had a 1 plus 3T which as Bluetooth 4.2. There should be no problems connecting to any 4.x devices. From TI's Top 5 Questions:
"Is Bluetooth 5 backwards compatible with existing Bluetooth 4.x devices? Yes! As with all features added in the Bluetooth 4.1, 4.2 and 5 specifications, they are optional and negotiated during the BLE connection. This ensures that Bluetooth 5 devices can reliably connect to and interact with legacy Bluetooth 4.x devices."
So, something has changed from the CC2650 to the CC2640R2F that means it won't work with some phones. I'm still trying to dig a little deeper, but as there seems to no incoming request it may be something that's out of reach.
Unfortunately, this obviously made it rather difficult to continue with any meaningful road testing on developing BLE applications.
My phone does recognise the Launchpad even if it can't connect. One thing I could still do was examine how the range compares. The CC2640R2F is supposed to have better range - although this is mainly sue to its ability to support BLE 5 Long Range mode. I wasn't able to test this out but I was able to do a like-for-like comparison between the CC2650 and CC2640R2F in standard mode. I powered up both devices running Project Zero and let the signal strength indicator on BLE Scanner compare the two.
The results in the screenshot aren't encouraging. I've picked the example that shows the CC2640R2F dropping out of range while the CC2650 is still connected. To be fair the newer device always lagged behind but there was never a significant difference between them. Let's call it a draw.
Well, I'm a little disappointed with TI's latest and greatest. Maybe the upcoming CC2642 can address these shortcomings? Maybe it's just a tweak to the firmware that's needed to restore compatibility with slightly older devices? I'll keep trying to find out.
A slightly negative conclusion isn't a fail though. This is a road test, not a promotion, and I have to be honest. On the plus side, TI's documentation, sample code and development environment are great and improving all the time. However, if your project may need to connect to Bluetooth 4.1 then maybe the CC2640R2F isn't for you and you should stick with the CC2650.
