NRF52840 won't receive from some TI CC2538 chips

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.

Parents
  • 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!

Reply
  • 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!

Children
Related