Hi there,
I have spent the last week trying to understand why my board, which is largely identical to the DK had various BT robustness issue; it was basically impossible to perform a DFU without a premature GATT_TIMEOUT; the exact same firmware on the DK worked fine though? Using the smp_svr sample, my debug process was as follows:
- My first thought was the antenna tune may be out, (despite exhibiting superior RSSI to the DK), however I double checked it with the VNA, and it was resonating nicely at 2.4GHz.
- I checked the power rails and DCDCs to to confirm no brown-out situations during the message-flow - all good.
- I set up an nRF52840 dongle as a BT packet sniffer, and compared the successful (DK) and unsuccessful (custom) scenarios - nothing looked untoward in the Wireshark captures, excepting that immediately prior to the DFU failing, there were a number of sequential packet submissions originating from the phone that timed-out (unsurprisingly).
- I rebuilt the hci_rpmsg to enable detailed logging - again, nothing seemed untoward as far as the BT stack went, although occasionally I did see an <err> hci_rpmsg: ACL payload length is not correct message.
- I then turned on detailed BT debugging on the app core, and lo-and-behold, it worked FLAWLESSLY!
My feeling is that there is some timing issue in BT stack / RPMsg. I could however be entirely wrong!
Other salient info relating to my setup:
- NCS 1.5
- HV DCDC disabled
- Silicon markings: N5340 QKAAD0 2044AB
- Battery powered: ~3.0V
- HFXT: Same Golledge crystal as DK
- internal caps
- LFXT: Golledge MP03952 (C0: 1.1pF, C1: 3.7fF. Circuit condition: 9pF) as no MP07668 in stock
- all internal cap values tested with no difference in behaviour
Quite urgently need to sort this one out, so any guidance is VERY appreciated. Many thanks!
BR,
Z
