Direct BLE Communication on NXP FRDM‑MCXW71 Using Windows PC

[Rudy25]

Hi all,

Development Environment:
Hardware & tools
Board: NXP FRDM-MCXW71
SDK: 25.09.00
IDE: MCUXpresso v25.6.136
Starting example: eatt_peripheral_bm (Bluetooth Wireless)
NBU firmware/binaries (from middleware/wireless/ble_controller/bin):
- mcxw71_nbu_ble_hosted.sb3
- mcxw71_nbu_ble_hadm_hosted.sb3
- mcxw71_nbu_ble_xp_hosted.sb3
I’m unsure which one is correct and currently use mcxw71_nbu_ble_hosted.sb3. Please explain the differences and which I should pick.

Goal:
I want a Windows PC to use its built-in Bluetooth (no USB serial intermediaries) to talk directly to the MCXW71 over BLE and ultimately perform OTA firmware updates.
To test the feasibility, I modified eatt_peripheral_bm to add a custom service for PC to BLE device data and BLE device to PC notifications, then wrote a simple Python client (Bleak/WinRT) that:
1. Connects (works)
2. Enables notifications (works)
3. Receives BLE device to PC notification data (works)
4. Writes data PC to BLE device (not working). I don’t see gEvtAttributeWrittenWithoutResponse_c or gEvtAttributeWritten_c in my callback.

Questions:
1. Is my goal achievable on MCXW71?
2. If yes, where should I look so gEvtAttributeWrittenWithoutResponse_c / gEvtAttributeWritten_c are triggered?
3. Is eatt_peripheral_bm a good base, or is there a more suitable example for building my application?

Thank you very much!

[Rudy25]

Hi all,

We are now able to perform Over-the-Air (OTA) firmware updates directly using the built-in Bluetooth adapter on a Windows PC.
Initially, the MCU BLE device runs the OTAP client sample application. We then update the firmware using the Wireless UART sample application.
However, after switching to the Wireless UART firmware, subsequent OTA updates are no longer possible because the OTAP implementation is no longer present.
To work around this, we merged the OTAP client functionality into the Wireless UART application so that OTA updates can continue after the update (i.e., Wireless UART + OTAP client combined firmware).
This solution works, but it is not ideal. Including the OTAP implementation in the main firmware increases overall image size, which slows down the OTA update process. What we would like instead is to place the OTAP implementation at a fixed memory location that will not be overwritten during firmware updates.
I believe this is achievable, but it likely requires modifying the bootloader or its configuration so that it correctly references the location of the new firmware image.
Additionally, we want to support dual-image booting, so OTA updates should store the newly downloaded image in a separate memory location.
To better understand things, I started reading about bootloaders. In the MCUBOOTFS documentation, three MCU bootloader types are mentioned:
- ROM Bootloader
- Flashloader
- Flash-Resident Bootloader

My understanding is that the MCXW71 microcontroller uses the ROM Bootloader.
Based on this, I would like to get more information on the following topics:
1) Where can I find documentation for the ROM Bootloader, including details about its internal flow (startup sequence, firmware update through USB, OTA update flow, etc.)?
2) Where can I find the ROM Bootloader source code?
I understand it is pre-programmed into the device. Is this a one-time programmed component, or can end users update the ROM bootloader if a newer version becomes available?
3) How does secure boot work on the MCXW71 microcontroller?
4) How is secure OTA firmware updating handled on the MCXW71?
5) What is the recommended approach for secure key generation, key storage, and key management?
6) Do you have a sample linker file demonstrating dual-image booting with a fixed memory location for the OTAP implementation?
If not, a sample memory map showing dual-image layout plus a dedicated OTAP location would be sufficient.

Thank you very much!

[sofiaurueta]

Hello,
Hope you are doing well.

Regarding the binaries found in the SDK path (middleware/wireless/ble_controller/bin):

"mcxw71_nbu_ble_hosted" is the standard BLE 5.3 controller firmware that supports general BLE features.

"mcxw71_nbu_ble_hadm_hosted" stack includes support for Channel sounding features.

"mcxw71_nbu_ble_xp_hosted" stack enables experimental features such as DBAF and ACS.

You can read more about supported stack features and capabilities on Wireless connectivity middleware overview. If your application does not use any of the experimental features, "mcxw71_nbu_ble_hosted.sb3" file is correct.

As a starting point, I would recommend to first run the OTAP client example. You can follow the process in 5.11 Over the Air Programming (OTAP) from the Bluetooth Low Energy Demo Applications User’s Guide.

Also, AN14396 provides the steps and process for integrating the OTAP Client Service into a BLE peripheral device. This document uses the wireless_UART example, but can also be implemented in a custom application by incorporating the OTA client files following the methodology described in section 4.1

Please let me know if this information is helpful!

Best regards,
Ana Sofia.