smp_svr sample does not discover services #16735
Comments
|
@jhedberg Could you triage? |
|
Looks like this PDU is not getting a response from Zephyr: |
|
@jhedberg I checked out the latest master @ 23a6de5 and repeated steps above: this seems to solve the issue. Output is now as expected: Output from btmon now: |
|
Also services now get discovered correctly: Can this issue be closed then? |
Yes, I'd say so. I.e. my suspicion of this getting solved by #16612 was correct. |
|
The issue still exists on the latest master @ ab69044 with the same symptoms as described in Bug description. |
Do you have any zephyr logs, does other samples services work or is this specific to smp_svr? |
|
Environment : OS: Linux 4.18.0-25-generic #26~18.04.1-Ubuntu SMP x86_64 x86_64 x86_64 GNU/Linux hciconfig -a hci0: Type: Primary Bus: USB Good scenario with hci0(Cambridge Silicon Radio): Bad scenario with hci1(Intel): btmon_cambridge_silicon_radio_hci_ok.log |
|
So it doesn't work with Intel but works when connected with CSR? Does bluetoothctl produces the same results. |
|
Yes, works with CSR and doesn't with Intel. |
|
I am seeing the same thing, unfortunately I only have Intel, hence I can't connect. On a related note the Zephyr app I am developing has developed a bug between an older build and the current tip. Doing a git bisect the bug shows up when a change to the timers was made. I am using tickless kernel (hence the timer rate is 32kHz which counts as high). When the bug hits the timer interrupts disappear (my LEDs also stop blinking), I think the bluetooth stack is taking too long to do something while the timer is trying to setup the next interrupt, and the compare register gets set too late, hence missing the interrupt and stalling the system for 512 seconds. But I haven't got to the bottom of it yet... Here is the output of git bisect identifying the change: |
|
@lawrencek52 your timer bug might be fixed now, there was a comparator register fix posted: 9f34d17#diff-57dfbf11ae1437d7b0a30d68d709d8d6 |
|
@YuraCobain @lawrencek52 can you please retest on the latest master, since there have been multiple fixes to GATT? |
|
@carlescufi the issue still exists on Intel controller. |
|
@YuraCobain I just tested this with an Intel controller: This is my device: |
|
@YuraCobain can you please use |
carlescufi
added
priority: low
|
Lowering priority to low since this is not a blocker nor it is easily reproducible. |
|
As recently I have been using smp_svr a loot on nRF52 SoC's I can tell that it works fine, re-open if found it buggy again. |
Describe the bug
When following steps in the smp_svr example (https://docs.zephyrproject.org/latest/samples/subsys/mgmt/mcumgr/smp_svr/README.html#smp-svr-sample) and try to perform a ping to the target device, I get the following error:
To Reproduce
Expected behavior
Expected output:
Impact
showstopper, I cannot DFU the smp_svr example.
Screenshots or console output
The MCU bootloader and application are correctly flashed as I get expected output from the UART terminal on the device:
Output from BTmon when issuing
mcumgr --conntype ble --connstring peer_name=Zephyr echo hello:I have also tried connecting directly using bluetoothctl, it seems the smp_svr service is available so I don't know what is causing the problem:
Environment (please complete the following information):
Additional context
The text was updated successfully, but these errors were encountered: