NRF52832 SDK 17 NUS LESC problem

[DmitrySol]

Hi.

NRF52832 is used as central for connecting with phones as peripheral.
NUS service is used. Lesc is used too.

SDK 17
SoftDevice S132 V7.0.1

I have sometimes crash of application.
I suppose it is crash of softdevice.
there aren't any logs in that time.
Application is just restarting in random times (every 1 - 15 minutes).
Breakpoint on NVIC_SystemReset() doesn't catches too.
Size of stack was increased. So i think perhaps sd has crashed in that time.

How can i find cause of that?
Thanks for any suggestions.

Another strange thing is that after resetting chip in this cases
resolving of private resolved address doesn't work (im_address_resolve).
(it is usually actual for one phone from two. phone1 is connecting successfully, another phone has not resolved address.)

[Edvin]

Try to add DEBUG to your preprocessor definitions, and monitor the log.

If you aren't sure how to add preprocessor definitions, please let me know what IDE you are using. Segger Embedded Studio? Keil?

If you are not sure how to monitor or enable the log, let me know.

Best regards,

Edvin

[DmitrySol]

Hi!

DEBUG was present in preprocessor directives.
Reset problem is solved now. (It is described above)

I have another question.
When chip as central is connected with phone ( as peripheral)
disconnection appears sometimes:

<info> app: ble_nus_c_evt_handler(): conn_handle=0x0, evt_type=0x2
<info> app: BLE_NUS_C_EVT_DISCONNECTED: 0x0
<info> app: BLE_GAP_EVT_DISCONNECTED: 1 , reason=0x13

0x13 means:
#define BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION 0x13 /**< Remote User Terminated Connection. */

It happens on old phone (BQ-5001L ble 4.0).
I seem that another phone (more modern) doesn't has this issue.

What may be caused of that disconnection?

[DmitrySol]

Good day! Edvin.

Thanks for your helping.

The matter is - when disconnections appears, that is cycling every few seconds.
So I can't catch address in list of wireshark.

Could I set address of central device as not private random (for debugging). and use it for filtering in wireshark?
If is it possible, how can i set that?

And the next question:
Could you advice a variant of self testing for factory testing.
I mean testing RF part, accuracy of quartz. Perhaps do you have application note for that?

Thanks!

[Edvin]

Hello,

It is not possible to filter on a central device, unfortunately.

I assume you want to use the sniffer trace to figure out what's wrong. Please be aware that when the link is encrypted using LESC, the sniffer will not be able to sniff the connection anyway, since sniffer devices can't keep up with LESC, because of it's nature. It could keep up for some time (with undecrypted packages), but eventually it can't keep up with the channel switching, so it will loose the connection. 

My advice to you is to try to debug the application. 

 

I have sometimes crash of application.
I suppose it is crash of softdevice.
there aren't any logs in that time.

 Do you have logging enabled in your application at all? Are you sure it doesn't say something like "fatal error"?

Is there some way for me to replicate this on a DK?

Is it the nRF that crashes? What do you see on the phone? Does it just disconnect? Have you tried connecting via nRF Connect for Android/iOS? Does it give a disconnect reason?

Do you see any disconnect reason on the nRF? Does the disconnect event occur at all?

Best regards,

Edvin

[DmitrySol]

Edvin said:

My advice to you is to try to debug the application. 

Ok. I see.

Edvin said:

have sometimes crash of application.

It is solved. I wrote above. External reset signal on the reset pin was the cause.

Disconnections on old phone is another problem.

Edvin said:

Do you see any disconnect reason on the nRF?

app: BLE_GAP_EVT_DISCONNECTED: 1 , reason=0x13

And the next question:
Could you advice a variant of self testing for factory testing.
I mean testing RF part, accuracy of quartz. Perhaps do you have application note for that?

[Edvin]

DmitrySol said:

Could you advice a variant of self testing for factory testing.
I mean testing RF part, accuracy of quartz. Perhaps do you have application note for that?

 I am no HW expert. I suggest you create a new ticket for this. That way, you don't have to listen to me trying to explain something to you that a colleague told me, which I don't understand myself. 

Does that mean that the disconnect issue still remains? If so, we are back to the disconnect reason 13. I just checked, and actually, if you disconnect from the nRF yourself, you will receive a disconnect reason 0x16 (BLE_HCI_LOCAL_HOST_TERMINATED_CONNECTION), and not 0x13 (BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION).

So if you see disconnected reason 0x13 on the nRF, it means that the phone decided to disconnect. Perhaps you can try to connect to it with nRF Connect for Android/iOS, and see if it disconnects, and if so, what the reason (should be printed in the log in nRF Connect for iOS/android).

BR,

Edvin

[DmitrySol]

hi

Edvin said:

 I am no HW expert. I suggest you create a new ticket for this. That way, you don't have to listen to me trying to explain something to you that a colleague told me, which I don't understand myself. 

ok

Edvin said:

So if you see disconnected reason 0x13 on the nRF, it means that the phone decided to disconnect. Perhaps you can try to connect to it with nRF Connect for Android/iOS, and see if it disconnects, and if so, what the reason (should be printed in the log in nRF Connect for iOS/android).

0x13  is used in app code too.

The issue can be closed now.

we'll try to debug phone application later.