SDK 2.2.2 and SDK 2.2.1 cause random disconnects/reconnects while SDK 2.2.0 does not ?

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

cross mob
ANa_2105331
Level 3
Level 3
5 likes given First like received First like given

Unfortunately it looks like the SDK 2.2.2 hasn't solved the issue of random disconnect/reconnects that we were seeing with SDK 2.2.1 but not with SDK 2.2.0.

As mentioned before, when we build our custom application using the SDK 2.2.0 we get a battery life with a CR2032 of 72+ hrs with no random disconnect/reconnects, while with the SDK 2.2.1 we get a battery life of 62+ hrs with anywhere from 50 to 100 random disconnect/reconnects. With everything else being the same the random disconnect/reconnects seen with SDK 2.2.1 is the culprit for the reduction in battery life. The SDK 2.2.2 was supposed to solve that.

I used the (.7z) version to import the SDK 2.2.2 into the OSX Eclipse IDE. I built our custom application on our board and I am seeing the same behavior with the random disconnect/reconnects seen with SDK 2.2.1.  The iPhone running our app to acquire the data is sitting right next to the board. The same board when built with SDK 2.2.0 exhibits no random disconnects/reconnects throughout the 72hr period.  I also separately built the SDK 2.2.2 on a laptop running Windows 7 and built our custom application on a different board and immediately noticed the same behavior.

This is rather unfortunate and disappointing since we have resolved almost all other issues and were hoping to freeze the firmware.  How do we resolve this ?

p.s.1 -  The random disconnect/reconnects are not a reboot of the board, so the data index count is maintained

p.s.2 - Our custom application is a modified heart_rate_monitor with a fine timer set at 200 ms.

1 Solution
Anonymous
Not applicable

Hello anavalgund,

1.  Since you are using the 200ms fine timer that will result in spikes during your advertisements

const BLE_PROFILE_CFG hello_sensor_cfg =

   /*.fine_timer_interval =*/ 200, // ms

2.  We fixed this to turn off the fine timer, so you can add the new SDK 2.2.2 patch disable_sw_timer_as_wake_source.a ?

3.  Make sure you are including the library file as shown in the list file or .asm file:

.. /tier2/brcm/libraries/lib/20736/disable_sw_timer_as_wake_source.a(disable_sw_timer_as_wake_source.o

  .. /.. /build/hello_sensor-BCM920736TAG_Q32-rom-ram-Wiced-release/lib_installer.o (install_patch_lm_ostimer_getTimeToSleep)

4.  We also added a KillTimer() as shown below as an example for another customer.

void hello_sensor_timeout(UINT32 arg)

  ble_trace1 (??? hello_sensor_timeout:%d ???, hello_sensor_timer_count);

  switch(arg)

  case BLEPROFILE_GENERIC_APP_TIMER:

  break;

  }

  bleprofile_KillTimer();

Hope this helps with your current issues.

JT

View solution in original post

12 Replies
Anonymous
Not applicable

Hello anavalgund,

1.  Since you are using the 200ms fine timer that will result in spikes during your advertisements

const BLE_PROFILE_CFG hello_sensor_cfg =

   /*.fine_timer_interval =*/ 200, // ms

2.  We fixed this to turn off the fine timer, so you can add the new SDK 2.2.2 patch disable_sw_timer_as_wake_source.a ?

3.  Make sure you are including the library file as shown in the list file or .asm file:

.. /tier2/brcm/libraries/lib/20736/disable_sw_timer_as_wake_source.a(disable_sw_timer_as_wake_source.o

  .. /.. /build/hello_sensor-BCM920736TAG_Q32-rom-ram-Wiced-release/lib_installer.o (install_patch_lm_ostimer_getTimeToSleep)

4.  We also added a KillTimer() as shown below as an example for another customer.

void hello_sensor_timeout(UINT32 arg)

  ble_trace1 (??? hello_sensor_timeout:%d ???, hello_sensor_timer_count);

  switch(arg)

  case BLEPROFILE_GENERIC_APP_TIMER:

  break;

  }

  bleprofile_KillTimer();

Hope this helps with your current issues.

JT

Anonymous
Not applicable

Hi anavalgund,

About the disable_sw_timer_as_wake_source.a :

j.t's spike solution did not solve my problem on our board, did you use the lib to solve that problem successfully? If yes, I will re-check my code in more detail. If not...maybe we need to wait SDK-2.2.3 or something.

0 Likes

So far calling the disable_sw_timer_as_wake_source.a patch in the Make file doesn't seem to have solved the issue of random disconnects/reconnects.  I have ensured the proper SDK 2.2.2 build configurations, ensured I run the clean before the build and so forth.

However the battery life seems to have improved despite the numerous random disconnects/reconnects. I did manage to get 84 hrs with a CR2032 over the weekend,  previously I was stuck around the 62+ hr mark with the SDK 2.2.1.

0 Likes
Anonymous
Not applicable

Hello Anavalgund,

The random connects/disconnects are probably an iOS issue, but I will have someone look into this.

It will take some time to reproduce this, but we will give it a try.

Thanks

JT

0 Likes

I have a strange phenomenon going on, out of 10 custom boards with the 20736S chips, for 6 of them the (disable_sw_timer_as_wake_source.a ) patch is working perfectly well with the SDK 2.2.2, with no disconnects whatsoever.   However for 4 of the custom boards when loading the firmware with SDK 2.2.2 the download works perfectly fine but it never talks to the IOS app, I can see it advertising but when we interrogate it, it falls through. However here is the strange part, for these same custom boards which fail with SDK 2.2.2 or for that matter SDK 2.2.1, when loaded with SDK 2.2.0 the exact same firmware works perfectly well, the boards communicate with the app,  I have reproduced it multiple times now and this is quite vexing. Is it something to do with the chips themselves ?

0 Likes
Anonymous
Not applicable

Hello anavalgund,

1.  Have you tried the crystal warm-up code work-around: Crystal Warmup help

2.  Did you clean before your compiled your code?  I made the mistake of not cleaning and the build process never picked up the patch.

Hope this helps,

JT

Thanks J.T for the suggestions.

The Crystal Warmup sounded promising, since for the SDK 2.2.2, it was set at 2800 in the mandatory.cgs file whereas for SDK 2.2.0 it was at 5000.

Did the change, saved the files, did a clean, closed and restarted the IDE, did a clean again and downloaded the firmware on the troubled boards - same outcome- the boards show up advertising, I can connect to it briefly but then they keep cycling in this loop of disconnecting, connecting back again.  I then proceeded to do the same download keeping the 5000 crystal warm up for the good boards and they retained their goodness and connect very nicely. 

When I proceeded to download the firmware on the troubled boards with the SDK 2.2.0, these boards work great.  The condition is the Crystal warmup time needs to be 5000, if it is 2800 here the boards do not do the cycle of connecting/disconnecting but remain disconnected post first connection.

Would appreciate any other places to look at ?

Clean has definitely become a second nature for me, do it everytime I make a change, or switch SDK's and in between downloads.

0 Likes
Anonymous
Not applicable

Hello anavalgund,

Which version of iOS are you running?

JT

0 Likes

Hi J.T, We are running IOS 9.2 on the devices.

0 Likes

Thanks for all your help j.t, I believe a combination of the two solutions the disable_sw_timer_as_wake_source.a patch and the Crystal warm up time has seemed to solved the issues.

The issue got really resolved when I switched from USB power to an external battery connected power source for the rebel boards. While the good boards were happy with the USB power, the rebel boards were not and were acting all wonky until I reprogrammed them and switched to battery power. 

Regards,

Anand

Anonymous
Not applicable

Great news!

Glad you got it working.

JT

0 Likes