CC3351MOD: Linux Driver for kernel 6.6 and SPI interface

Amandio Neves

Part Number: CC3351MOD
Other Parts Discussed in Thread: AM68A

Tool/software:

Hello,

We have a custom board based on the AM68A using ti-linux-kernel 6.6.32. That is based off of ti linux sdk v 10.00.00.08. We are currently investigating wifi/bluetooth combo modules which use a SPI interface and the CC3351MOD seems to match up with our requirements. As part of our investigation, I wanted to ask some questions and just confirm some details around driver support with this module.

Are there any limitations to know of with respect to using the SPI interface? I found this thread:

CC33XX-SOFTWARE: CC33xx Linux driver - Wi-Fi forum - Wi-Fi - TI E2E support forums

which suggests, at least at one time, maybe the SPI interface was not recommended. Is that still the case? Is there anything else to know about using the SPI interface? By the way, our application does not require the wi-fi speed to be super fast. We just need to support small burst of data so we can tolerate a slower link like SPI vs SDIO. We do, however, need the link to be stable and consistent.

What is the correct set of driver patches to apply, and in what order (if necessary)? On the CC33XX software download page:

CC33XX-SOFTWARE Driver or library | TI.com

there are links for v1.0.0.8 of the Linux package as well as the github page for support for other kernels. The latest driver package from the download page (v1.0.0.8) include patches for SPI support but the documentation suggests it's for kernel v6.1. The github page is a bit confusing. In the README, it links ti-linux-6.6.y (which is what we are running) to 1.0.0.8. But in the file listing, there is a folder named ti-linux-6.6.y with a single patch file in it that looks more recent. However it looks like it is missing SPI support which we need. Could someone tell me what is the appropriate driver to use for our kernel?

Thanks!

4 months ago

0 Sabeeh Khan1 4 months ago

TI__Mastermind 30790 points

Hi Amandio,

Amandio Neves said:
which suggests, at least at one time, maybe the SPI interface was not recommended. Is that still the case?

We generally don't talk about SPI enough because of the limitations in throughput. But in use cases like yours, SPI does sound like a very reasonable path forward. We are here to assist you in this development path.

Amandio Neves said:
there are links for v1.0.0.8 of the Linux package as well as the github page for support for other kernels. The latest driver package from the download page (v1.0.0.8) include patches for SPI support but the documentation suggests it's for kernel v6.1. The github page is a bit confusing. In the README, it links ti-linux-6.6.y (which is what we are running) to 1.0.0.8. But in the file listing, there is a folder named ti-linux-6.6.y with a single patch file in it that looks more recent. However it looks like it is missing SPI support which we need. Could someone tell me what is the appropriate driver to use for our kernel?

This is an accurate analysis! Appreciate you reading through all available documentation and making the connection. So yes, SPI is currently not available in the ti-linux-6.6.y. However, this is a fair request and we can update the patches on the GitHub repo to enable SPI on ti-linux-6.6.y.

What are your timelines for this project so we can better assist you?

0 Amandio Neves 4 months ago in reply to Sabeeh Khan1

Prodigy 250 points

Sabeeh Khan1 said:
What are your timelines for this project so we can better assist you?

We should know in the next 2 to 3 weeks if we are switching wireless modules.

Sabeeh Khan1 said:
So yes, SPI is currently not available in the ti-linux-6.6.y

I'm confused. Why does the README on the github page link to 1.0.0.8 for ti-linux-kernel-6.6.y? What's the difference between 1.0.0.8 and the patch that is in the ti-linux-kernel-6.6.y folder on the github page (and maybe even what has been mainlined)?

Sabeeh Khan1 said:
We generally don't talk about SPI enough because of the limitations in throughput. But in use cases like yours, SPI does sound like a very reasonable path forward. We are here to assist you in this development path.

That sounds great! Like I mentioned before, our main concern is reliability. We had evaluated a different module using SPI that has stability issues and will emit spi errors and cause corrupted downloads silently. Obviously, this is something we want to avoid. So, I just want to confirm with you that by using the SPI interface we won't run into any similar issues, is that correct?

Thanks!

0 Amandio Neves 4 months ago in reply to Sabeeh Khan1

Prodigy 250 points

Hi Sabeeth,

Do you have an update you can share?

Thanks!

0 Sabeeh Khan1 4 months ago in reply to Amandio Neves

TI__Mastermind 30790 points

Hi Amandio,

Amandio Neves said:
Why does the README on the github page link to 1.0.0.8 for ti-linux-kernel-6.6.y? What's the difference between 1.0.0.8 and the patch that is in the ti-linux-kernel-6.6.y folder on the github page (and maybe even what has been mainlined)?

The CC33xx SDK 1.0.0.8 is based on TI kernel 6.1. There is basic support for cc33xx in the ti-linux-6.6.y, but it needs to be updated. So that is why we have a patch in the Github for ti-linux-6.6.y: to update the kernel for the latest SDK 1.0.0.8.

As an example, the ti-linux-6.6.y doesn't include BLE support. The patch in the GitHub repo adds this. Furthermore, we always recommend (as there are significant improvements in the firmware) to use the latest SDKs so this patch updates the kernel to match the latest SDK.

Amandio Neves said:
We had evaluated a different module using SPI that has stability issues and will emit spi errors and cause corrupted downloads silently. Obviously, this is something we want to avoid. So, I just want to confirm with you that by using the SPI interface we won't run into any similar issues, is that correct?

The linux driver loads a firmware into the CC33xx. The linux host can communicate to the firmware via SPI or SDIO. However, the actual connection management is handled within the firmware. So there would not be any connection performance (in terms of maintaining the connection) difference by just changing the communication peripheral. There is, however, an impact on throughput.