Hi,
I was able to do more tests using BLE_MONITOR_RTT and btmon.
Here are 3 captures from 2 phones (nexus 5 and huawei). The one from the
Nexus contains 3 successful connections followed by a failed one. Both
from nexus only contain 1 failed attempt. For each test, you'll find the
output of btmon and the capture from wireshark.
The files are available here :
https://seafile.codingfield.com/d/3e17cb3f43da4eedaefd/
Note that I observed that the connection is more often successful when
BLE_MONITOR_RTT is enabled than when it is disabled. Remember it was the
same with Debug/Release : there are more successful connections in Debug
than in Release.
It makes me think of a timing issue, but it's weird that it works better
when the code is supposed to run slower...
I hope you'll be able to make sense of these captures!
Thanks for your help!
JF
Le 15/06/2020 22:54, j...@codingfield.com a écrit :
Hi,
Sorry, I do not mean to spam this mailing list. I just wanted to say I
misread the article, and manage to use the monitor over RTT. I build
the tool rtt2pty, ran it and then launched "btmon -J nrf52" and I see
very detailed logs about BLE communication!
It's running late, I'll analyze them tomorrow evening.
Thanks for your help, and sorry for the spam :)
JF
Le 15/06/2020 22:25, j...@codingfield.com a écrit :
Hi again,
Ok, I had a look to BLE_MONITOR_RTT, but I can't figure out how to
enable it in my code (which does not use mynewt as RTOS) : at first,
the code did not compile. I tried to fix the compilation errors (for
example, I had to define struct File_methods and struct File).
Then, I built the code, but couldn't see any messages coming out of
JLinkRTTClient.
It is supposed to work with JLinkRTTClient, or do I need to use
btshell running on another nrf board? (I do not have a nrf52840 on
hands...).
By the way, I already use the RTT for logging, and manage to enable
some loggers some nimble. Are the same messages available using the
logger, or do I really need bt_monitor?
Thx!
JF
Le 15/06/2020 20:38, j...@codingfield.com a écrit :
Hi,
The ACK you're talking about, are they the "Rcvd Read" listed in the
capture?
If BLE_MONITOR_RTT means that nimble supports JLink RTT, then yes, I
have a console available. I'll try to enable it. I'll also have a
look
at the stats and how to use them.
Thanks for the pointers, I'll report to you as soon as I have more
information!
JF
Le 14/06/2020 23:18, Łukasz Rymanowski a écrit :
Hi,
so indeed your logs show that after trying to read include services
from
GATT service, something bad happened. Controller was able to ACK 2
following master packets then it stopped to send ACKs.
Do you have a console available? If so, does it show anything
interesting?
For further debugging I suggest to look at BLE_MONITOR_RTT to grab
hci logs
(https://www.codecoup.pl/blog/support-for-btmon-in-mynewt/)
With this we will know if response is still in the host or is in the
controller.
Then we could check some stats e.g. ble_ll_stats - maybe that could
show us
something interesting - but first let us see where it stuck.
Best
Łukasz
On Sun, 14 Jun 2020 at 21:06, <j...@codingfield.com> wrote:
Hi,
It looks like the attachements were dropped somewhere... You can
download them on my seafile instance :
https://seafile.codingfield.com/d/64d53a6ca6b44ae6b5d7/
It seems to fail during the discovery of the characteristics on the
device. From what I understand, it happens during the discovery of
Generic Access Profile and Generic Attributes Profile, which are
handled
by nimble.
I may be wrong, I'm a beginner with BLE and nimble!
Maybe the captures will make more sens to you?
Yeah, it's very strange that it works when the code is supposed to
run
slower... It makes me think of a timing or memory issue, but I
couldn't
find it...
Thanks,
JF
Le 14/06/2020 20:46, Łukasz Rymanowski a écrit :
> Hi,
>
> Thanks for the report, however looks like attachments are missing.
>
> First of all you need to understand what read fails i.e check handle
> and
> make sure that your application responds correctly.
> It is very suspicious that read works with -Og, but still I would focus
> on
> that failing read first.
>
> Thanks
> Lukasz
>
>
> On Sun, Jun 14, 2020, 20:25 <j...@codingfield.com> wrote:
>
>> Hello,
>>
>> I'm working on a firmware for the Pinetime, a smartwatch based on the
>> NRF52832. The code is written in C/C++ and uses FreeRTOS.
>> I've recently switched from the Nordic Softdevice to NimBLE as BLE
>> stack. I used the freertos port from the 'porting' folder of the
>> source
>> code of nimble.
>>
>> I did many test using my PC on Linux : it can connect and communicate
>> with the NRF52 without issue.
>> However, things are not that easy when I try to connect using Android
>> phone (I tried with a Huawei Psomething and my old Nexus5) : the
>> connection fails most of the time.
>>
>> I did a lot of debugging, logging, sniffing,.. and I still cannot
>> understand why it's not working as expected. Here are some of my
>> observations:
>>
>> - When Android successfully connects, I receive the following GAP
>> events : BLE_GAP_EVENT_CONNECT and then BLE_GAP_EVENT_CONN_UPDATE 2
>> times. The first update sets the connection interval to 6, the second
>> one to 40.
>> - When it fails, I receive only the BLE_GAP_EVENT_CONNECT event and
>> the
>> 1st BLE_GAP_EVENT_CONN_UPDATE.
>> - Using the sniffer, I noticed that the last packet is a read
>> request
>> from the phone. It looks like the NRF52 never respond to this last
>> read.
>> - It fails in the discovery steps (when the android phone discover
>> all
>> the services, characteristics and attributes) but not always at the
>> same
>> place.
>> - I noticed that the tasks (ll task and host task are not in
>> deadlock
>> BUT it looks like the radio ISR (ble_phy_isr() in ble_phy.c) is not
>> called anymore.
>> - When I build the very same code in DEBUG (-Og instead of -O3), it
>> works perfectly!
>>
>> You'll find in attachements 2 captures I did with Wireshark and the
>> NRF
>> Sniffer (running on a NRF52-DK), one failed and one successful attempt
>> to connect.
>>
>> I'm running out of idea to debug this further. Is there a
>> configuration
>> issue (there are so many parameters in syscfg.h)? What could I try?
>> Where should I search ? Do you need more info to understand the
>> issue?
>>
>> Could you help me fix this issue?
>>
>> Thanks,
>>
>> JF
