cyw43439: add support for CYW43439 wifi chip #4529

irina-nita · 2025-07-27T21:59:13Z

Pull Request Overview

This pull request adds:

chips/cyw43439: support for the PIO half-duplex SPI interface for the RP2040 chip used to communicate with the CYW43439 chip available on the Raspberry Pi Pico W board
support in boards/raspberry_pi_pico for enabling the PIO configuration and Ethernet Tap capsule
hil/wifi_cyw43: minimal WiFi HIL for peripherals that interact with the CYW43439 or other similar Cypress chips. The HIL contains four traits that provide interfaces for initializing the device and getting the MAC address, scanning networks and configuring station/access point mode.

Testing Strategy

WiFi HIL implementation tested by scanning/connecting to/creating networks
Ethernet HIL tested with the libtock-c lwIP example

TODO or Help Wanted

This PR needs to add an abstract interface for communicating with the CYW4343x chips. Besides the peripheral used for reading/writing to the chip, the process should be the same

Documentation Updated

Updated the relevant files in /docs, or no updates are required.

Formatting

Ran make prepush.

Added support for the PIO half-duplex SPI interface for the RP2040 chip to provide read/write functionalities for communicating with the CYW43439 chip available on the Raspberry Pi Pico W board. Support is also added in the board main. A minimal WiFi HIL for the Cypress 43439 chips was added. Both WiFi HIL and EthernetTap HIL implementation were provided for the RP2040 PIO.

alexandruradovici

Looks really nice, just a few ideas.

alexandruradovici · 2025-07-28T06:43:14Z

boards/cyw43-firmware/43439A0.bin

I suggest that we add a firmware folder in Tock where we put these kinds of files.

Created a firmware directory in root

alexandruradovici · 2025-07-28T06:44:45Z

boards/raspberry_pi_pico/src/main.rs

 #[no_mangle]
 #[link_section = ".stack_buffer"]
-static mut STACK_MEMORY: [u8; 0x1500] = [0; 0x1500];
+static mut STACK_MEMORY: [u8; 0x6000] = [0; 0x6000];


Is there any way we could reduce this size? Do we inow what causes it?

I missed to modify this after adding a static buffer for packet construction. Fixed it now

alexandruradovici · 2025-07-28T06:45:40Z

boards/raspberry_pi_pico/src/main.rs

 >;
 type TemperatureDriver = components::temperature::TemperatureComponentType<TemperatureRp2040Sensor>;

+const WIFI: bool = option_env!("WIFI").is_some();


What about adding a a feature in and assigning WIFI to cfg?

Is there a reason why we would want to disable WiFi?

I think it's more that we don't want capsules like Ethernet to be available for Picos without Wifi. I tried using a wifi feature at first but the Tock board Makefile doesn't provide any "cargo flags" variable. Adding that would require re-writing some of the Makefile rules and I didn't want to create any clutter. My idea was that for Pico W we'd build with WIFI=1 make

alexandruradovici · 2025-07-28T06:47:34Z

chips/rp2040/src/cyw43439.rs

This should be a capsule as this chip might be uses with other microcontrollers.

alexandruradovici · 2025-07-28T08:26:07Z

chips/rp2040/src/pio.rs

            sm.set_enabled(true);
        }

+        pub fn cyw43_spi_program_init(


Is this just an example?

It's used for initializing the PIO in cyw43439.rs

Given that we have a bunch of these, one more can't hurt.

alexandruradovici · 2025-07-28T08:28:49Z

kernel/src/hil/wifi_cyw43.rs

+// SPDX-License-Identifier: Apache-2.0 OR MIT
+// Copyright OxidOS Automotive 2025.
+
+//! Interfaces for CYW43439 WiFi devices


Can we document here how these traits relate to each other and how they should be used?

Changed back the stack size. Moved firmware files to root. Fixed bug from calling recv in the transmit_frame method in rp2040/cyw43439.

brghena

Here's some quick notes from skimming this. Not a full pass yet.

brghena · 2025-07-28T14:34:21Z

firmware/cyw43439/README.md

@@ -0,0 +1,5 @@
+# Wifi firmware blobs
+
+Firmware obtained from https://github.com/georgerobotics/cyw43-driver/tree/main/firmware


Why from some random github project? Does Infineon or Raspberry Pi not provide them directly?

Oh, I see. We're actually copying Embassy here: https://github.com/embassy-rs/embassy/tree/main/cyw43-firmware

We could possibly get them directly from Infineon: https://github.com/Infineon/wifi-host-driver/tree/master/WHD/COMPONENT_WIFI5/resources/firmware/COMPONENT_43439 and https://github.com/Infineon/wifi-resources (for the "Country Locale Matrix")

We discussed on the call today possibly relying on an external crate for firmware blobs. Maybe the same Crate embassy uses: https://crates.io/crates/cyw43-firmware

That should probably be discussed on a Core team call for approval.

brghena · 2025-07-28T14:47:02Z

chips/rp2040/src/pio.rs

            sm.set_enabled(true);
        }

+        pub fn cyw43_spi_program_init(


Given that we have a bunch of these, one more can't hurt.

brghena · 2025-07-28T14:52:06Z

chips/rp2040/src/gpio.rs

+            _2mA = 0,
+            _4mA = 1,
+            _8mA = 2,
+            _12mA = 3,


The leading underscore here is misleading. It's often used for "internal" things in other languages.

These should match the datasheet whenever possible, and to the extend possible. Maybe call them DRIVE_2MA, DRIVE_4MA, etc.?

brghena · 2025-07-28T14:53:48Z

chips/rp2040/src/gpio.rs

+    _2mA = 0,
+    _4mA = 1,
+    _8mA = 2,
+    _12mA = 3,


Update these to match whatever the "DRIVE" values are named above if you change them.

brghena · 2025-07-28T14:55:35Z

chips/rp2040/src/cyw43439/utils.rs

+    }
+}
+
+pub static NVRAM: &[u8] = b"


This also came from a source, right? That should be cited. Looks like it can be found here: https://github.com/Infineon/wifi-resources It would be good to double-check that matches though.

alexandruradovici · 2025-07-28T15:17:52Z

kernel/src/hil/wifi_cyw43.rs

+    /// ## Arguments
+    ///
+    /// - `ssid`: SSID of found network
+    fn scanned_network(&self, ssid: Ssid);


Is there any way to know what kind of encryption it uses?

bradjc · 2025-07-28T16:26:16Z

firmware/cyw43439/43439A0.bin

I think it would be fine to put this in the board's directory.

Adding a new top-level directory is probably not something we want to do. Putting it in chips/ is potentially an option, but I think would require some discussion and a plan for what types of binary blobs are acceptable and under what situations.

Another option is to embed the bytes in a rust file.

We discussed this on the Network working group call and we're considering an external crate that the CYW* WiFi capsule would rely on which would contain the binary blobs. Notably, they're licensed differently than the rest of the Tock kernel and there are some concerns there.

That would probably still be easiest to include from the board, then.

bradjc · 2025-07-28T16:26:35Z

kernel/src/hil/wifi_cyw43.rs

This seems general enough to just be called wifi.rs.

Event though we discussed this during type networking call, I kind of agree with @bradjc that this seems general enough. I do not see how other devices might need anything else here.

bradjc · 2025-07-28T16:36:24Z

chips/rp2040/src/cyw43439/packets.rs

+macro_rules! impl_bytes {
+    ($t:ident) => {
+        impl $t {
+            /// Bytes consumed by this type.
+            pub const SIZE: usize = core::mem::size_of::<Self>();
+
+            /// Create from byte array.
+            #[allow(unused)]
+            pub fn from_bytes(bytes: &[u8; Self::SIZE]) -> &Self {
+                let alignment = core::mem::align_of::<Self>();
+                assert_eq!(
+                    bytes.as_ptr().align_offset(alignment),
+                    0,
+                    "{} is not aligned",
+                    core::any::type_name::<Self>()
+                );
+                unsafe { core::mem::transmute(bytes) }
+            }
+
+            /// Create from mutable byte array.
+            #[allow(unused)]
+            pub fn from_bytes_mut(bytes: &mut [u8; Self::SIZE]) -> &mut Self {
+                let alignment = core::mem::align_of::<Self>();
+                assert_eq!(
+                    bytes.as_ptr().align_offset(alignment),
+                    0,
+                    "{} is not aligned",
+                    core::any::type_name::<Self>()
+                );
+
+                unsafe { core::mem::transmute(bytes) }
+            }
+        }
+    };
+}


I'm worried about having these unsafes here in general, and based on learning how macros work in Rust having unsafe in a macro is even more scary. It's not clear to me what impl_bytes does or how necessary it is versus using a safe approach.

This file might also be copied directly from Embassy, if I recall what we discussed on the Network working group call. Maybe we should be re-implementing these for Tock.

bradjc · 2025-07-28T16:37:20Z

chips/rp2040/src/cyw43439/utils.rs

+pub(super) fn as_bytes<T: Sized>(data: &T) -> &[u8] {
+    unsafe {
+        core::slice::from_raw_parts(
+            core::ptr::from_ref::<T>(data) as *const u8,
+            core::mem::size_of::<T>(),
+        )
+    }
+}
+
+pub(super) fn slice8_mut(x: &mut [u32]) -> &mut [u8] {
+    let len = x.len() * 4;
+    unsafe { slice::from_raw_parts_mut(x.as_mut_ptr() as _, len) }
+}
+


With these unsafes I don't know how necessary they are, but it would be good to add a # Safety comment that explains why they are safe.

alexandruradovici · 2025-07-28T17:55:49Z

kernel/src/hil/wifi_cyw43.rs

+    /// ## Arguments
+    ///
+    /// - `ssid`: SSID of found network
+    fn scanned_network(&self, ssid: Ssid);


Suggested change

fn scanned_network(&self, ssid: Ssid);

fn scanned_network(&self, ssid: Ssid, encryption: Option<Encryption>, signal_strength: Option<u8>);

#[non_exhaustive] enum Encryption { Open, Wep, Wpa1, Wpa2, Wpa3, }

signal_strength defined in abs(dBm).
Just to make it more generic.

alevy · 2025-09-06T18:21:45Z

@irina-nita @alexandruradovici @JADarius This seems quite close, but waiting on some feedback. Is there a timeline/estimate/plan for this?

irina-nita · 2025-09-19T07:46:08Z

Hey, sorry for the lack of activity on this PR. I'm currently working on wrapping up and testing the migration from chips to capsules as discussed. Because of this, some comments will become obsolete, I think. I estimate that in a few days I'll be able to push the updated version.

github-actions bot added the HIL This affects a Tock HIL interface. label Jul 27, 2025

github-actions bot assigned hudson-ayers Jul 28, 2025

alexandruradovici requested changes Jul 28, 2025

View reviewed changes

cyw43439: minor fixes

0fa0fed

Changed back the stack size. Moved firmware files to root. Fixed bug from calling recv in the transmit_frame method in rp2040/cyw43439.

irina-nita force-pushed the pico/wifi branch from 1774319 to 0fa0fed Compare July 28, 2025 12:35

cyw43439: added wifi hil doc

e54e641

brghena added the WG-Network In the purview of the Network working group. label Jul 28, 2025

brghena reviewed Jul 28, 2025

View reviewed changes

alexandruradovici reviewed Jul 28, 2025

View reviewed changes

bradjc reviewed Jul 28, 2025

View reviewed changes

alexandruradovici reviewed Jul 28, 2025

View reviewed changes

brghena self-assigned this Jul 29, 2025

brghena added the waiting-on-author label Aug 2, 2025

		@@ -0,0 +1,5 @@
		# Wifi firmware blobs

		Firmware obtained from https://github.com/georgerobotics/cyw43-driver/tree/main/firmware

	fn scanned_network(&self, ssid: Ssid);
	fn scanned_network(&self, ssid: Ssid, encryption: Option<Encryption>, signal_strength: Option<u8>);

Uh oh!

cyw43439: add support for CYW43439 wifi chip #4529

Are you sure you want to change the base?

cyw43439: add support for CYW43439 wifi chip #4529

Uh oh!

Conversation

irina-nita commented Jul 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Pull Request Overview

Testing Strategy

TODO or Help Wanted

Documentation Updated

Formatting

Uh oh!

alexandruradovici left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

brghena left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexandruradovici Jul 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexandruradovici Jul 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

irina-nita commented Jul 27, 2025 •

edited

Loading

alexandruradovici Jul 28, 2025 •

edited

Loading

alexandruradovici Jul 28, 2025 •

edited

Loading