cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Smart Bluetooth

Anonymous
Not applicable

I'm running a modified version of the hello_sensor and and my application will occasionally loss connection to the client (phone)  this happens randomly and I was wandering if there is a way to see who terminated the connection client/server?

thank you

0 Likes
1 Solution
Anonymous
Not applicable

Hello. I'm sorry to hear that the reboots are still occurring.

Yes unfortunately you can't find what caused a reboot by just using our API.

Since you are using 20736S which is SIP module, you may indeed have the crystal warmup issue (not very probable though I think).

Have you ever tried to figure out if this was the problem?

I doubt the traces are causing the reboots. However according to you, you only experience the reboots when using traces, right?

===>> Actually, can you elaborate more on the situation of when you see a reboot happening? <<===

Have you ever tried running some other applications(e.g. unmodified, original hello_sensor) on your board and see if you get these reboots when using traces? If you still get reboots, it's probably the board.

Do you have any other board that you can test like our Tag 3 Evaluation board?

Because I didn't have any problems using your app on Tag 3. No disconnections, no reboots.

Although, I did have to change the GPIO pin used for the button for some reason.

Have you ever tried changing the GPIO pin that you are using?

At this point, I would do anything really to debug, no matter how improbable it may sound.

Also, try to add one feature at a time from scratch. (You've probably already developed this way).

Comment out whole chunks of code and start adding little by little.

I'm sorry I can't give you a definitive solution.

But I'll be happy to continue to brainstorm on this if you tell me more about the reboot situation.

It seems like we started talking about random disconnections in the beginning and then about random reboots.

Are they the same problem? Are disconnections caused by reboots?

If not, did you fix the disconnection problems?:)

Thanks.

James

View solution in original post

0 Likes
17 Replies
Anonymous
Not applicable

if you run debug traces, shouldn't it show you the disconnect reason? then you can match it with the BLE spec sheet.

0 Likes
Anonymous
Not applicable

how do I set-up debug traces, I'm using a bcm20736s and I'm programming it via an FTDI?

0 Likes
MichaelF_56
Moderator
Moderator

Take a look at the WICED Smart Quick Start Guide (SDK 2.x and TAG3 Board) 


There is also an encoded trace viewer built into the IDE.

0 Likes
Anonymous
Not applicable

I already have that enabled and when I do monitor the trace I don't get any error codes except those I put put in such as connection down. I've seen the term air trace over the forums, does this require extra hardware i.e. a packet sniffer or is it a matter of enabling it ?

0 Likes
Anonymous
Not applicable

Hello.

It is most likely that hello_sensor is the one that disconnects. Client, your phone, won't really disconnect unless it sends a disconnect request or gets out of the range.

As far as I know, there are two reasons why hello_sensor will disconnect.

Either hello_sensor will disconnect because of the connection idle timeout or because of the pending SMP request(pairing).

Are you pairing with hello_sensor? If not, disconnection probably occurs because of the latter reason.

In connection_up function:

   lesmp_pinfo->pairingParam.AuthReq  |= LESMP_AUTH_FLAG_BONDING;

   lesmp_sendSecurityRequest();

Either try pairing with hello_sensor or try commenting out these two lines if you want to prevent disconnections.

If you've changed this variable hello_sensor_stay_connected to be 0, then hello_sensor will disconnect after .con_idle_timeout (seconds) defined in the app configuration. The default value of hello_sensor_stay_connected is 1 and so unless you've changed this value, you really won't get disconnected from the connection idle timeout.

If you think your application is disconnecting because of the connection idle timeout, you can either put 0 for .con_idle_timeout in the configuration or call a function like bleprofile_StopConnIdleTimer. This is a function defined in the hello_sensor. You can define your own function similar to this and call it somewhere in your app.

I'm guessing your phone is not pairing with hello_sensor properly, hence the disconnection.

Let us know if this helps.

Thank you.

James

0 Likes
Anonymous
Not applicable

I do pair with hello_sensor and I've had the connection up for over a 1000 seconds and no disconnections and in some cases connection is down within 100. hello_sensor_stay_connected is set to 0 but I've also set con_idle_timeout to 0. Take it the sensor can't terminate a connection on it own? 

I had some more questions about pairing if you don't mind, I've not changed anything with regards to pairing from the example and I was wandering if it' possible to have pairing require a key so that when the phone requests to pair it's then prompted to enter a key/code sort of like classic Bluetooth?

on the topic of debugging my module will sometimes restart randomly for example after successfully flashing new code I remove the TX line and then restart the module to view the trace the module will restart sometimes for as much as 4 times before operating normally. I also have a button that triggers an interrupt, this is pulled down by an external 10k resistor, and I've noticed every now and again this interrupt will cause a restart and I was wandering if there was a way to see what caused the restart even is it's a varible that I can maybe write to nvram and then read on my next restart?

thank you 

0 Likes
Anonymous
Not applicable

Try changing hello_sensor_stay_connected back to 1. I believe you are right in that if you change .con_idle_timeout to 0, there will be no disconnection at least from the connection idle timeout. However since we don't know the source of disconnection, lets try to reduce the number of variables. See if disconnection still occurs even after you changed hello_sensor_stay_connected back to 1. If it does, then it is most likely either pairing or your interrupt that is causing the disconnections.

Now to eliminate the pairing as the cause of disconnection, try commenting out

   lesmp_pinfo->pairingParam.AuthReq  |= LESMP_AUTH_FLAG_BONDING;

   lesmp_sendSecurityRequest();


in connection_up function. If disconnection still happens, it is probably your interrupt that is the root cause unless you made other changes to hello_sensor.

In that case: What are you doing in the interrupt function? Which pin are you using for the button interrupt?

Your phone isn't likely causing the disconnection, but just curious which model are you using?

To answer your question about requiring key in pairing, there's something called passkey pairing.

Hello_sensor has everything set up for passkey pairing. You just need to uncomment the line that defines PASSKEY_PAIRING.

There is a little instruction for setting it up at the top of hello_sensor.c. The line that you need to uncomment appears right after the includes.

If you upload your code with indications to your changes to the original hello_sensor, I'll be happy to test it with various mobile devices here.

James

Anonymous
Not applicable

jamesle1

The interrupt function increments a value every time it' called, I had to do a software debounce with an if statement as the interrupt is called twice instead of just on the rising edge, this is a temp fix that works just now, it also starts high adv if connection is down and read the variable from nvram before is increments and write it back to nvram. I thought maybe it had something to do with nvram, so I tried commenting this out and this still happened.

I have a customs app running on a LG G2, I thought it was maybe the app but the app was tested using the Hello_Sensor example with no disconnections at all so it can't be that unless if LG's BLE chip has some disconnection parameters such a if connection is idle for x time disconnect, just guessing here.

I noticed something odd earlier, with regards to reboots at start, the app is will attempt ti reconnect to the module if connection is lost, so this means after a random reboot the app will try to reconnect, is it possible that the phone attempting to reconnect will cause issues if say the module is halfway through the create function?

while using an arduino I while back I had random reboots because I was running out of ram could this also be happening here, if so that wouldn't explain reboots at the start or when a reboot is followed by a series of subsequent reboots?

Thanks for the help with passkey, I'll start work on that just now and update you as to how that goes, I've also attached my code as you asked, thank you for all your help

0 Likes
Anonymous
Not applicable

I tried your dose counter.

It seems like it works fine. I don't have any problems with disconnections after a proper pairing.

But I've only tested when the device is idling.

I didn't know how to interact with dose_counter so I couldn't do anything else.

Can you tell me more about how to use the app?

My only guesses as to why you are having disconnection issues are pairing and MAYBE LG G2.

When you pair, do you see the BLE device as a paired device when you go to Bluetooth Setting?

Because when I paired with the device, I was able to stay connected without any disruptions.

Since Android devices have a wide range of hardware implementations, it can be your phone that is disconnecting. (but I doubt this is the problem)

But maybe LG's implementation of BLE stack is different from ours. I'm not sure about this one.

Have you tested your app on a different Android device?

As for the "reboots", I didn't experience this either.

I don't know how you are programming your Android app, but you can make it so that the app doesn't autoconnect after connection is lost unless this is one of your app's feature. However, I don't think this will cause any problems. I think it might be just ignored since the BLE device is not ready.

I was just skimming through your code (I'll take closer look later) but I did noticed that you never reset some of the variables you are using. (correct me if I'm wrong).

You've defined some variables to be UINT32 and it will take a very long time to reach the maximum values, but it can eventually create an overflow bug.

It might not be the biggest concern right now, but I thought it was something to fix later.

James

Anonymous
Not applicable

jamesle1

Dose counter measure the dose a user enters via the button using an interrupt connected to button and if the interrupt doesn't fire for 2 seconds this dose is then transmitted to the app if paired, if it's not paired the dose is saved in nvram. so all you need to do is pair with the device and register for either notifications or indication and you should get a number corresponding to your button presses. did you by any chance have a loop at the interrupt set up and see why it fires on both edges?

The module does pair with the device and does show up under paired devices. I'll be able to get another device next week I agree it's unlikely this is the cause, can I ask what you used for your testing?

The reboots are however my biggest issue atm, I was wandering if it's at all possible to to find out what caused the reboot, maybe a flag in a register somewhere?

these variables are used to hold time from the seconds timer and figured since I'm making use of deep sleep and the module under normal operation shouldn't be awake for more than a few minutes when I go to sleep they would all get reset but I'll start patchin this just in case, thank you. I was curious if you how an overflow would affect the module?

0 Likes
Anonymous
Not applicable

I used Nexus 7, 9, and iphone 5.

I've talked to few other FAE's about your issues.

For firing interrupts on both edges, it might be because of the switch bouncing.(but seems like you fixed this problem in your code)

pastedImage_0.png

But when I scoped the signal, it seemed to be clean. You might want to scope it yourself.

For the reboot problem, it might be crystal warmup issue(?) if you using a SIP design.

Re: Explanation of Crystal Warmup Issue

These are just conjectures; I'm sorry I can't answer your questions definitively.

As for the integer overflow, the value might loop around causing a logic error somewhere.

I don't think it will cause a major problem like shutting down the app.

I'll ask the developers if there are any flags indicating what caused the reboot.

James

0 Likes
Anonymous
Not applicable

jamesle1

Thanks for you response I'll start exploring the crystal but I'd appreciate if you can find out about the reboot flags

0 Likes
Anonymous
Not applicable

Hello again.

According to the developers, there are no such reboot flags unfortunately. Sorry.

Are you still having issues with the reboot?

If you are, can you elaborate more on that?

Do you think the random reboots are the cause of the disconnections?

Are there random reboots only when you are trying to view traces?

previously you said:

" on the topic of debugging my module will sometimes restart randomly for example after successfully flashing new code I remove the TX line and then restart the module to view the trace the module will restart sometimes for as much as 4 times before operating normally. "

It's hard to understand the bug, because when I run your code on Tag 3, I don't run into any problems.

Are you using SIP design?

James

0 Likes
Anonymous
Not applicable

The reboot are till occurring, I can only confirm the reboot when using traces unless if you think it's the trace causing reboots?I take it it's not possible at all then to find what caused a  reboot? I'm running the code on one of these EMRF-20736S, Breakout Board, Embedded Masters.

embeddedmasters

0 Likes
Anonymous
Not applicable

Hello. I'm sorry to hear that the reboots are still occurring.

Yes unfortunately you can't find what caused a reboot by just using our API.

Since you are using 20736S which is SIP module, you may indeed have the crystal warmup issue (not very probable though I think).

Have you ever tried to figure out if this was the problem?

I doubt the traces are causing the reboots. However according to you, you only experience the reboots when using traces, right?

===>> Actually, can you elaborate more on the situation of when you see a reboot happening? <<===

Have you ever tried running some other applications(e.g. unmodified, original hello_sensor) on your board and see if you get these reboots when using traces? If you still get reboots, it's probably the board.

Do you have any other board that you can test like our Tag 3 Evaluation board?

Because I didn't have any problems using your app on Tag 3. No disconnections, no reboots.

Although, I did have to change the GPIO pin used for the button for some reason.

Have you ever tried changing the GPIO pin that you are using?

At this point, I would do anything really to debug, no matter how improbable it may sound.

Also, try to add one feature at a time from scratch. (You've probably already developed this way).

Comment out whole chunks of code and start adding little by little.

I'm sorry I can't give you a definitive solution.

But I'll be happy to continue to brainstorm on this if you tell me more about the reboot situation.

It seems like we started talking about random disconnections in the beginning and then about random reboots.

Are they the same problem? Are disconnections caused by reboots?

If not, did you fix the disconnection problems?:)

Thanks.

James

View solution in original post

0 Likes
Anonymous
Not applicable

Hello.

Were you able to fix your problem?

James

0 Likes
Anonymous
Not applicable

While we still deal with the odd disconnection every now and again, the majority of this has been stopped by petting the watchdog timer in the interrupt as this was sometimes firing far too often resulting in issues, if I find any more details I'll update, thank you for your help

0 Likes