BT stack Memory leak

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
KoSa_1909416
Level 5
Level 5
Distributor - Marubun (Japan)
250 sign-ins 25 replies posted First solution authored

Hi All,
We are planning to create a program with similar functionality to " ble_wifi_introducer " .

[Background]
    Our application does not turn off the power once it has been turned on
    until something like a power outage occurs.

    On the other hand, while checking the WICED Studio Wi-Fi/Combo Forums,
    I found the following thread.


    https://community.cypress.com/message/156413#156413

    It seems that a memory leak occurs when the BT stack is repeatedly
    wiced_bt_stack_deinit and wiced_bt_stack_init .
    This thread still seems to be open.

[Question]
    Is the BT stack memory leak problem solved ?
    We believe that our product needs a fix for this issue.

    Software environment:
        - WICED 6.2.1 or 6.4

Best Regards,
       Sakagami

0 Likes
1 Solution
SheetalJ
Moderator
Moderator
Moderator
First comment on KBA 750 replies posted 500 likes received

Hello,

We have tested the memory leak problem internally and confirm that the problem exists. Needed fix is already done in WICED library and should be available for customers in next WICED release. If this is a blocking issue for customer, please get in touch with your local Cypress team in order to obtain the patch early. You can also create a technical support case in order to receive the patches.

I apologize for the delayed response.

View solution in original post

0 Likes
19 Replies
SheetalJ
Moderator
Moderator
Moderator
First comment on KBA 750 replies posted 500 likes received

Hello Sakagami,

Unfortunately we have not yet verified this memory leak problem.

Coming back to basic doubt, why do you want to re-initialize the BT stack? Also, did you notice the memory leak problem in latest WICED 6.2.1 or 6.4? The reported issue seems to be using WICED 6.1.

0 Likes
KoSa_1909416
Level 5
Level 5
Distributor - Marubun (Japan)
250 sign-ins 25 replies posted First solution authored

Dear SheetalJ san,
Thank you for your reply.

> why do you want to re-initialize the BT stack?

        As our product is an embedded device, it does not have enough memory.
        So it is necessary to free the memory area when it is no longer needed.
        Also, the number of times a BT connection request occurs cannot be predicted.

>Also, did you notice the memory leak problem in latest WICED 6.2.1 or 6.4?

        Yes.There are the memory leak problem(about 192 byte) in both WICKED version.

Best Regards,

Sakagami

0 Likes
KoSa_1909416
Level 5
Level 5
Distributor - Marubun (Japan)
250 sign-ins 25 replies posted First solution authored

Dear SheetalJ san,

I checked using the sample code in the thread below.

https://community.cypress.com/message/156413#156413

The amount of memory leak differs depending on

the OS and wiced_bt_cfg_buf_pool_t (buffer pool configuration ) used.

For example,

( WICED  6.4 )

        bt_memleak-CY8CKIT_062-FreeRTOS-LwIP => 186 byte

        bt_memleak-CY8CKIT_062-ThreadX-NetX   => 56 byte

Is it difficult to solve the memory leak problem ?

Best Regards,

Sakagami

0 Likes

SheetalJ_96 wrote:

Hello Sakagami,

Unfortunately we have not yet verified this memory leak problem.

Coming back to basic doubt, why do you want to re-initialize the BT stack? Also, did you notice the memory leak problem in latest WICED 6.2.1 or 6.4? The reported issue seems to be using WICED 6.1.

The basic doubt is why don't you verify it?

It just needs a few minutes to compile and run the test code.

(I even uploaded the test code to make it easier to verify).

The reason it was reported to WICED 6.1 is because it was the latest release when I reported the memory leak issue.

Remember that the memory leak is in closed source library!

If cypress don't want to fix the memory leak, no one else can fix it.

0 Likes
KoSa_1909416
Level 5
Level 5
Distributor - Marubun (Japan)
250 sign-ins 25 replies posted First solution authored

Dear SheetalJ san,

I'm sorry to rush you, but we are waiting for your reply.

Is it difficult to solve the memory leak problem ?

Best Regards,

Sakagami

0 Likes

Hello @SheetalJ_96​,

We would also need this fix as we would need to be able to start and stop the BT stack

Can you please advise on the status of this issue?

Thanks in advance,

Best regards

0 Likes

SheetalJ_96

This issue is currently blocking us, in relation to my other post here: How to handle BTM_LPM_STATE_LOW_POWER

De-initialising the stack when we don't actively need BLE is the only way I've found to avoid the READ_THREAD task to prevent the MCU to go into STOP mode, as it always makes a call to platform_mcu_powersave_disable then waits for the radio to send data over UART by default.

However I can definitely see the memory leak happening as well, just running wiced_bt_stack_init and wiced_bt_stack_deinit in a loop.

This is a blocker for our product which cannot meet its consumption target as long as the MCU is prevented to go into STOP mode by the BT stack.

I'm very worried about the WICED SDK and the fact that several critical problems such as this one are left unanswered for years. This is not the first time it happens.

Please advise regarding the actions considered by Cypress regarding this issue.

If possible, could we consider getting access to the source code so I can attempt to fix the problems I need fixed?

Thanks in advance for your support,

Best regards

0 Likes

I doubt if the BLE stack read thread would be directly calling the platform_mcu_powersave_disable API. My guess is, BLE stack read thread calls the MCU platform layer for reading a byte (platform_uart_receive_bytes) and that platform API might be blocking MCU low power entry. Could you please check your MCU platform UART driver and see if platform_uart_receive_bytes calls platform_mcu_powersave_disable? If it does, then you should be able to remove the powersave lock and poll the BT_HOST_WAKE line before deciding to enter MCU STOP mode.

0 Likes

What is READ_THREAD task. You can print the return address from which you are getting platform_mcu_powersave_disable. You can look up the elf file and disassembly to tell the functions from which this is call is made.

Thanks,

Venkat
PS: I have experience of taking several products from prototype to production with WICED. I am available for consulting work and you can reach me at

contact@packetp.com

What is READ_THREAD task

>> One of the threads in Bluetooth stack that's related to HCI UART data reading I believe.

0 Likes

You can disassemble the elf of your application and then search for all instances of invocation of platform_mcu_powersave_enable/platform_mcu_powersave_disable.

VENKATs-MBP: ~/build/wiced/wiced_6.2_mfi/WICED-Studio-6.2/43xxx_Wi-Fi/libraries/drivers/bluetooth : grep "powersave_enable\|powersave_disable" ~/tmp/pp_gatt_client-BCM94343WWCD2.s

800cd00: f001 f858 bl 800ddb4 :

800ddb6: 4b08 ldr r3, ; (800ddd8 <platform_mcu_powersave_disable+0x24>)

800ddbc: dc06 bgt.n 800ddcc <platform_mcu_powersave_disable+0x18>

800ddbe: 4907 ldr r1, ; (800dddc :

800dde2: 4a08 ldr r2, ; (800de04 <platform_mcu_powersave_enable+0x24>)

800ddec: dc06 bgt.n 800ddfc <platform_mcu_powersave_enable+0x1c>

800ddee: 4906 ldr r1, ; (800de08

==

Also you can disassemble the BT library and the search in the assembly for powersave_enable\|powersave_disable. I didn’t find any.

grep "powersave_enable\|powersave_disable" ~/tmp/bluetooth_low_energy.FreeRTOS.LwIP.ARM_CR4.release.S

Thanks,

Venkat

SheetalJ
Moderator
Moderator
Moderator
First comment on KBA 750 replies posted 500 likes received

Hello,

We have tested the memory leak problem internally and confirm that the problem exists. Needed fix is already done in WICED library and should be available for customers in next WICED release. If this is a blocking issue for customer, please get in touch with your local Cypress team in order to obtain the patch early. You can also create a technical support case in order to receive the patches.

I apologize for the delayed response.

0 Likes
KoSa_1909416
Level 5
Level 5
Distributor - Marubun (Japan)
250 sign-ins 25 replies posted First solution authored

Dear  SheetalJ san,
Thank you for your investigation.
I will create a technical support case in order to receive the patches.

Best Regards,
Sakagami

0 Likes

@SheetalJ 

Please may I obtain the patch for this memory leak issue. I am using WICED Version: Wiced_006.004.000.0061

Regards,
Rob

0 Likes
SheetalJ
Moderator
Moderator
Moderator
First comment on KBA 750 replies posted 500 likes received

Hi Rob,

As I mentioned in my above response, you will have to contact our Sales team or a technical case should work.

0 Likes

@SheetalJ 

Hi,

I tried to raise a case to begin with and I mentioned this thread. I asked for the patch and I got the following response from Greg in Cypress San Jose:

"I would recommend making the request through the thread you referenced below. The Apps Engineer will open up a case for you to handle the request"

It seems they don't have access to the patch and need you guys to action it.
Please, are you able to advise if you can supply the patch or to whom I need to approach for it?

Thank you.

Regards,

Rob

0 Likes

Hi Rob, 

Please check the private message in your inbox and provide the needed details.

0 Likes

@SheetalJ 

I have replied to your PM.

Regards,
Rob

0 Likes

Hi @SheetalJ ,

I am having an issue with the patch: when calling 

  1. wiced_bt_stack_init
  2. wiced_bt_stack_deinit
  3. wiced_bt_stack_init

The 2nd call to wiced_bt_stack_init leads to a Hardfault. Stepping out of the hardfault, it appears that the issue comes from the wiced_create_pool() routine.

image.png

 

Is that expected behavior with the Wiced SDK 6.6?

Thank you,

Best regards,

Ben

0 Likes