[WIP] cpu/cc26x2_cc13x2: add sub-1-ghz netdev driver

[jeandudey]

Contribution description

Note: this code is untested and I highly don't recommend running the code yet.

---

Status

What works:

• Sending a packet.
• Receiving a packet.
• Auto initialization.
• Data whitening (not sure, not verified).

What doesn't work (not done):

• CRC calculation of packets: I've disabled it as it gave me some errors, needs to configured correctly, (in the sending/receive functions).
• CCA, can be trivially implemented but the driver codebase is quite a lot complex and I first want to get initial thoughts on this before continuing to work.

What isn't supported by hardware:

• Auto ACK
• Address-based filtering (can be done, but removes compatibility with IEEE 802.15.4g standard).
• FEC (needs a CPE patch, I couldn't find where).
• Mode Switching (same as FEC).

Standard compliance

This driver implements the MR-FSK PHY of the IEEE 802.15.4g standard, on the 915 MHz band using Filtered 2-FSK (2-GFSK). It still needs to be verified with another device to check that it works.

About channel pages I haven't been able to find what page is that PHY on that Band, I'm not sure about it. I defaulted to page 0.

---

Some of the code is based on the @kaspar030 code for the cc26x0, and on the OpenThread implementation for the CC1352 (IMHO a lot of the OpenThread code has been rewritten, but I kept the Copyright notice).

Testing procedure

Don't do that, but if you want to get your hands on the code here it is:

BOARD=cc1312-launchpad make

On a GNRC example.

Issues/PRs references

#13205
#13215

Useful links

• CC13x2, CC26x2 SimpleLink MCU TRM. pag. 1898.

cc @amovitz , @benpicco , @kaspar030

[benpicco]

Would it make sense to include the driverlib as a pkg? This was done for Microchips cryptoauthlib (#13014), which is a similarly heavy library.

[jeandudey]

Would it make sense to include the driverlib as a pkg? This was done for Microchips cryptoauthlib (#13014), which is a similarly heavy library.

I'll take a look at it, I don't want to pollute the RIOT repo with all that code

[benpicco]

It's has a prop in the name because it uses the propietary mode of the RF Core (the only available on the CC1312, and the Sub-GHz option for CC1352)

I'm a bit confused because the product page lists IEEE 802.15.4g support as a feature, so I'd assume it could talk to other IEEE 802.15.4g radios like the at86rf215.

[jeandudey]

It's has a prop in the name because it uses the propietary mode of the RF Core (the only available on the CC1312, and the Sub-GHz option for CC1352)

I'm a bit confused because the product page lists IEEE 802.15.4g support as a feature, so I'd assume it could talk to other IEEE 802.15.4g radios like the at86rf215.

They call it proprietary mode for unknown reasons (doesn't comply with IEEE standards, but in some way it's compatible, i don't know if compatible with other radios, but in the documentation the radio parameters can be changed to be compatible with CC110x), The IEEE mode support I've seen from the CC1352 and CC26x2 are for the 2.4 GHz band, however the CC1312 is Sub-GHz only.

In conclusion after digging up a little bit:

• Sub-GHz -> Propietary mode
• 2.4 GHz -> IEEE mode

[jeandudey]

I've added the cc26xx_cc13xx_driverlib package and rebased the changes.

[benpicco]

I'd put the board config in a separate commit.
Also no need to first add the files to cpu/cc26xx_cc13xx only to move them to cpu/cc26x2_cc13x2 in the next commit 😉

Haven't looked at the code yet, so I'm just nitpicking commits 😉

[jeandudey]

Re-rebased. I'm investigating if it can be compatible with other modules. TI docs are confusing on that matter.

[jeandudey]

So far I have been investigating and it seems that the CC13x2 devices are compatible with the MR-FSK PHY of the IEEE 802.15.4g standard, although it isn't quite easy and doesn't support all of the IEEE 802.15.4g features (Mode Switching, FEC, etc.), and it requires some patches on the RF Core (I haven't found what patches exactly, documentation is scarce). So far I have been working to get this done, I'm doing some refactorings to clean-up the code and testing here and there.

[jeandudey]

Will rebase and squash to update the code for the new capabilities API of the HAL.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[benpicco]

Uh what was the last state of this one?
I have two boards and can do some tests.

[jeandudey]

It's quite outdated a bit due to the recent HAL changes, have to wait for some boards to come in to continue development

[kYc0o]

I'm very interested on this driver so I took the liberty of rebasing it into current master. @jeandudey should I push it into this branch? I'm doing some tests with various hardware I have at hand, so I'll be giving some feedback during this week.

[jeandudey]

Yeah for sure, I just bought some hardware couple months ago, haven't had the time to keep working on it yet but would like to get this in re built

[kYc0o]

So now I succeeded to rebase it and adapt it to current master. HAL adaptations were done and basic examples/tests are running. There's just a little problem with ACK and retransmissions which may be due to a wrong set symbol time, which I'll investigate soon.

@jeandudey should I just force push and restart the review process?

[kYc0o]

Oh and thanks a lot @jia200x for the help on the HAL adaptation!

[benpicco]

Might be easier if you just make a new PR of your own.

[kYc0o]

I've opened a new PR with the updated code at #18737 @benpicco @jeandudey @jia200x

[jeandudey]

Thanks! Will close this one in favor of yours