This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Change of ADV data in SDK 17

Hello 

We have an application that ADV every second and is based on SDK 14.

We are currently attempting to move to SDK 17. What I have noticed is that if I change and ADV data during advertisement by the help of new API function ble_advertising_advdata_update I see that there will be a delay of ±2 seconds (I see it in air trace) during which there will be no ADV at all.

Even when I configured ADV interval to be 100 milli and data rate change is 1 time at a second I see a delay of 2 seconds over the air until an updated data takes place.

The question is: Is that an expected behaviour? Is there any way to prevent this stop of ADV for 2 seconds?

  • KTM said:

    I put a break point in the main on the first line.

    I hit it so I assume there was a reset due to some error

    Breakpoints before having enabled the SoftDevice is fine - since it will not assert if it is not enabled and active.
    To clarify my last comment: you might very well use breakpoints to debug your application - the first part will behave as usual: when a breakpoint is encountered, the CPU is halted, and the debugger shows you the contents of different registers ol. at that time.
    However, the difference comes when the SoftDevice is active at this time, and thus does not get to run when it needs to in order to maintain a connection or other timing-critical obligations. This will cause the SoftDevice to assert the moment it is given back control of the CPU ( which happens as soon as you click "resume" on the debugger ). So, long story short: You may indeed use breakpoints, but it will cause the device to reset immediately when you leave an encountered breakpoint.

    KTM said:

    I hit it so I assume there was a reset due to some error

    This is a way I figure out that there is probably a device reset...

     When did you hit this breakpoint, did you hit it a first time when starting the application, and then again when attempting to update the advertising data?

    KTM said:
    Also within a function ble_advertising_advdata_update I put a point after sd_ble_gap_adv_set_configure call (i.e. on return) and never hit this line so I guess that the reset comes from sd_ble_gap_adv_set_configure

    As mentioned, this will work - you should encounter the breakpoint as usual - but the SoftDevice will assert immediately upon resuming the program.

    KTM said:
    How would you suggest to debug that?

    I would make sure that all SDK function that returns error codes are accounted for, and that their returned error values always is passed to an APP_ERROR_CHECK, to see if the code is anything other than NRF_SUCCESS.
    This way, you should see the exact error printed by your logger - along with which function that returned it - if an error different than NRF_SUCCESS is returned.
    Are you seeing anything at all being written to your logger when this behavior occurs?

    Best regards,
    Karl

  • did you hit this breakpoint, did you hit it a first time when starting the application, and then again when attempting to update the advertising data?

    Exactly

  • Then I must concur that it sounds like the device is resetting, most likely due to an error being generated in / by the update function.

    Karl Ylvisaker said:
    Are you seeing anything at all being written to your logger when this behavior occurs?

     
    Best regards,
    Karl

  • Are you seeing anything at all being written to your logger when this behavior occurs?

    No

    But I managed to take a GATTS example app (ble peripheral) and cal the function and did not observe any kind of delay I do in our app. So probably this is a problem on my side

    Sorry bothering you and thanks a lot for help

  • KTM said:
    No

    Thank you for clarifying this. Are you seeing anything being written to your logger at all when your program is running?

    KTM said:
    But I managed to take a GATTS example app (ble peripheral) and cal the function and did not observe any kind of delay I do in our app. So probably this is a problem on my side

    I too would think this - I have successfully tested this function myself, and I know of other cases in which it has been used successfully - so the question becomes what is causing this, and how to remedy it. I suspect that you might be inputting invalid parameters to the update function - however, this should result in an error message being written to your logger ( since you have DEBUG defined in the preprocessor defines ). If you are not seeing anything at all in the logger output when the device resets, then we need to take a closer look at that first, and resolve the seemingly separate logger issue.

    KTM said:
    Sorry bothering you and thanks a lot for help

    It is no problem at all, I am happy to help and not bothered at all by this. If you would like, I can still help you resolve this issue - but you need tell me more about your application, and what behavior you are seeing / not seeing.
    The more specific and elaborate you are, the easier it is for me to help you in a timely manner.

    Should you not want to continue this support ticket, you may also close it at any time.
    In that case, feel free to open a new ticket in the future if you should encounter any issues or questions!

    Best regards,
    Karl

Related