Maybe I should direct my question to JF then. Thanks for your reply.
Mo Chen On Mon, Jun 15, 2020, 10:18 Mo Chen <shanyechu...@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.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 >
