• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 52 subscribers
  • Views 1284 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.

CC2564MODA: Problem implementing HCI using dma on stm32F4

Laurent CHENU87
Prodigy 30 points

Part Number: CC2564MODA
Other Parts Discussed in Thread: CC2564

Hello,

We have a custom board using STM32F4 and CC2564. We need to port the HCI to dma for application. We started out from the sources in the hcitrans.dma of the BlueTopia stack. We have noticed one inconsistency in teh sources:

The callback routine passed as argument to HCITR_COMOpen() is indicated as returning a value (which seems logical in order to implement some sort of flow control) in the comments above the function:

/* The following function is responsible for opening the HCI */
/* Transport layer that will be used by Bluetopia to send and receive*/
/* COM (Serial) data. This function must be successfully issued in */
/* order for Bluetopia to function. This function accepts as its */
/* parameter the HCI COM Transport COM Information that is to be used*/
/* to open the port. The final two parameters specify the HCI */
/* Transport Data Callback and Callback Parameter (respectively) that*/
/* is to be called when data is received from the UART. A successful*/
/* call to this function will return a non-zero, positive value which*/
/* specifies the HCITransportID that is used with the remaining */
/* transport functions in this module. This function returns a */
/* negative return value to signify an error. */
int BTPSAPI HCITR_COMOpen(HCI_COMMDriverInformation_t *COMMDriverInformation,
HCITR_COMDataCallback_t COMDataCallback, unsigned long CallbackParameter)

However it really is declared as "typedef void (BTPSAPI *HCITR_COMDataCallback_t)(unsigned int HCITransportID, unsigned int DataLength, unsigned char *DataBuffer, unsigned long CallbackParameter);" in file HCITRANS.h

What am I missing out here ?

Thank you for your help,

L.CHENU

  • 0
    TI__Mastermind 29361 points

    Hi,

    Laurent CHENU87 said:
    However it really is declared as "typedef void (BTPSAPI *HCITR_COMDataCallback_t)(unsigned int HCITransportID, unsigned int DataLength, unsigned char *DataBuffer, unsigned long CallbackParameter);" in file HCITRANS.h

    That is correct. This means that the callback function (implemented in the upper layers) will be void type. This is the convention used throughout the BT stack. For example, the callback function pointer in the SPP_Open_Server_Port API has the SPP_Event_Callback_t type but the SPP_Event_Callback_t type declaration in the SPPAPI.h is typedef void. So when implementing an SPP_Event_Callback function in an application, the function will be void type.

    Laurent CHENU87 said:
    We have a custom board using STM32F4 and CC2564. We need to port the HCI to dma for application. We started out from the sources in the hcitrans.dma of the BlueTopia stack

    I'd recommend using the existing HCITRANS.c files in the hcitrans.dma folder as a starting point and port your platform specific changes on it. This way you can follow how the HCITR_COMDataCallback_t COMDataCallback should be handled in the HCITRANS functions.

    Best regards,

    Vihang

  • 0 in reply to Vihang Parmar
    Prodigy 30 points
    Thank you Vihang for your reply.

    Your suggestion is exactly what I did and the fact that it is not working the reason why I posted my original message.
    We have a board which needs to use both BLE and A2DP and HFP profiles. After a big struggle we managed to implement A2DP and HFP_1.5 (which is the reason for the need of high bandwidth over HCI) but are facing distortions on A2DP when there are other communications over HCI (using SPP).
    With no other modifications to the original HCITrans.c file (in the dma directory) the setup works for A2DP but only at a specific baudrate for HCI. Rising the baudrate has it fail which, after digging into the code, lead me to the conclusion that as the COMDataCallback () never tells us when it cannot accept more data, we actually flood the upper layers.
    There a contradiction between comments in the source files, it seemed logical for the callback to provide some sort of information about whether it succeeded or not so as to adapt the bandwidth (as done in HFP for instance).

    Best Regards,
    Laurent
  • 0 in reply to Laurent CHENU87
    TI__Mastermind 30735 points
    Hi Vihang,

    Some more information on the customer use case:
    - Bluetopia stack v4.0.2.1
    - Goal is to have A2DP et HFP on the HCI channel (as BLE need to be used). A3DP and HFP1.6 can NOT be used.

    A.
  • 0 in reply to Laurent CHENU87
    TI__Mastermind 29361 points

    Laurent,

    Laurent CHENU87 said:
    After a big struggle we managed to implement A2DP and HFP_1.5 (which is the reason for the need of high bandwidth over HCI) but are facing distortions on A2DP when there are other communications over HCI (using SPP).

    First of all, the eSCO data (for HFP) will be routed through the PCM interface of the CC256x so the HFP should not have much impact on the HCI UART traffic. 

    Laurent CHENU87 said:
    With no other modifications to the original HCITrans.c file (in the dma directory) the setup works for A2DP but only at a specific baudrate for HCI. Rising the baudrate has it fail which, after digging into the code, lead me to the conclusion that as the COMDataCallback () never tells us when it cannot accept more data, we actually flood the upper layers.

    The callback function's task is to send the data/events coming from the controller to the upper protocol stack. Why would a callback function send any indication(some sort of flow control) to the UART drivers? It would be better to just adjust the UART buffer sizes in the hcitrans since the UART hardware flow control is based on that.

    The default HCI baud rate for all sample applications is 921600 for this SDK release I believe. It is possible that the hcitrans dma is "fine tuned" for these settings. Typical A2DP stream data rate (328 KBits/s) is way lower than 921600. Why would you need to use a higher baud rate for this application? 

    Laurent CHENU87 said:
    it seemed logical for the callback to provide some sort of information about whether it succeeded or not so as to adapt the bandwidth (as done in HFP for instance)

    Can you be more specific, where/what exactly in the HFP are you referring to?

  • 0 in reply to Vihang Parmar
    Prodigy 30 points

    Vihang said:

    First of all, the eSCO data (for HFP) will be routed through the PCM interface of the CC256x so the HFP should not have much impact on the HCI UART traffic. 

    Yes, however in our configuration our Codec is wired to the STM32 and we use SCO_Set_Physical_Transport(BluetoothStackID, sptHCI)

    Vihang said:
    The callback function's task is to send the data/events coming from the controller to the upper protocol stack. Why would a callback function send any indication(some sort of flow control) to the UART drivers? It would be better to just adjust the UART buffer sizes in the hcitrans since the UART hardware flow control is based on that.

    The default HCI baud rate for all sample applications is 921600 for this SDK release I believe. It is possible that the hcitrans dma is "fine tuned" for these settings. Typical A2DP stream data rate (328 KBits/s) is way lower than 921600. Why would you need to use a higher baud rate for this application? 

    I understand that. We took the original HCITrans.c file in the dma directory as is and are observing that the BT component sends us tons of data and at one point the whole just crashes. In theory and looking at the way the whole is set up this should not happen. The only way out we found was to fine tune the baudrate (466800 baud).

    Vihang said:
    Can you be more specific, where/what exactly in the HFP are you referring to?

    I was referring to 'HFRE_Send_Audio_Data()' that we use in our app, this call back does return different values upon success/failure (and the event etHFRE_Audio_Transmit_Buffer_Empty_Indication is only issued when the callback failed). I can provided log files of the xfers over HCI if needed.
    Best Regards, 
    Laurent

  • 0 in reply to Laurent CHENU87
    TI__Mastermind 29361 points

    Laurent CHENU87 said:
    Yes, however in our configuration our Codec is wired to the STM32 and we use SCO_Set_Physical_Transport(BluetoothStackID, sptHCI)

    The SCO over HCI is a legacy mode of operation and it is not recommended since the PCM (default mode) is more reliable. I am sure there are ways to route the PCM interface through the MCU.

    Laurent CHENU87 said:
    I understand that. We took the original HCITrans.c file in the dma directory as is and are observing that the BT component sends us tons of data and at one point the whole just crashes. In theory and looking at the way the whole is set up this should not happen. The only way out we found was to fine tune the baudrate (466800 baud).

    I see. If you need additional help debugging this on the MCU side, please contact one of our third party partners (i.e. Cloud2GND) who are will aware with the BT stack.

    Laurent CHENU87 said:
    I was referring to 'HFRE_Send_Audio_Data()' that we use in our app, this call back does return different values upon success/failure (and the event etHFRE_Audio_Transmit_Buffer_Empty_Indication is only issued when the callback failed). I can provided log files of the xfers over HCI if needed.

    The HFRE_Send_Audio_Data() is not a callback nor it has any parameter that expects a callback function pointer. It is not comparable to what you mentioned earlier about HCI layer APIs. 

    Moreover, please refer to my two comments above as they are applicable for this statement as well.

    BR,

    Vihang