Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

[MESH SDK] PB REMOTE - Device crash when provisionning

Hi,

I try to implement the PB Remote feature on device.

I have setup a pb remote server and a pb remote client on two devices. Both are configured.

But when a provisioning a device using the pb client and a pb remote as proxy, the currently provisioning device crash after the "Sending static auth keys" step but the pb client and server do not crashed and show a "provisioning failed" message.

On the crashed device, I have no callstack or log.

If I enable DEBUG & DEBUG_NR, I got : "<error> app: SOFTDEVICE: ASSERTION FAILED"

When I try to provisioning the device in "regular" mode, there is no issues.

Used softwares :

NRF SDK 17.1.0

MESH SDK 5.0.0

Regards

Parents
  • Hi,

    Feedback from the SoftDevice team is that the crash looks to be timeslot related. Timeslots are scheduled periods of time where the SoftDevice (the BLE stack) gives access to the radio (and other resources) to the application. This is used by the Bluetooth mesh stack in nRF5 SDK, for mesh operation. The assert indicates that resources were still held at the end of the timeslot, typically meaning the timeslot was overstayed.

    Do you by any chance have a sniffer trace from the communication between PB Remote Server and provisionee, that we can look into?

    Are you able to get logs out of the provisionee? (Using custom software if needed?)

    Please note that this is a public ticket. If there are things you cannot share publicly, then please let us know and we will change this into a private ticket.

    Regards,
    Terje

Reply
  • Hi,

    Feedback from the SoftDevice team is that the crash looks to be timeslot related. Timeslots are scheduled periods of time where the SoftDevice (the BLE stack) gives access to the radio (and other resources) to the application. This is used by the Bluetooth mesh stack in nRF5 SDK, for mesh operation. The assert indicates that resources were still held at the end of the timeslot, typically meaning the timeslot was overstayed.

    Do you by any chance have a sniffer trace from the communication between PB Remote Server and provisionee, that we can look into?

    Are you able to get logs out of the provisionee? (Using custom software if needed?)

    Please note that this is a public ticket. If there are things you cannot share publicly, then please let us know and we will change this into a private ticket.

    Regards,
    Terje

Children
  • Hi,

    Thanks for your answer.

    Do you by any chance have a sniffer trace from the communication between PB Remote Server and provisionee, that we can look into?

    How can I do that ?

    Are you able to get logs out of the provisionee? (Using custom software if needed?)

    I have my app logs but nothing interresting. Which log module can I enable to get more infos ?

    An other thing, I have Pa Lna active on my firmware, can it make a difference?

    Regards

  • Hi,

    I have snif the communication using Wireshark and Nrf Sniffer plugin.

    The device f4:94:c1:9c:f7:7a is the provisionner.

    The device e6:2b:5c:0e:59:6c is the PB Server.

    The device d5:b1:c0:06:0a:60 is the provisionee.

    3000.sniff.pcapng

    Regards

  • Hi,

    Thanks for the sniffer trace. I am not sure if we have everything for decoding the messages, but I will hear with the mesh team. Most likely we would need a trace from a professional sniffer, where you can provide the proper network, device, app keys for deobfuscating and decrypting the messages.

    Regarding the provisioning working for a DK, what application did you run on the DK? The difference may be either in the hardware, or in the software, or in both.

    PA / LNA module may make a difference, yes. I assume that you followed the instructions for adding a PA/LNA module, in the nRF5 SDK for Mesh documentation?

    Have you tried adding PA/LNA module to an SDK example to check if you make it work for the same application as was working with the DK?

    I will let you know if there are any log settings you can turn on for getting more information out of the logs.

    Regards,
    Terje

  • Hi,

    Most likely we would need a trace from a professional sniffer, where you can provide the proper network, device, app keys for deobfuscating and decrypting the messages.

    What kind of sniffer would do the trick? Is there any way to configure Nrf Sniffer Plugin to use the right network and apps keys to decode messages?

    Regarding the provisioning working for a DK, what application did you run on the DK? The difference may be either in the hardware, or in the software, or in both.

    I run the pb_remote and the provisionee on a custom board.

    I run the provisionner on a nrf52840 DK (and also on a NRF52840 Dongle, which is the final target for the provisioner)

    PA / LNA module may make a difference, yes. I assume that you followed the instructions for adding a PA/LNA module, in the nRF5 SDK for Mesh documentation?

    Yes I follow this documentation to adding it.

    Have you tried adding PA/LNA module to an SDK example to check if you make it work for the same application as was working with the DK?

    I have the PA/LNA active on the provisionee and the pb_remote but not on the provisioner.

    Regards

  • Hi,

    I have tried to disable the pa/lna on the provisionee but same issue, it crashed during the provisioning process.

    Regards

Related