You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by jf...@codingfield.com on 2020/06/14 18:24:45 UTC
Nimble on NRF52 : connectivity issue with Android, stack seems to
freeze
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
Posted by Łukasz Rymanowski <lu...@codecoup.pl>.
Hi Mo Chen,
I'm actually using Mynewt OS where OTA is supported when using MCUBoot.
Maybe worth considering using MCUBoot?
Best
Łukasz
On Mon, 15 Jun 2020 at 17:19, Mo Chen <sh...@gmail.com> wrote:
> Hi Lukasz,
>
> We are also trying FreeRTOS + Nimble on nrf52. Have you realized DFU OTA
> via BLE with FreeRTOS? We are not sure if this is something doable.
>
> Thanks,
>
> On Sun, Jun 14, 2020 at 4:19 PM Łukasz Rymanowski <
> lukasz.rymanowski@codecoup.pl> wrote:
>
> > 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, <jf...@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 <jf...@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
> > >
> >
>
>
> --
> Mo Chen
>
Re: Nimble on NRF52 : connectivity issue with Android, stack seems to freeze
Posted by Mo Chen <sh...@gmail.com>.
Maybe I should direct my question to JF then.
Thanks for your reply.
Mo Chen
On Mon, Jun 15, 2020, 10:18 Mo Chen <sh...@gmail.com> wrote:
> Hi Lukasz,
>
> We are also trying FreeRTOS + Nimble on nrf52. Have you realized DFU OTA
> via BLE with FreeRTOS? We are not sure if this is something doable.
>
> Thanks,
>
> On Sun, Jun 14, 2020 at 4:19 PM Łukasz Rymanowski <
> lukasz.rymanowski@codecoup.pl> wrote:
>
>> 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, <jf...@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 <jf...@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
>> >
>>
>
>
> --
> Mo Chen
>
Re: Nimble on NRF52 : connectivity issue with Android, stack seems to freeze
Posted by Mo Chen <sh...@gmail.com>.
Hi Lukasz,
We are also trying FreeRTOS + Nimble on nrf52. Have you realized DFU OTA
via BLE with FreeRTOS? We are not sure if this is something doable.
Thanks,
On Sun, Jun 14, 2020 at 4:19 PM Łukasz Rymanowski <
lukasz.rymanowski@codecoup.pl> wrote:
> 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, <jf...@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 <jf...@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
> >
>
--
Mo Chen
Re: Nimble on NRF52 : connectivity issue with Android, stack seems to freeze
Posted by Andrzej Kaczmarek <an...@codecoup.pl>.
Hi,
Your changes look good, I think it should work just fine.
Just fyi, in theory you could use basepri with NimBLE controller if you set
radio irq priority to 1 and lower any other priorities below that one.
However, this requires extra care to make sure there are no irqs set to
priority 0 since we really want radio irq to have the lowest latency
possible. So unless you really need some irqs to be enabled all the time,
using primask instead of basepri is a simpler option imo.
Best,
Andrzej
On Fri, Jun 19, 2020 at 10:23 PM <jf...@codingfield.com> wrote:
> Hi,
>
> And thanks Andrzej for this advanced analysis of my code! I've never dug
> this deep in FreeRTOS and ARM interrupts, so, I did some researches.
>
> If I understand correctly, BASEPRI allows to mask all interrupts with a
> priority lower than the value of the register, while PRIMASK masks all
> the interrupts.
> Using PRIMASK is slower (and induce a higher IRQ lantency) but BASEPRI
> does not allow to mask IRQ 0, which is needed by nimble to mask the
> radio IRQ. Am I right?
>
> So, I found out that port of FreeRTOS for Cortex-M4 uses BASEPRI
> (because it's faster) and, as BASEPRI is not available on Cortex-M0, the
> port for Cortex-M0 uses PRIMASK.
> Then, I tried to change the macro portENABLE_INTERRUPTS() and
> portDISALE_INTERRUPTS from
>
> #define portDISABLE_INTERRUPTS() vPortRaiseBASEPRI()
> #define portENABLE_INTERRUPTS() vPortSetBASEPRI(0)
>
> to (code from Cortex-M0 port):
>
> #define portDISABLE_INTERRUPTS() __asm volatile ( "
> cpsid i " ::: "memory" )
> #define portENABLE_INTERRUPTS() __asm volatile ( "
> cpsie i " ::: "memory" )
>
> and... connection from Android seems to be a lot more reliable! And the
> rest of the application seems to work correctly.
>
> Do you think my modification is complete and safe? I don't think
> interrupt latency will be a big deal in my application.
>
> Thanks a lot for your help!
>
> Le 19/06/2020 14:20, Andrzej Kaczmarek a écrit :
> > Hi,
> >
> > I just quickly looked through the code and it seems that your FreeRTOS
> > port
> > uses basepri for critical sections. The problem here is that radio irq
> > has
> > priority 0 so it cannot be blocked by basepri, that's one reason why
> > NPL
> > uses primask for its own macros. One function that can be affected in
> > particular is npl_freertos_eventq_remove() which uses FreeRTOS calls to
> > enter critical section so if some corner case it can be called from
> > both
> > ISR and task context messing up queue contents, although other calls
> > may
> > have the same problem due to basepri usage in general. That could
> > explain
> > problems which appear only in certain build configurations since they
> > are
> > triggered by timing.
> >
> > Best,
> > Andrzej
> >
> >
> >
> > On Wed, Jun 17, 2020 at 9:05 PM <jf...@codingfield.com> wrote:
> >
> >> Hi,
> >>
> >> I use the init functions found in porting/nimble and
> >> porting/npl/freertos. There are functions to handle semaphores,
> >> queues,
> >> timers,... Is there any issue with this freertos port, if it's not
> >> official? I did not write any code related to the radio or irq as it
> >> seems 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 critical
> >> > section?
> >> > These kinds of problems are common if you have misconfigured locking,
> >> > interrupt priorities or smth. Since we do not have any official port
> >> > for
> >> > FreeRTOS (there's only NPL but it does not deal with hardware) I
> assume
> >> > you
> >> > did this on your own so would be good to know more details.
> >> >
> >> > Best,
> >> > Andrzej
> >> >
> >> >
> >> > On Tue, Jun 16, 2020 at 8:29 PM <jf...@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 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, jf@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, jf@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, jf@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, <jf...@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 <jf...@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
Posted by jf...@codingfield.com.
Hi,
And thanks Andrzej for this advanced analysis of my code! I've never dug
this deep in FreeRTOS and ARM interrupts, so, I did some researches.
If I understand correctly, BASEPRI allows to mask all interrupts with a
priority lower than the value of the register, while PRIMASK masks all
the interrupts.
Using PRIMASK is slower (and induce a higher IRQ lantency) but BASEPRI
does not allow to mask IRQ 0, which is needed by nimble to mask the
radio IRQ. Am I right?
So, I found out that port of FreeRTOS for Cortex-M4 uses BASEPRI
(because it's faster) and, as BASEPRI is not available on Cortex-M0, the
port for Cortex-M0 uses PRIMASK.
Then, I tried to change the macro portENABLE_INTERRUPTS() and
portDISALE_INTERRUPTS from
#define portDISABLE_INTERRUPTS() vPortRaiseBASEPRI()
#define portENABLE_INTERRUPTS() vPortSetBASEPRI(0)
to (code from Cortex-M0 port):
#define portDISABLE_INTERRUPTS() __asm volatile ( "
cpsid i " ::: "memory" )
#define portENABLE_INTERRUPTS() __asm volatile ( "
cpsie i " ::: "memory" )
and... connection from Android seems to be a lot more reliable! And the
rest of the application seems to work correctly.
Do you think my modification is complete and safe? I don't think
interrupt latency will be a big deal in my application.
Thanks a lot for your help!
Le 19/06/2020 14:20, Andrzej Kaczmarek a écrit :
> Hi,
>
> I just quickly looked through the code and it seems that your FreeRTOS
> port
> uses basepri for critical sections. The problem here is that radio irq
> has
> priority 0 so it cannot be blocked by basepri, that's one reason why
> NPL
> uses primask for its own macros. One function that can be affected in
> particular is npl_freertos_eventq_remove() which uses FreeRTOS calls to
> enter critical section so if some corner case it can be called from
> both
> ISR and task context messing up queue contents, although other calls
> may
> have the same problem due to basepri usage in general. That could
> explain
> problems which appear only in certain build configurations since they
> are
> triggered by timing.
>
> Best,
> Andrzej
>
>
>
> On Wed, Jun 17, 2020 at 9:05 PM <jf...@codingfield.com> wrote:
>
>> Hi,
>>
>> I use the init functions found in porting/nimble and
>> porting/npl/freertos. There are functions to handle semaphores,
>> queues,
>> timers,... Is there any issue with this freertos port, if it's not
>> official? I did not write any code related to the radio or irq as it
>> seems 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 critical
>> > section?
>> > These kinds of problems are common if you have misconfigured locking,
>> > interrupt priorities or smth. Since we do not have any official port
>> > for
>> > FreeRTOS (there's only NPL but it does not deal with hardware) I assume
>> > you
>> > did this on your own so would be good to know more details.
>> >
>> > Best,
>> > Andrzej
>> >
>> >
>> > On Tue, Jun 16, 2020 at 8:29 PM <jf...@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 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, jf@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, jf@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, jf@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, <jf...@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 <jf...@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
Posted by Andrzej Kaczmarek <an...@codecoup.pl>.
Hi,
I just quickly looked through the code and it seems that your FreeRTOS port
uses basepri for critical sections. The problem here is that radio irq has
priority 0 so it cannot be blocked by basepri, that's one reason why NPL
uses primask for its own macros. One function that can be affected in
particular is npl_freertos_eventq_remove() which uses FreeRTOS calls to
enter critical section so if some corner case it can be called from both
ISR and task context messing up queue contents, although other calls may
have the same problem due to basepri usage in general. That could explain
problems which appear only in certain build configurations since they are
triggered by timing.
Best,
Andrzej
On Wed, Jun 17, 2020 at 9:05 PM <jf...@codingfield.com> wrote:
> Hi,
>
> I use the init functions found in porting/nimble and
> porting/npl/freertos. There are functions to handle semaphores, queues,
> timers,... Is there any issue with this freertos port, if it's not
> official? I did not write any code related to the radio or irq as it
> seems 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 critical
> > section?
> > These kinds of problems are common if you have misconfigured locking,
> > interrupt priorities or smth. Since we do not have any official port
> > for
> > FreeRTOS (there's only NPL but it does not deal with hardware) I assume
> > you
> > did this on your own so would be good to know more details.
> >
> > Best,
> > Andrzej
> >
> >
> > On Tue, Jun 16, 2020 at 8:29 PM <jf...@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 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, jf@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, jf@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, jf@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, <jf...@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 <jf...@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
Posted by jf...@codingfield.com.
Hi,
I use the init functions found in porting/nimble and
porting/npl/freertos. There are functions to handle semaphores, queues,
timers,... Is there any issue with this freertos port, if it's not
official? I did not write any code related to the radio or irq as it
seems 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 critical
> section?
> These kinds of problems are common if you have misconfigured locking,
> interrupt priorities or smth. Since we do not have any official port
> for
> FreeRTOS (there's only NPL but it does not deal with hardware) I assume
> you
> did this on your own so would be good to know more details.
>
> Best,
> Andrzej
>
>
> On Tue, Jun 16, 2020 at 8:29 PM <jf...@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 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, jf@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, jf@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, jf@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, <jf...@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 <jf...@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
Posted by Andrzej Kaczmarek <an...@codecoup.pl>.
Hi,
How did you setup interrupts on FreeRTOS (e.g. radio) and critical section?
These kinds of problems are common if you have misconfigured locking,
interrupt priorities or smth. Since we do not have any official port for
FreeRTOS (there's only NPL but it does not deal with hardware) I assume you
did this on your own so would be good to know more details.
Best,
Andrzej
On Tue, Jun 16, 2020 at 8:29 PM <jf...@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 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, jf@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, jf@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, jf@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, <jf...@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 <jf...@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
Posted by jf...@codingfield.com.
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, jf@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, jf@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, jf@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, <jf...@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 <jf...@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
Posted by jf...@codingfield.com.
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, jf@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, jf@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, <jf...@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 <jf...@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
Posted by jf...@codingfield.com.
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, jf@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, <jf...@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 <jf...@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
Posted by jf...@codingfield.com.
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, <jf...@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 <jf...@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
Posted by Łukasz Rymanowski <lu...@codecoup.pl>.
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, <jf...@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 <jf...@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
Posted by jf...@codingfield.com.
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 <jf...@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
Posted by Łukasz Rymanowski <lu...@codecoup.pl>.
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 <jf...@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