I have loaded \BLE-CC254x-1.2\Accessories\HexFiles\CC2540_keyfob_SimpleBLEPeripheral.hex into a V1.01 keyfob and \BLE-CC254x-1.2\Accessories\HexFiles\CC2540_USBdongle_HostTestRelease_All.hex into a rev 1.0 USB dongle. When I do the tutorial in swru270b.pdf section 4.3.1 Reading a Characteristic Value by UUID, the value read is 0x25 instead of 0x22. The other values are also 3 off. 4.3.4 Discovering a Characteristic by UUID returns 02 28 00 F2 FF.
What is going on?
Hi,
Handles are used for addressing local attributes and are enumerated during device initiation, when all services are registered. I would guess that a service may have gotten more attributes added in BLEv1.2, supposedly "Device Information". This would result that everything after those "new" attributes would be shifted in terms of handles. This is why it is importatnd to use the UUIDs and do Service Discovery OTA, so that you know the handles that corresponds to UUIDs.
I will make sure that the documentation gets attention. Thanks for indicating the confusion.
Br
I also have a SmartRF05 & a CC2540EM. I loaded CC2540_SmartRF_SimpleBLEPeripheral.hex into the CC2540EM and tried the demo. The handles returned match the documentation in that case. The source for CC2540_SmartRF_SimpleBLEPeripheral.hex is included in BLEv1.2, but the source for cc2540_ble1.1_keyfob_SimpleBLEPeripheral.hex is not. Is that source available? It would be interesting to compare the two.
Thanks for clearing up the confusion.
Nick L Hi, Handles are used for addressing local attributes and are enumerated during device initiation, when all services are registered. I would guess that a service may have gotten more attributes added in BLEv1.2, supposedly "Device Information". This would result that everything after those "new" attributes would be shifted in terms of handles. This is why it is importatnd to use the UUIDs and do Service Discovery OTA, so that you know the handles that corresponds to UUIDs. I will make sure that the documentation gets attention. Thanks for indicating the confusion. Br
I've been confused by this as well. With version 1.1a of the BLE stack, we were able to issue a Discover Characteristic by UUID with the value f1:ff and we'd receive "0A 22 00 F1 FF", then it was possible to use Read Charactersitic UUID with f1:ff and we'd receive the value stored at handle 0x22, which we could then modify and write to.
With stack version 1.2, if I use Discover Characteristic by UUID with value f1:ff, I get "0A 25 00 F1 FF" CodeNybbler pointed out. This is fine, and I understand why the handle value may be different, but what I can't understand is why issuing Read Using Characteristic UUID with the value f1:ff gives me a failure response. I'm also unable to use Read Characteristic Value/Descriptor with 0x0025, which is the correct handle, nor can I write to this handle, even though it's got 0x0A for the permissions (read/write capable).
So to recap, why can we no longer read/write this characteristic handle with BLE stack version 1.2? Thanks,
Adam
Hi Adam & Nick,
I think Adam may be right. The other day, during a quick test, I realized I was not able to activate the "Link loss alert", which I think is the same one Adam is trying to activate. Am I wrong, Adam?
If I do not remember wrong, because my keyfob is almost destroyed due to intense hardware tests, I suffered from the same issues, but I repeat, I tested in a quick way. Can anybody at TI test this?
Please click the Verify Answer button on a post if it answers your question! :)
Hi Adam,
That is weird. I dont not see the issue you are experiencing. I have tried both flashing the keyfob from IAR using simpleBLEPeripheral project and also using CC2540_keyfob_SimpleBLEPeripheral.hex with Flash Programmer. As you see in the PrintScreen image below, I can successfully read and write.
Please have another go, or correct me if I understood your problem in a wrong way.
Hi Nick, thanks for your response, now that I know it's not expected behaviour, I managed to track down the problem. Turns out I had flashed the keyfob to the 1.2 software, but the USB dongle was still using the software from the 1.1a stack. So if anyone runs into the issue of receiving a failure response when attempting to use Read Using Characteristic UUID, or a failure when writing a Characteristic Value Handle, make sure you're using the same stack version on the USB dongle, keyfob and BTool. Thanks again Nick, you've saved me a lot of confusion!!
Same thing here. Sorry.
Hi!
I had the same problem. Can anyone explain why this is happening?
If both versions (1.1 and 1.2) meet the BE specifications, why it's impossible to read characteristics by UUID or by right handle?
Serg
Hi Mr White,
Handles has nothing to do with any specification, they are just internal addressing. For example, you use the UUID to discover the handles, that is a specification procedure.
Consider following user case. You are going to visit a library to get a specific book, but since libraries not place their books in same manner (since libraries are not built the same) you would have to ask a librarian where the book can be found. You would get the internal address.
I dont know if this made any sense to you but I hope so.
Hi Nick L
1. I discover characteristic by UUID, as specification procedure, and got a right handle (rigth "internal address for this library"). Why it's unable to read characteristic by this right handle, as specification procedure?
2. Let's forget about handles. Is this specified procedure to read characteristic by UUID? Why it's unable to read characteristic by UUID, as specification procedure, if I using different versions of stack in KeyFob and in USB Stick?
Mr. White1. I discover characteristic by UUID, as specification procedure, and got a right handle (rigth "internal address for this library"). Why it's unable to read characteristic by this right handle, as specification procedure?
When you do the "discover characteristic by UUID" procedure, you will get a response with permission, UUID, and handle. As long as you have permission to write/read to that characteristic (Read permission bit is 0x01 and Write permission bit is 0x02), you shall be able to do it
Mr. White2. Let's forget about handles. Is this specified procedure to read characteristic by UUID? Why it's unable to read characteristic by UUID, as specification procedure, if I using different versions of stack in KeyFob and in USB Stick?
That should not happen, which UUID are you trying to read? For example, you cannot read/write to "keyPressed" (UUID 0xFFE1) attribute in simpleKeys. For this you would write 01:00 to the handle + 1 to enable notifications, which would be how you obtain button pushes OTA.
Are you tried to do so?
Try to flash v1.1 to USB Stick and v1.2 to KeyFob and you'll be surprised.
I told you again: it's impossible in this situation (v1.1 in USB Stick and v1.2 in KeyFob) to read characteristic (0xFFF1 for example) with read permission and right handle!!!
And more, it's impossible to read characteristic by UUID (0xFFF1 for example)!!!
Just try!!!
Mr. White,
I suppose you use the latest BTool as well (1.20c), I could replicate what you are experiencing. I did however tested with an older BTool (1.10a) as well, which worked fine. So maybe there is something in the newer BTool that has been updated so that it do not longer fully support older versions of HostTestRelease.
I can only conclude that you should use the latest HostTestRelease build (v1.2) and the latest BTool (v1.20c).
Hi Nick,
I also discovered the change in handle values from V1.1 to V1.2, having also taken the shortcut of using 'well known' handle values.
FWIW, the change in handle values is not reflected in the CC2540/41 Bluetooth® Low Energy Software Developer’s Guide v1.2 (doc ID SWRU271B) which still has the values from v1.1 in the attribute tables on pages 36 and 37.
Richard
Hello Nick,
An additional typo which could be corrected in a newer version: the handle 0x20 is two times in the list.
Is it possible to publish all versions of the table that one does not need to read out every value?
rider