Change in 4343W BLE physical layer performance from 4.0 to 5.2?

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

cross mob
rashc_2727106
Level 4
Level 4
10 likes received First like received First like given

We recently upgraded the firmware for our 4343W-based product from WiCED sdk v4.0 to 5.2 on the way to 6.2.   There were some hurdles to jump through to get things building and running because of the resource changes (e.g.. the clm_blob), but we passed a quick verification of our system performance as we continued our upgrades onto v6.2.

But we recently noticed a sharp drop in the reliability of BLE scanning and pairing when trying to connect to the 4343W from our mobile apps.  We traced to the change between v4.0  and 5.2 version.  Specifically on the same hardware and same antenna, our apps (both iOS and Android) scan and pair reliably with our 4.0 firmware build and struggle to find our hardware or maintain pairing with it for more than a few 10's of seconds with the 5.2 build.

The 5.2 release notes do not mention any changes in the BLE firmware or API. 

So before we dive in and try to figure this out, wanted to see if anyone else has run into anything similar.

0 Likes
1 Solution
rashc_2727106
Level 4
Level 4
10 likes received First like received First like given

So an update for this thread.

We were investigating BLE performance for debug builds specifically because our existing app (which worked reliably from android or iOS against wiced SDK versions before 5.2) was struggling to maintain a BLE connection.  We were finally able to track this down to some ugly legacy code inside our source that was calling wiced_rtos_delay_milliseconds from inside a timer context ( a no-no with ThreadX).  That manifested as a BLE stack failures because level 0 priority threads were being delayed.

So in short -  this was not a BLE radio performance issue at all.

View solution in original post

0 Likes
6 Replies
rashc_2727106
Level 4
Level 4
10 likes received First like received First like given

Don't have an ultimate cause yet, but latest testing reveals this is NOT a v5.2 versus v4.0 issue but rather a debug build vs release build issue.

We don't have any extra logging turned on for our debug builds, so this difference isn't due to e.g. logging load.

But this diff sure hints at some part of the BLE stack getting starved or missing some timing.

We'll investigate further.

0 Likes

Adding yssu and a few other members of the Applications team so they can review:  grsr riya rroyzhez zhxh yans kavs shjl

0 Likes

It's really very hard to report stability issues regarding BLE stack.

The thing is the BLE stack output does not help too much.

e.g.

https://community.cypress.com/thread/34514

Do you consider to produce more verbose debug information so at least

your developer can understand what is going on when people hit issues.

Since we didn't hear back from Cypress about any generally known issue with debug builds, we did run some experiments where we disabled all of our code except for the BLE thread.  So the most obvious sources of resource starvation were removed.  And we still see the issue. 

Thanks for the link axel.lin_1746341​ 

I'll see I can connect what we're seeing with that issue.

0 Likes

FYI, I also reported a issue that BLE silently stop working 1 year ago:

Re: SDK-5.1: ble scan stop working if large bufer max-used count becomes 1

No further feedback, so I think the issue is still there.

0 Likes
rashc_2727106
Level 4
Level 4
10 likes received First like received First like given

So an update for this thread.

We were investigating BLE performance for debug builds specifically because our existing app (which worked reliably from android or iOS against wiced SDK versions before 5.2) was struggling to maintain a BLE connection.  We were finally able to track this down to some ugly legacy code inside our source that was calling wiced_rtos_delay_milliseconds from inside a timer context ( a no-no with ThreadX).  That manifested as a BLE stack failures because level 0 priority threads were being delayed.

So in short -  this was not a BLE radio performance issue at all.

0 Likes