NRF52840 won't receive from some TI CC2538 chips

[Libertas]

I have two devices on TI CC2538 that having problems talking to the NRF52840 dongle.

1. The channel is channel 11
2. There are 8 devices using TI CC2538. Only two of them are having problems
3. NRF52840 dongle ABSOLUTELY cannot see any packet from those two devices
4. I tried three dongles. It is consistent.
5. I doubted my own firmware. So I downloaded the NRF52840 sniffer and tried Wireshark. Same result! Those two devices disappeared in thin air from the dongle!
6. TI CC2538 can see packets from all devices, regardless of TI or Nordic.
7. TI CC2530 sniffer can see the packets from those two devices just fine.
8. Signal strength is not a problem. I have readings of -63dBM and -70dBM from Hub and the devices are much closer to the NRF53840 dongle.

I can only think of some compatibility problem. I don't think it has anything to do with software at this point.

I have a feeling that this is serious and we need to find out why?

I can give you guys the devices for further analysis.

[Susheel Nuguru]

Hi Libertas,

I have not seen or known any BLE interoperability issue between CC2538 and nRF52840. That does not mean that there is none, it just means that you might be the first to come across this. Before we can proceed on this I would need some information on your environment.

1. Which softdevice version and SDK version are you using on nRF52840 dongle? (not the sniffer, but your own firmware version based on which SDK and softdevice version?)
2. Does the nRF52840 run on XTAL LFCLK or internal RC? 
3. Does your 8 devices of TI CC2538 run on XTAL LFCLK or RC?
4. When you say not able to receive packets, do you mean advertising packets or connection packets?
5. If advertising packets, what is the interval of adv and scan and If connection packets, what are the connection parameters?

When you are testing two devices that are running on the same clock accuracy, and jitter the same amount then it more probable that the devices find each other. If you are using RC oscillator or some other clock on TI CC2538 with lower clock accuracy, it is no mystery that they find each others packet as eventually as they all of them are running on the same clock accuracy. 

If nRF52840 dongle is running the firmware on XTAL LFCLK with little bit more accuracy that the peer, then it is probably more strict with the timing of packets.

[Libertas]

Hi Susheel,

Thank you for your quick response. Please see my answers below:

1. The whole setup is 802.15.4. There is no BLE involved.

2. My own firmware is based on nRF5 SDK 17.1.0. My own firmware and the official Nordic sniffer firmware can only see 6 out of 8 devices on TI CC2538.

3. All TI devices can see the nRF52840 dongle. A TI2530 dongle-based sniffer can see all devices including the nRF52840 dongle.

4. All TI devices are on XTAL.

So the symptom appears to be that the nRF52840 dongle won't receive plain 802.15.4 packets from some of my TI devices.

I still can't believe what I have experienced but it just happened.

[Susheel Nuguru]

I cannot find any references of such issues internally, so I will try get some assistance from my colleagues to see if they know about this. Meanwhile maybe a sniffer trace for the thread would help to understanding the timings of the packets transmitting from TI CC2538

[Libertas]

OK. Here is the Wireshark capture with the nRF52840 dongle as sniffer.

There should be 4 APS transactions in this period. Each transaction is between the Hub (short address 0x0000) and a device with a short address of 0x0006 and a long address of 00:12:4b:00:19:3c:9b:9e.

Both devices are on TI CC2538.

As you can see, somehow, the nRF52840 dongle can only see packets from Hub. It completely lost the traffic from another device.

On the other hand, the transactions were going smoothly with direct communication and no MAC retry.

Each transaction shall generate 4 packets:

1. APS request from 0x0000 to 00:12:4b:00:19:3c:9b:9e (0x0006)
2. MAC acknowledgment of request from 0x0006
3. ASP response from 0x0006 to 0x0000
4. MAC acknowledgment of response from 0x0000

Because the nrf52840 dongle can only see traffic from 0x0000, it can only record two packets per transaction.

As you can see from the capture below. Each time the sequence number of ACK didn't match the original. That's because both packets are from Hub (0x0000). The dongle lost two packets from the other device in the middle of the transaction.

These are plain 802.15.4 packets. The two devices are about 9 feet away but the "hidden device" is inches from the dongle and the dongle still can't see anything from it.

I am banging my head right now!

[Susheel Nuguru]

I will have to show this to someone who have a bit deeper knowledge in the per packet transaction and ACK/NACKing of these packets. Will be back with more info when I get some.