• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 51 subscribers
  • Views 2686 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

cc2540/cc2541 - BLE Bridge - corrupted data received from a single byte UART communication.

Dag.FF2
Intellectual 300 points
Other Parts Discussed in Thread: CC2541, CC2540

Hi,

I need some help with the following scenario using the BLE Bridge:

SETUP «

I am running a simple UART test, where a single byte is transmitted from a cc2541 Keyfob to a cc2540 USB using the following configuration:

(1)  Windows 7 PC: USB-to-RS232 adapter Tx pin
                   RealTerm program,
                   BTool program,
                   IAR Embedded Workbench [8051 core]

(2) cc2541 Keyfob: TEST port pin-6 [P1_7] @9600 BAUD,8,n,1, and
                   RF @115200 BAUD,8,n,1

(3)    cc2540 USB: RF @115200 BAUD,8,n,1

Where (1) physically connects to (2) by means of the USB-to-RS232 adapter, (2) connects to (3) over-the-air and (1) runs the RealTerm, BTool and IAR EW [8051 core] programs simultaneously.
»

TEST «

1) A single hex byte [0x01] is transmitted from (1) to (2) using the RealTerm program.
2) The hex byte received at (2) is [0x01] (as probed with an oscilloscope).
3) The hex byte received over-the-air at (3) is 0x7F.

=[Windows 7 PC]===================
  Transmitter: RealTerm: Serial Capture Program 2.0.0.70
Port Settings: 9600 BAUD, 8, n, 1
    Data Sent: [0x01]

=[Keyfob Development Board]========
     Receiver: cc2541 Keyfob
Port Settings: 9600 BAUD, 8, n, 1
    Registers: from function "HalUARTOpenDMA(halUARTCfg_t *config)"
               ...
               UxBAUD = 59;
               UxGCR = 8;
               UxUCR = UCR_STOP; // 8 bits/char; no parity; 1 stop bit; stop bit hi.
               ...
Data Received: [0x01]

  Transmitter: cc2541 Keyfob
Port Settings: 115200 BAUD, 8, n, 1
    Data Sent: [ ? ]

=[USB Development Board]==========
     Receiver: cc2540 USB and BTool - Bluetooth Low Energy PC Application - v1.41.05
Port Settings: 115200 BAUD, 8, n, 1
Data Received: [0x7F]
»

OBSERVATION «

1) The data appears to be inverted and shifted-in in reverse order.

     0x01 --> 0000 0001 (original data)
0000 0001 --> 1111 1110 (1's complement inversion)
1111 1110 --> 0111 1111 (LSB to MSB conversion)
0111 1111 --> 0x7F      (data received)
»

QUESTIONS «

1) Where and in which piece of the code is this conversion happening?
2) Is there an Application Note that addresses this conversion and what to do to convert the data back, to make the data received the same as the data sent?
3) Does this conversion happen with the SPI as well?
»

Please advise.  Thanks.

  • 0
    TI__Guru** 105180 points
    Hello Dag,

    It's difficult to identify from the description, but should be easy to determine the exact SW behavior with the CC Debugger and a BLE air sniffer.

    What are you using for your custom service? Are you using the processors.wiki.ti.com/.../SerialBLEbridge_V_1.4.1 Serial Bridge example?

    The debugger should allow you to inspect the incoming UART data before you write it to your service's characteristic. From there, you can use the BLE sniffer to see what is going over the air. Likewise, on the Central side, you can trace the data coming from the BLE Stack (in the callback function) before it gets sent to the PC.

    Best wishes
  • 0 in reply to JXS
    Intellectual 300 points

    Hello JXS,

    Thanks for your reply.

    In a nutshell, the cc2541 KEYFOB receives a hexadecimal byte [0x01] at its UART Port from an RS-232 Terminal program.  When the KEYFOB transmits this 

    data over-the-air to the cc2540 USB, it is received as hexadecimal byte [0x7F], as seen in the BTool window, at handle 0x002E, UUID 0xFFF4.

    Yes, I was able to get this far using the Serial Bridge (v 1.4.1) example.

    I will use the SmartRF Packet Sniffer and post an update.

  • 0 in reply to Dag.FF2
    Intellectual 300 points

    Hello JXS,

    To which device does the SmartRF Packet Sniffer connect, cc2540 USB or cc2541 Keyfob?  There isn't any activity in the "Capturing device" tab of the SmartRF Packet Sniffer after pressing F5.  The START button does NOT stay ON either.

    The Radio Configuration was set as follows:
      - Advertising Channel: 38 (2426 MHz)
      - Connect to Initiator Address is selected, and the address used [54:4A:16:48:B3:E1] (Keyfob)
      - Long Term Key: <blank>
      - Pass Key: 000000

    Is a Comm port selection required?  Please advise.  Thanks.

     

  • 0 in reply to Dag.FF2
    TI__Guru** 105180 points
    Hello Dag,

    For BLE, the Packet Sniffer must use the CC2540USB dongle flashed with the Packet Sniffer firmware as the capturing device. You can find more details in the Packet Sniffer User Guide (swru187).

    Best wishes
  • 0 in reply to JXS
    Intellectual 300 points

    Hello JXS,

    Success!  Flashing the USB dongle was the missing link: the SmartRF Packet Sniffer program now reports all packets received. 

    So, to recap: the SmartRF Packet Sniffer reports data received at the USB Dongle.  Granted this is correct, and going back to the original focus, which tool can be used to examine what's happening at the cc2541 Keyfob during transmission of the data packets?  Please advise.  Thanks.

  • 0 in reply to Dag.FF2
    TI__Guru** 105180 points
    Hello Dag,

    What did the packet sniff log indicate? Was the data in the expected format while being transferred via BLE?

    You can use the CC Debugger tool to step through the code and watch data in the KeyFob.

    Best wishes
  • 0 in reply to JXS
    Intellectual 300 points

    Hello JXS,

    The data still appears corrupted/converted: a [0x01] captured in the Keyfob's DBUF register from the UART communication is transmitted as [0x7F] from the Keyfob over-the-air to the USB Dongle.  May I ask for your help with keywords I can use, to search the code or set breakpoints, to step through the execution that would help to identify how the DBUF register content is being handled? I think this would help to determine why and where the conversion is happening.

    Moreover, I'm not sure whether I'm making correct sensor-to-handle assignments in my custom GATT Attribute Profile Table.  It seems that I have a handle mismatch in GATT Attribute Profile Table.  This custom table was created using the wiki "Tutorial: How to Create a Custom Bluetooth Smart Embedded Application with the CC2650DK."  So whats happening is that the data transmitted to handle 0x002D appears at handle 0x002E: this can be observed using the BLE Device Monitor, BTool or SmartRF Packet Sniffer--after flashing the corresponding hex file to the USB Dongle.  I can see how the GATT Attribute Profile Table is generated [static gattAttribute_t *_ProfileAttrTbl(SERVAPP_NUM_ATTR_SUPPORTED)...] and [bStatus_t *_AddService( uint32 services )].  May I ask for your help to identify where the sensor-to-handle assignment occurs?  Please advise.  Thanks.

  • 0 in reply to Dag.FF2
    TI__Guru** 105180 points
    Hello Dag,

    For the UART questions, please refer to my suggestions in the other thread.

    For your BLE question above, it's difficult to give a firm answer without a BLE air sniffer trace. Can you take a trace with the TI Packet Sniffer or similar sniffer?

    Best wishes