Hi, On Sat, 31 Jul 2021 at 13:43, <j...@codingfield.com> wrote:
> Hello! > > I'm working on the InfiniTime project, an open source firmware for the > PineTime from Pine64. It's based on the NRF52832 MCU. > InfiniTime is running on FreeRTOS and uses NimBLE as BLE stack. > > By the way : thanks everyone working on this project! Thanks to you, we > can build a 100% open source firmware for our smartwatch, which is > great! Thanks also to this mailing list that have already helped us a > couple of times! > > I'm trying to analyze a strange issue we have for quite some time : BLE > connectivity works fine (we use it to synchronise the time, send heart > rate data, notify battery level, firmware update,...) for ~24h. After > roughly 24h, we lose all BLE connectivity : a host device cannot connect > to the watch, and the watch does not advertise itself when it should > (advertising is restarted every time the watch is woken up by a push on > the button). It looks like the ble stack just stops. > > I've already done a few experiments: > - Run a BLE sniffer (the NRF sniffer based on the nrf52dk) next to the > watch for a day : The sniffer would see all advertising messages > whenever the watch was supposed to advertise until it saw nothing. I saw > no strange message between the last time the sniffer saw the advertise > messages and the time I noticed the watch was not advertising anymore. > - Connect the debugger once BLE does not work anymore and look at the > tasks : both LL and Host tasks were waiting for an event on their event > queue. No deadlock or infinite loop. > - Enable the monitor mode and log all HCI messages using btmon. I did > this a while ago, but as far as I remember, I couldn't see anything > wrong. > - Change the timeout of the calls to ble_npl_eventq_get() to check if > the tasks were running properly : they did. They just didn't receive any > new event3 > > So, as far as I can see, it looks like everything is running fine, but > no new event is generated to unlock the ble tasks. So I guess I have to > probe a bit deeper in the radio/isr code? > > Any suggestion to analyze this issue is welcome. What debug info can I > add/enable to try to understand what's happening under the hood? I have > a NRF52DK board on hand with a logic analyzer if needed. > If you have nrf52 you could trace radio activity with some debug pins BLE_PHY_DBG_TIME_ADDRESS_END_PIN BLE_PHY_DBG_TIME_WFR_PIN BLE_PHY_DBG_TIME_TXRXEN_READY_PIN Here you can find a description of those. https://github.com/apache/mynewt-nimble/blob/master/nimble/drivers/nrf52/syscfg.yml#L35 Best Łukasz > The source code is here (https://github.com/JF002/InfiniTime) and we are > using nimble 1.3 master branch commit > 82153e744833821e20e9a8b0d61c38b2b0dbcfe1. > > Thanks for your help! >
