Driver Seems to Die if Channel is Too Busy

[bradjc]

I'm seeing an issue where no more packets are sent or received after three "channel busy" detections. The kern.log output is:

Mar 27 22:29:38 raspberrypi kernel: [23663.893466] [cc2520] - channel still busy, waiting 1901 uS
Mar 27 22:31:57 raspberrypi kernel: [23803.039498] [cc2520] - channel still busy, waiting 1640 uS
Mar 27 22:34:43 raspberrypi kernel: [23968.961506] [cc2520] - channel still busy, waiting 1770 uS

I'm not sure why 3 seems to be the magic number, but this has happened more than once. If I decide to dive in I'll poke around, but I wanted to make sure to record this now.

[bradjc]

Not sure if this is the same issue, but it has the same effects. The driver stops receiving packets after:

Apr 11 05:44:24 raspberrypi kernel: [1259260.761073] [cc2520] - src_mode: 3 dest_mode: 2 pan_comp: 1    src_addr_offset: 8
Apr 11 05:44:24 raspberrypi kernel: [1259260.761966] [cc2520] - read:  0x44 0x41 0xC8 0xC9 0x22 0x00 0xFF 0xFF 0xBC 0x78 0x7F 0x50 0x45 0x6D 0x12 0x00 0x69 0x3B 0xC0 0xFF 0xC1 0x3A 0x1A 0x9B 0x01 0x5A 0xF7 0x00 0x00 0x00 0x02 0x17 0x9D 0xF9 0xF7 0x20 0x01 0x04 0x70 0x1F 0x11 0x13 0x1A 0x5F 0xBB 0x02 0x46 0x31 0xFE 0xC9 0x22 0x04 0x0E 0x00 0x0A 0x08 0xFF 0x00 0x03 0x00 0x01 0x00 0x00 0x00 0xFF 0xFF 0xFF 0xED 0xEB
Apr 11 05:44:24 raspberrypi kernel: [1259260.765957] [cc2520] - src_mode: 3 dest_mode: 2 pan_comp: 1 src_addr_offset: 8
Apr 11 05:44:24 raspberrypi kernel: [1259260.766919] [cc2520] - more than one RX packet received, flushing buffer
Apr 11 05:44:24 raspberrypi kernel: [1259260.766947] [cc2520] - oversized packet received. clearing.
Apr 11 05:44:24 raspberrypi kernel: [1259260.774109] [cc2520] - src_mode: 3 dest_mode: 2 pan_comp: 1 src_addr_offset: 8
Apr 11 05:44:24 raspberrypi kernel: [1259260.774883] [cc2520] - more than one RX packet received, flushing buffer
Apr 11 05:44:24 raspberrypi kernel: [1259260.774899] [cc2520] - oversized packet received. clearing.
Apr 11 05:45:12 raspberrypi kernel: [1259309.206250] [cc2520] - write:  0x41 0x41 0xC8 0xF2 0x22 0x00 0xFF 0xFF 0xAC 0xB7 0x48 0x15 0x00 0x6D 0x12 0x00 0x79 0x3B 0x3A 0x1A 0x9B 0x01 0xD2 0x15 0x00 0x00 0x00 0x01 0x97 0x03 0xFF 0xFF 0x20 0x01 0x04 0x70 0x1F 0x11 0x13 0x1A 0x5F 0xBB 0x02 0x46 0x31 0xFE 0xC9 0x22 0x04 0x0E 0x00 0x0A 0x08 0xFF 0x00 0x03 0x00 0x01 0x00 0x00 0x00 0xFF 0xFF 0xFF

A bunch more writes happen, but they're all broadcast and the application functionally stops.

[bradjc]

OK it seems:

• The driver doesn't deadlock or anything. It is still able to send packets.
• The radio gets into a state where it no longer receives packets. The SFD line doesn't go high unless a packet is being sent.
• It always stops receiving after strobing SFLUSHRX.

I'm looking into why it may corrupting the radio state.