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.

CC256x + Bluetoopia + SMT32F4 porting

Guys,

I have weird problem. I succesfully ported Buetoopia FreeRTOS stack to STM32F4 using Keil and precombilled bluetopia library. 

That was succesfull and product is working correctly. Recently I moved whole software into open source and I would like to use gcc as compiller instead 

of uVision Keil.

I added proper Bluetopia library to the gcc project (compiled for gcc from Bluetopia/lib/gcc/libBluetopia_32_M3.a), so similar as in Keil project.

I also added proper for GCC and STM32F4 port.c and port.h files according to FreeRTOS documentation. Other code is exactly the same, only those changes was made. 

Project compiles succesfully, everything before MainThread creation is done, event part which is not connected to Bluetopia library in MainThread 

is working(some pin bitbanging, SPI communication, etc) but as soon as I get to this part of code:

...
static int OpenStack(HCI_DriverInformation_t *HCI_DriverInformation, BTPS_Initialization_t *BTPS_Initialization)
{
   int                        Result;
   int                        ret_val = 0;
   char                       BluetoothAddress[15];
   Byte_t                     Status;
   BD_ADDR_t                  BD_ADDR;
   HCI_Version_t              HCIVersion;
   L2CA_Link_Connect_Params_t L2CA_Link_Connect_Params;

   /* First check to see if the Stack has already been opened.          */
   if(!BluetoothStackID)
   {
      /* Next, makes sure that the Driver Information passed appears to */
      /* be semi-valid.                                                 */
      if((HCI_DriverInformation) && (BTPS_Initialization))
      {

         /* Initialize BTPSKNRl.                                        */
         BTPS_Init(BTPS_Initialization);

         /* Initialize the Stack                                        */
         Result = BSC_Initialize(HCI_DriverInformation, 0);

         /* Next, check the return value of the initialization to see if*/
         /* it was successful.                                          */
         if(Result > 0)
         {

..

which was taken from SPPDemo from bluetopia library, delivered by TI I get HardFaul_Handler. 

The SP does not point properly to function which caused HardFault, I know that, 

Result = BSC_Initialize(HCI_DriverInformation, 0);

causes that. In debbugger it just does not go forward. If I comment this and go further It agains called HaldFault_Handler as soon 

as some Bluetoopia code from precompilled library is called.

  • hi , we will assign the query to BT expert and get back to you
    Saurabh
  • hi , please let us know if you still need assistance with this issue
    Saurabh
  • Hi,

    same issue with same configuration (STM32F4 MCU, CC2564B chipset and GCC based IDE). The hardfault_handler occurs as soon as the static library is called (BSC_Initialize function). Any help would really be appreciated.

    Thank you,

    Daniele


  • Hi Saurabh,

    Yes issue is still there. I did not manage to fix it or to find the problem. Any kind of event path how to debug it 

    will be nice. Since static library is precompiled I cannot debug it and it's really hard to figure out what is wrong there. 
    Maybe you have some working example of such a configuration ?

  • Hi Rafal,

    In order to debug this issue, can you please place breakpoints in the following functions of the BTPSVEND.c and tell us which breakpoints are hit and which ones are not before the hard fault occurs.

    - HCI_VS_InitializeBeforeHCIOpen()
    - HCI_VS_InitializeAfterHCIOpen()
    - HCI_VS_InitializeBeforeHCIReset()
    - HCI_VS_InitializeBeforeHIClose()


    Since the BSC_Initialize() initializes all the BT stack layers and the HCI transport, the hardfault can be occuring from various sources. This can help eliminate some possibilities.

    BR,
    Vihang
  • Hi Vihang,

    Sorry for late answer but I did not have enough time to check this one. Right now I am working with the same 

    code but project is setup for Keil iuVision and everything works just fine.

    As soon as I reconfigure the project for GCC  I will check and let you know. For further investigation .What if I wont go throught single of those functions ? 

    That this mean that I having problems with my HCI layer ? How come if exactly the same code works for Keil ? 

    BR,

    Rafal

  • Rafal,

    Please update us when you get to check the GCC project again.

    Best regards,
    Vihang
  • Hi Vihang,

    Function which causes the problem is someting before this call: 

    HCI_VS_InitializeAfterHCIReset

    I checked and when HardFault occur I never get to the breakpoint here:

    Boolean_t BTPSAPI HCI_VS_InitializeAfterHCIReset(unsigned int HCIDriverID, unsigned int BluetoothStackID)
    {
       Boolean_t                        ret_val;
       HCI_Driver_Reconfigure_Data_t    DriverReconfigureData;
       HCI_COMMReconfigureInformation_t COMMReconfigureInformation;
    
       /* Verify that the parameters that were passed in appear valid.      */
       if((!VendorCommandsIssued) && (HCIDriverID) && (BluetoothStackID))

    ...

    When I pass this function, initialization works correctly ? What could be the problem that it's working sometimes 

    and sometimes it does not  ?

    Vihang said:
    Hi Rafal,

    In order to debug this issue, can you please place breakpoints in the following functions of the BTPSVEND.c and tell us which breakpoints are hit and which ones are not before the hard fault occurs.

    - HCI_VS_InitializeBeforeHCIOpen()
    - HCI_VS_InitializeAfterHCIOpen()
    - HCI_VS_InitializeBeforeHCIReset()
    - HCI_VS_InitializeBeforeHIClose()


    Since the BSC_Initialize() initializes all the BT stack layers and the HCI transport, the hardfault can be occuring from various sources. This can help eliminate some possibilities.

    BR,
    Vihang

  • Hi Rafal,

    From your update above, it looks like the gcc version of the libraries you are using is not able to send the HCI_Reset command. You might want to check in your HAL and HCITrans files.

    It is best to use the default libraries that are working out of the box.

    Best Regards,
    Vihang
  • I am using Bluetoopia version 4.0.1 and gcc version 4.8.5. 
    What do you mean that it cannot reset device. Same library used with Keil compiller works perfectly.

  • Rafal,

    Before initializing the Bluetooth controller, the bluetooth stack issues HCI_Reset command to the controller and once the response to this HCI_Reset command in received from the bluetooth controller, the stack passes rest of the initialization script to the controller over HCI UART. In the gcc case, either the stack is failing to issue the HCI_Reset command (less likely) or failing to properly trigger the UART interrupt for the return command (more likely). This in turn could cause the hard fault on the STM32F4 MCU. I am just pointing the possibilities here after eliminating other options from your previous debug steps. In order to verify, you might want to observe the HCI UART lines using a logic analyzer and compare it to the working case.

    I understand that the same library used with keil compiler works perfectly. A sample application will use the stack libraries and the hardware adaptation layer (for UART, gpio control etc.). Even though the libraries are the same, the HAL will depend on which compiler is used to build the final sample application.

    Again, you can debug this issue in HAL/HCITrans files using this info. In my opinion, it is best to use the default Keil/IAR compiler that works out of the box without any issues.

    Best regards,
    Vihang