BLE with coded PHY and CCM decryption

RE: BLE with coded PHY and CCM decryption

Esi — Wed, 30 Mar 2022 10:42:29 GMT

Hey Einar, Sorry for the very late reply. Unfortunately I got Covid and had to self quarantine for a while.

At last I'm back in the office and managed to do some testing.

Thanks for sending the link for the Zephyr implementation. I went through it and couldn't spot any differences at first. Then went back to the code and started to experiment some more, until I realized that by setting PCNF0.S1LEN = 0, I could get the decryption to work!.

Investigating this further and going back to the reference manual, showed that S1 field is marked as "Reserved for future use" in the CCM chapter. I took this as that I can use this field for my own purposes, however this is not the case. When looking at the zephyr code, they also set the S1LEN to either 0 or 8 depending on whether the device supports CTE (which is an extension for direction finding). Since the nrf52840 doesn't support direction finding, I assume the CCM module is not configured in a way to allow the use of the S1 field. If this field is transmitted by the radio, the CCM module will lag behind by 1 byte and thus not complete the decryption in sequence with the Radio module.

At least that's my theory.

In any case, I seem to have a good work around for my problem and can continue. Thanks for all of the help!

RE: BLE with coded PHY and CCM decryption

Einar Thorsrud — Wed, 09 Mar 2022 13:33:48 GMT

Hi,

I am sorry for the delay. Have you looked at the low-level implementation for Nordic in the Zephyr LL and used that as a reference? Unfortunately I have not had a chance to dig into it, but I suspect you may be able to find some inspiration in how things are done there.

RE: BLE with coded PHY and CCM decryption

Einar Thorsrud — Fri, 04 Mar 2022 16:06:53 GMT

I see. I will look into how we do this in our stack implementations and get back to you.

RE: BLE with coded PHY and CCM decryption

Esi — Thu, 03 Mar 2022 16:19:18 GMT

Hi,

Yeah, if I start the decryption after the payload has been received, even if the CCM module is configured to operate as fast as possible (2 Mbps, which in theory should be safe since we have received all of the payload), it will still end up taking some time for the whole packet to be decrypted. During this time, the radio can't be used to receive the next packet which prevents me from receiving packets end to end which in turn affects the throughput.

In theory, the radio can be configured to receive the next packet while the CCM is busy decrypting the previous one by changing the packet pointer in the RADIO peripheral, but it becomes complex to manage. I was hoping to avoid that.

RE: BLE with coded PHY and CCM decryption

Einar Thorsrud — Thu, 03 Mar 2022 15:58:20 GMT

Hi,

I see.

Regarding the question I must admit I have not been able to find an explanation for why you need to trigger trigger CRYPT from the PAYLOAD event? Is there any issue doing that (other than using a PPI channel)?

RE: BLE with coded PHY and CCM decryption

Esi — Wed, 02 Mar 2022 22:03:59 GMT

Hi,

That's a fair question. We are not going to develop the Bluetooth LE stack from scratch. The idea is to develop a rather simple proprietary communication protocol that uses BLE LR modulation for long range and noise immunity. Other than the PHY layer, all other MAC and application layers will be different and much simpler than what's required for the BLE stack.

RE: BLE with coded PHY and CCM decryption

Einar Thorsrud — Wed, 02 Mar 2022 14:33:25 GMT

Hi,

I have not had a chance to look at this today, but will take a look tomorrow. In the mean time, may I ask why you are writing your own Bluetooth LE stack (which is a huge task)?