Re: Nimble on NRF52 : connectivity issue with Android, stack seems to freeze

jf Wed, 17 Jun 2020 12:06:15 -0700

Hi,

I use the init functions found in porting/nimble andporting/npl/freertos. There are functions to handle semaphores, queues,timers,... Is there any issue with this freertos port, if it's notofficial? I did not write any code related to the radio or irq as itseems to be handled by these functions.


Here is the function I call in my main() to init nimble:

void nimble_port_init(void) {
  void os_msys_init(void);
  void ble_store_ram_init(void);
  ble_npl_eventq_init(&g_eventq_dflt);
  os_msys_init();
  ble_hs_init();
  ble_store_ram_init();

  int res;
  res = hal_timer_init(5, NULL);
  ASSERT(res == 0);
  res = os_cputime_init(32768);
  ASSERT(res == 0);
  ble_ll_init();
  ble_hci_ram_init();
  nimble_port_freertos_init(BleHost);
}

And BleHost():

void BleHost(void *) {
  struct ble_npl_event *ev;

  while (1) {
    ev = ble_npl_eventq_get(&g_eventq_dflt, BLE_NPL_TIME_FOREVER);
    ble_npl_event_run(ev);
  }
}

If you want to have a look at the complete code, it's hosted on Github.main() is in src/main.cpp, the nimble is in src/libs/mynewt-nimble :https://github.com/JF002/Pinetime


Is there anything specific I should check?

Thanks,

JF


Le 17/06/2020 10:35, Andrzej Kaczmarek a écrit :

Hi,

How did you setup interrupts on FreeRTOS (e.g. radio) and criticalsection?

These kinds of problems are common if you have misconfigured locking,

interrupt priorities or smth. Since we do not have any official portforFreeRTOS (there's only NPL but it does not deal with hardware) I assumeyou

did this on your own so would be good to know more details.

Best,
Andrzej


On Tue, Jun 16, 2020 at 8:29 PM <j...@codingfield.com> wrote:

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 fromthe

Nexus contains 3 successful connections followed by a failed one. Both

from nexus only contain 1 failed attempt. For each test, you'll findthe

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 wasthesame with Debug/Release : there are more successful connections inDebug

than in Release.

It makes me think of a timing issue, but it's weird that it worksbetter

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
>>>>>

Re: Nimble on NRF52 : connectivity issue with Android, stack seems to freeze

Reply via email to