[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]

@benpicco I think this is in a reviewable state, for sure it's not the most performant nor the best code in his class but it's a good start and I can iterate on the code depending on the feedback (I need to now if I'm doing things right or there's a better approach) . I've updated the PR description.

[amovitz]

The build fails if ENABLE_DEBUG is not switched on in the file rf_internal.c or in a compiler switch.

cpu/cc26x2_cc13x2/prop_radio/rf_internal.c

77 #define ENABLE_DEBUG (1)

Otherwise, this is the first time I've seen a RIOT application send a packet from one CC1312r board to another with UDP. Please let me know if I can help with anything.

[jeandudey]

The build fails if ENABLE_DEBUG is not switched on in the file rf_internal.c or in a compiler switch.

I have a weird bug when debug is disabled, probably to a race condition in interrupt handlers. However I'll fix that compilation bug too.

Otherwise, this is the first time I've seen a RIOT application send a packet from one CC1312r board to another with UDP. Please let me know if I can help with anything.

For sure, there are some bugs around there wanting to be discovered.

[jeandudey]

I've fixed the synchronization bug (Frequency Synthesizer didn't finish it's job and RX started too early).

[amovitz]

Reporting in with some test results and observations

Using UDP (no DTLS) I get a fairly constant data rate of just under 3 kilobytes/s. This is a very consistent test via the shell commands and could be sped up.

One thing I notice is there are some bugs with transmitting data and the device locking up. It will stop responding to shell commands and must be reset with the launchxl's reset button or via the onboard debugger.

I know there's still a lot to improve, but I can't express how much better this workflow is than using the TI tools for building similar test RTOS/applications.

[jeandudey]

There's room for improvements, I want to fix bugs on TX/RX and then move onto fixing incompatibilities with IEEE 802.15.4g.

Sometimes the driver locks into an state where it cannot receive or send, and sometimes the RF Core locks itself when running a TX. Synchronization issues that need to be fixed of course.

I'm doing small steps into fixing these bugs, as it's a little bit hard to work on this specific MCU. While testing internally by a colleague, the driver worked on a C1352P (not supported by RIOT currently, but trivial to add support to).

I know there's still a lot to improve, but I can't express how much better this workflow is than using the TI tools for building similar test RTOS/applications.

Much better definitely, I'm trying to remove all dependencies on the TI driverlib package. Working with RIOT on these MCUs makes it seem easy :wink:

[benpicco]

Please make a separate PR for the cc1352p, that should be easy to merge.

[luisan00]

Please make a separate PR for the cc1352p, that should be easy to merge.

Sorry @benpicco , that was a mistake, i pushed on the wrong branch.

[jeandudey]

I've updated the code to reflect the changes on master (-1000 lines removed), for now it's just basic TX/RX functionality, for now it isn't compatible with IEEE 802.15.4g (uses TI defaults, will be changed), the netif can't be turned off (for now). It's very simple, there are things that I can improve before fixing these things.

Also, I've removed external packages.

Please feel free to review.

[jeandudey]

Rebased (to keep the PR updated in case I get more time to work on this). Works only with DEVELHELP disabled due to #14164.

[benpicco]

Sorry for the sparse response. A few general comments / questions

Address-based filtering (can be done, but removes compatibility with IEEE 802.15.4g standard).

This I don't understand. Doesn't that just mean having a frame-filter so that only the frames intended for the radio are processed?

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.

It would be 9 and 10, but that makes only sense with the macExtendedBitmap which we don't have. (See 802.15.4g-2012 Amendment 3, 802.15.4-2015 (and probably 802.15.4-2020 too, but I haven't gotten hold of that yet)), but at this point I wouldn't bother with it. RIOT does nothing with this other than displaying it in ifconfig.

I've seen the CC1352P can operate on both sub-GHz and 2.4 GHz. Can it do so at the same time, so does it have two interfaces that act mostly independent from another like at86rf215?

[jeandudey]

This I don't understand. Doesn't that just mean having a frame-filter so that only the frames intended for the radio are processed?

It can't handle IEEE 802.15.4 addresses (only CC1352R/CC1352P/CC26xx can do, but at 2.4 GHz) as the radio mode for Sub-GHz doesn't allow that, it can handle addresses but they modify the packet format in a way that isn't compatible with 802.15.4 frames. Currently it receives any frame, even if it isn't the target.

I've seen the CC1352P can operate on both sub-GHz and 2.4 GHz.

Supports both bands, however, only one can be used at a time. TI drivers changes the radio mode each time they need to send a packet on sub-GHz or 2.4 GHz.

AFAIK only one interface can be used to receive due to how the RF Core works, only one command at a time, and sub-GHz/2.4 GHz have different commands, hence the weird thing about the addresses and that they're only supported on 2.4 GHz which has the PHY properly implemented per the 802.15.4 standard.

However with that in mind, I've tried to separate actual radio modes from the RF Core, (the cc26x2_cc13x2_rfc module) to share code between future implementations of other modes (2.4 GHz & BLE).

[benpicco]

Don't worry, I haven't forgotten about this - just didn't find the time to look into it. I even have a pair of cc1352p-launchpads so I can do some interop testing. And before I wanted to bring MR-FSK for at86rf215 upstream so I better know what I'm talking about (and we don't have to figure out all the timing calculations yet again here).

You might be happy to hear that a new radio HAL is in almost ready that will take care of retransmissions (#14792) and doesn't put the burden on the driver to queue packets while sending.

[jeandudey]

Don't worry, I haven't forgotten about this - just didn't find the time to look into it. I even have a pair of cc1352p-launchpads so I can do some interop testing. And before I wanted to bring MR-FSK for at86rf215 upstream so I better know what I'm talking about (and we don't have to figure out all the timing calculations yet again here).

I'll rebase the driver as there have been some changes since then. There might be some interop issues regarding PHY header, the Start of Frame Delimiter might be flipped since Texas Instruments doesn't specify a byte order for their header, or the bitrate which both could be easily be fixed.

FWIW making a 2.4 GHz driver is far more easy than the Sub-1-GHz (TI is very weird in this aspect) and some code could be reused for CC1352 since it supports both. It might affect the driver design a little bit, but would be better if code was shared between. On 2.4 GHz IEEE 802.15.4g has first class support for retransmissions and auto ACKs.

You might be happy to hear that a new radio HAL is in almost ready that will take care of retransmissions (#14792) and doesn't put the burden on the driver to queue packets while sending.

This is really good news for Sub-GHz, since retransmission should be handled by software. I was waiting for it, and to update the code to make it possible to use with the radio HAL.

---

Thanks for keeping an eye on this :wink:

[benpicco]

still WIP?

[jeandudey]

still WIP?

Yep, still WIP, some code hasn't been pushed (yet) with the port to the radio HAL, it still needs some polishing and handle correctly the ACKs.

[jeandudey]

Updated the driver to use only the IEEE 802.15.4 HAL, some things are unclear in how to proceed.

The direct netdev implementation was dropped to reduce complexity, might be suitable to do on another PR now that the base code is there.

Aside from the change that has to be done with the ACK_TIMEOUT, the TX and RX works well. The CCA works in carrier sense mode, other modes can be implemented by software, but for another PR.

I feel like this PR should be the minimum of functionality and be used as a starting point to extend the functionality while the HAL evolves.

Another question is the RSSI, the driver provides the raw value in an int8_t in dBm, how do I do map it to the RSSI that the HAL expects?

[jeandudey]

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

[stale[bot]]

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.