This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

sniffer detects LL infinite loop

tr4x_87dB_0xc7_1024_7.5ms_おかしい.psdWe are using a transmission scheme where we tag each of our packets with a block number and fire them off using write without acknowledgement. The receiving side looks for "holes" (missing block numbers) and requests the re-transmission of those missing blocks.

While testing functionality with the central app running on a PC and using the MasterEmulator.dll, we noticed the Central sometimes "locked up" and resent the same packet "forever", well, hundreds of times until some watchdog timer kicks in and the connection is disconnected.

The packet is sent at an interval of ~7.5ms, and the channel always changes, so the radio timing sync is working OK. But there is a vicious circle where the SN and NESN get out of sync.

image description

I have not delved into the details of the link layer, but I would imagine there should be some sort of retry timeout mechanism, who knows?
I believe the connection interval used was 7.5ms, and the peripheral is using S130 2.0.0-7 Alpha with app_sched_execute(); to process the Q. The peripheral may well have been operating near its limit, which may have caused a critical delay which sparked this sequence, but no matter how you get into it, this infinite loop is a LL state machine problem, bug or feature.

We will be transitioning to the S130 release version image soon enough, and the problem may, just go away. Or then again, it may not.

Hope some one has time to address the issue. Thanks. Karel.

Minor edit: added the trace file (sorry, its a TI trace file).

Parents
  • Hi Hung,

    1. I was not fully aware that the protocol did not have a max retry count at the lower layers, is this true also for notifications as well as write-without-ack?
    2. Added the trace file (TI sniffer) to the top of the question.
    3. Don't know the exact chip used, but another one from the same batch has markings
      N51822 / QFACA1 / 1620AM The chip on the Nordic Dongle (MasterEmulator side) has markings N51442 / QFACA1 / 1503AD
Reply
  • Hi Hung,

    1. I was not fully aware that the protocol did not have a max retry count at the lower layers, is this true also for notifications as well as write-without-ack?
    2. Added the trace file (TI sniffer) to the top of the question.
    3. Don't know the exact chip used, but another one from the same batch has markings
      N51822 / QFACA1 / 1620AM The chip on the Nordic Dongle (MasterEmulator side) has markings N51442 / QFACA1 / 1503AD
Children
No Data
Related