I'm a bit confused over the HexFile naming conventions in the BLE-CC254x.1.2.1/Accessories/HexFiles folder.
This folder contians hex files for both the keyfob and the USBdongle, right?
I presume for the SimplePeripheralBLE example:
keyfob is loaded with CC2540_keyfob_SimpleBLEPeripheral.hex
What is the difference between
1) CC2540_SmartRF_HostTestRelease_All.hex and
2) CC2540_USBdongle_HostTestRelease_All.hex and
3) CC2540_SmartRF-SimpleBLECentral.hex
Are each of these 3 hex files code targeted for the dongle?
Is there a dongle file which corresponds to the CC2540MiniDkDemoSlave.hex file? Will one of the 3 files listed above allow the dongle to be the central device for the keyfob running the DemoSlave program?
===================== Part II ==================
I am using the Btool to message the key fob running the SimpleBLEPeripheral code.
I am finding that the attribute table in the documentation (Bluetooth Low Energy CC2540 Mini Development Kit User Guide, Version 1.1) doesn't match up to my experimental probing.
The table matches up through handle 0xD, [ Documented Note: ServiceChanged characteristic declaration.]
0xE is not readable as documented.
But then, 0xF returns 00 00 (not 0x180A as documented).
The handle values then appear to be off by 1 from 0x10 through 0x1F :
0x10 returns 0x180A the value which the atttribute table indicates shoud be returned by 0xF.
Similarly 0x11 returns what is the documentation indicates is to be returned by 0x10.
This off by 1 behavior continues through hex handle 0x20 where another anomaly occurs (I won't document it) but additional offests are observed where the documented data associated with handle 0x22 is actually returned by handle 0x25.
Is this known behavior, or is it indicative I've got a configutation issue?
Thanks,
Chip