Enabling the MCXW71 (NXP) with Golioth’s Bluetooth-to-Cloud

Golioth continues to enable new boards with Bluetooth-to-Cloud abilities, today it’s the NXP FRDM-MCXW71. At this point, it’s almost becoming routine! As a general rule, we look for the following in devices that can talk back to the cloud through our standard BLE-GATT based gateway:

• A board that is running Zephyr, optimally with in-tree support (though custom hardware is also possible)
• A device with a working BLE sample, including the HCI for communications

So far we have enabled the ST Microelectronics STM32WB5MM-DK, the Arduino Nicla Sense ME (with a Nordic nRF52833), the nRF52840-DK, and the NXP RW612. In all of these cases, we were able to send back generic packets (filled with our sensor data) to the cloud. Most of the time spent in our previous blog and video output centered around configuring Zephyr to be able to pull in external sensor readings. This made more realistic data flowing through the standard Golioth gateway up to the cloud.

A second NXP board

We have already enabled the RW612, so why spend the time enabling a different part on their ecosystem? The nature of the parts matters. And in fact: it’s all about Matter!

The RW612 is meant as a Thread border router, which enables Matter smart home setups. It has more communication mechanisms (Bluetooth, 802.15.4, Ethernet, Wi-FI) and generally a lot more horsepower. As such, it has a much higher price tag. The MCXW71 is the ‘node’ chip in that system, meant to be a Thread (and by extension, Matter) sleepy device: low power, lower cost, reduced functionalities. This matches the abilities of other chips we have enabled so far. Small, low power microcontrollers meant to take readings and then go back to sleep are a perfect fit for what we’re often doing with our Bluetooth-to-Cloud. And while Thread actually runs using 802.15.4, it’s nearly universal that the pairing process for Thread devices is done over Bluetooth.

Challenges with this board

If you’re looking to run the FRDM-MCXW71 on your bench, there are two potential pitfalls to getting started (also highlighted in the video above):

1. Getting the LinkServer utility working – This is the debug interface for modern NXP boards. They list JLink as another way to debug this board, but we couldn’t get it working. The tricky part is that LinkServer wasn’t enabled until Zephyr 4.1, whereas our current Bluetooth builds were against 4.0. A bit of reworking in the west manifest and we were able to call out the correct version and also pull in the appropriate NXP HAL to make things build smoothly.
2. The Bluetooth HCI / NBU  – On this board, it’s required that you program the Bluetooth HCI image into a secondary Cortex-M3 processor. This is separate from the build process for Zephyr and requires a tool called blhost. Check out the NBU section of the Zephyr docs for more info.

We’re excited to have another NXP board included in the list of boards that work with Golioth’s Bluetooth-to-Cloud capabilities. We will continue to add new vendors and chipset variations in the coming weeks. If you’d like to join the private access program, sign up here!