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.rymanow...@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, <j...@codingfield.com> wrote: > > > Hi, > > > > It looks like the attachements were dropped somewhere... You can > > download them on my seafile instance : > > https://seafile.codingfield.com/d/64d53a6ca6b44ae6b5d7/ > > > > It seems to fail during the discovery of the characteristics on the > > device. From what I understand, it happens during the discovery of > > Generic Access Profile and Generic Attributes Profile, which are handled > > by nimble. > > I may be wrong, I'm a beginner with BLE and nimble! > > Maybe the captures will make more sens to you? > > > > Yeah, it's very strange that it works when the code is supposed to run > > slower... It makes me think of a timing or memory issue, but I couldn't > > find it... > > > > Thanks, > > JF > > > > Le 14/06/2020 20:46, Łukasz Rymanowski a écrit : > > > Hi, > > > > > > Thanks for the report, however looks like attachments are missing. > > > > > > First of all you need to understand what read fails i.e check handle > > > and > > > make sure that your application responds correctly. > > > It is very suspicious that read works with -Og, but still I would focus > > > on > > > that failing read first. > > > > > > Thanks > > > Lukasz > > > > > > > > > On Sun, Jun 14, 2020, 20:25 <j...@codingfield.com> wrote: > > > > > >> Hello, > > >> > > >> I'm working on a firmware for the Pinetime, a smartwatch based on the > > >> NRF52832. The code is written in C/C++ and uses FreeRTOS. > > >> I've recently switched from the Nordic Softdevice to NimBLE as BLE > > >> stack. I used the freertos port from the 'porting' folder of the > > >> source > > >> code of nimble. > > >> > > >> I did many test using my PC on Linux : it can connect and communicate > > >> with the NRF52 without issue. > > >> However, things are not that easy when I try to connect using Android > > >> phone (I tried with a Huawei Psomething and my old Nexus5) : the > > >> connection fails most of the time. > > >> > > >> I did a lot of debugging, logging, sniffing,.. and I still cannot > > >> understand why it's not working as expected. Here are some of my > > >> observations: > > >> > > >> - When Android successfully connects, I receive the following GAP > > >> events : BLE_GAP_EVENT_CONNECT and then BLE_GAP_EVENT_CONN_UPDATE 2 > > >> times. The first update sets the connection interval to 6, the second > > >> one to 40. > > >> - When it fails, I receive only the BLE_GAP_EVENT_CONNECT event and > > >> the > > >> 1st BLE_GAP_EVENT_CONN_UPDATE. > > >> - Using the sniffer, I noticed that the last packet is a read > > >> request > > >> from the phone. It looks like the NRF52 never respond to this last > > >> read. > > >> - It fails in the discovery steps (when the android phone discover > > >> all > > >> the services, characteristics and attributes) but not always at the > > >> same > > >> place. > > >> - I noticed that the tasks (ll task and host task are not in > > >> deadlock > > >> BUT it looks like the radio ISR (ble_phy_isr() in ble_phy.c) is not > > >> called anymore. > > >> - When I build the very same code in DEBUG (-Og instead of -O3), it > > >> works perfectly! > > >> > > >> You'll find in attachements 2 captures I did with Wireshark and the > > >> NRF > > >> Sniffer (running on a NRF52-DK), one failed and one successful attempt > > >> to connect. > > >> > > >> I'm running out of idea to debug this further. Is there a > > >> configuration > > >> issue (there are so many parameters in syscfg.h)? What could I try? > > >> Where should I search ? Do you need more info to understand the > > >> issue? > > >> > > >> Could you help me fix this issue? > > >> > > >> Thanks, > > >> > > >> JF > > > -- Mo Chen
