I am running the BLE-CC254x-1.2.1 stack, HostTestApp project, EB configuration on my Mini Dev. Kit keyfob device. I know that the HostTestApp EB configuration is meant for the more advanced SmartRF EB, but I am just looking to use the HCI-over-UART functionality. I am using a PIC to communicate via UART using HCI to control the CC2540. I am sending GAP_Init() transmissions to the CC2540, and I receive return codes of INVALIDPARAMETER (0x01) for any "profileRole" that contains a binary bit for the value '4'. In the possible 8 bits that define any character, xxxxxxxx, if the 3rd spot is a binary 1 (xxxxx1xx), I am seeing that the CC2540 is mislabeling or mishandling this value. For example, I am sending a GAP_Init() command from my PIC to the CC2540, sending a profileRole of 0x02, to put the device in Observer mode. The return code is SUCCESS (0x00). Same for Broadcaster (0x01), and Broadcaster/Observer (0x03). Doing GAP_Init() for Peripheral (0x04) or any combination of possible modes that includes the binary bit for a '4' (for example, 0x05, which is 0b00000101) returns a value of INVALIDPARAMETER (0x01).
If I edit the HostTestApp code, specifically in the "hci_ext_app.c" file, to call GAP_Init() with a hard-coded argument of 0x04 replacing the "profileRole" argument, my GAP_Init() UART transmissions from the PIC return the correct and expected RX dumps, along with return values of SUCCESS (0x00)--the purpose of editing the code like this is to confirm that the device can be put into peripheral mode, if a profileRole of 0x04 is passed to the GAP_Init() routine in the firmware (I hard-coded a value of 0x04 to always be passed to the GAP_Init() function as the profileRole value).
My observation is that the third bit in any character is being "stretched out", and possibly mishandled due to faulty timing. A transmitted binary value of 0x04 is not being recognized by the CC2540 as a binary value of 0x04. I have confirmed with a logic analyzer that my PIC is sending valid characters over UART. Equal pulse widths for 0x01, 0x02, 0x04, and 0x08 are observed using a logic analyzer looking on the UART TX line from the PIC to the CC2540. However, when the CC2540 must send response data back to the PIC, on the UART RX line I see equal pulse widths for 0x01, 0x02, and 0x08, but for returned values of 0x04 I observe a pulse with at least twice the width of the other pulse widths for 01x01, 0x02, and 0x08. This is what leads me to believe that 0x04 is being mishandled.
Furthermore, I have also edited the HostTestApp code to return a value of the received "profileRole" variable, instead of returning the usual code of SUCCESS (0x00) or INVALIDPARAMETER (0x01) in response to a GAP_Init() HCI command. If I send a GAP_Init() command over UART to the CC2540, containing a "profileRole" value of 0x01 for Broadcaster, I recieve the mirrored "profileRole" value of 0x01 on the UART RX line, which is to be expected, given my code edit. Same thing with 0x02, 0x03, 0x08, 0x09, etc--for any profileRole not including a 0x04 binary bit, I receive back the correct binary values. When I do the same thing, but send a GAP_Init() UART command with a "profileRole" of 0x04, I see in the returned data stream a binary value that is a "stretched out" bit where the bit 0x04 should be. This leads me to believe that the CC2540 is not recognizing a 0x04 over UART as a 0x04, but rather that the timing is off somewhere, leading to an unpredictable state.
