Acomplishments

The past 2 weeks, I worked on and completed the P2P BLE setup between the STM32 and the ESP32 microcontrollers. In our BLE communication architecture, the STM32 is a GATT server, and the ESP32 is a GATT client. At a high level, as a GATT client, the STM32 advertises and exposes its services; the ESP32 scans and connects to the server and writes/reads data. Both devices initialize the BLE stack on their second CPU core, which support a variety of low power modes. This is ideal, given that our filtering/processing tasks are likely going to consume a significant amount of power.

As for our implementation/process, we ended up not using an RTOS on our STM32. The BLE setup code included on STM32CubeIDE uses a sequencer for BLE that conflicts with some of the tasks on FreeRTOS for example. While we found a workaround for it, we thought it would be more productive to simply not use an RTOS, instead of going through the hassle of fixing linker errors and carefully managing task priorities between sequencer and RTOS tasks. Additionally, there are relatively few subroutines that the STM32 has to execute compared to the ESP32. We were, however, able to get BLE working on its own FreeRTOS task on the ESP32. Fortunately, not much new code had to be written for both microcontrollers. Most time was spent properly configuring the IOC config file for the STM32 and editing a few things like UUID and advertising name. For the ESP32, I was able to reuse most of the GATT Client example code from Espressif. I simply had to modify it so that it would scan for the server with the proper device/characteristic UUIDs and the correct remote device name.

For verification, I used multiple debug logs and redirected them to UART for verification of the existence of the successful case logs. I was also able to set a supervision timeout of 2000 ms for the connection and got the correct disconnection status codes when I disconnected the ESP32 from power.

Progress / Schedule

I’m currently on track with my schedule. The next step would be to integrate Caitlyn’s work with the IMU sensor data, and to test the BLE code once Nick is able to verify the PCBs. During the following days, I will be using an oscilloscope to test BLE latency and taking measurements, so we have something to compare against once we start implementing optimizations.

Deliverables / Next Steps

• Take latency measurements for BLE and SPI/I2C.
• Flash code into PCBs once they’re verified.
• Write mock code to simulate sensor activity and communication.

Accomplishments

This week, I worked with Caitlyn for some of the FreeRTOS integration with the STM32WB55RG Nucleo board. However, I spent most of my time working setting up P2P BLE communication between the STM32 and ESP32.

We’re using the STM32CubeIDE for development on our STM32 board. This allows you to autogenerate configurations so that you don’t have to manually do things like writing a bootloader/RTOS, writing drivers for GPIO and communication protocols like UART, I2C, SPI, BLE, etc. However, there was an issue with getting both RTOS and P2P BLE communication working on the STM32. This is because the P2P code uses a sequencer that conflicts with the RTOS’s scheduler, and therefore the IDE cannot autogenerate code to support both. I saw that at least 2 ST employees have acknowledged this limitation in these 2 ST community forum posts: see post 1 and post 2.

Regardless, with the help of some of the documentation from one of the ST employees, I was able to replace the P2P sequencer code with similar RTOS kernel function calls. So far, the code at least builds and compiles fine. I have documented some of my learnings along the way, as well as the communication architecture for BLE between the ESP and STM in this Google doc.

Progress / Schedule

Currently, I would be a bit behind schedule. The FreeRTOS and P2P setup on both devices has been a challenge, as well as getting accustomed to the new development environment for the microcontrollers. However, I have learned how to debug on both devices via UART and GDB (at least the STM32IDE has a pretty decent GUI for GDB+print debugging), and I have also learned more about the BLE protocol.

In parallel, Caitlyn and I will be testing out some of the IMU sensors and haptic motors.

Deliverables / Next Steps

Next week, I will:

• Work on sending a stream of bytes from one MCU to another and validating with UART with minicom on my machine.
• Test BLE latency between the 2 devices using an oscilloscope via a sequence of GPIO set commands.
• Help with the setup and integration of sensors/motors.

Accomplished

So far, I’ve been working on setting up a development environment for the XIAO ESP32S3 that works on both macOS and Windows. We have decided to move forward with the Espressif-IDF (Espressif-IoT Development Framework), given that Espressif Systems is the company that makes the ESP32 and there is extensive amounts of support online through documentation and forums.

There is a Docker image that is built and published by Espressif on their official Docker Hub account. This makes building ESP32 code seamless across different operating systems. I wrote the Dev Container configuration file for the ESP32 which uses the Espressif image. However, I personally develop on macOS, and have found that the flashing process specifically is easier to do locally, given that Docker spins up a Linux VM and does not run on the macOS kernel. Windows can bypass this with WSL and USB passthrough, on the other hand.

We accomplished writing a simple program that flashes an onboard LED via simple GPIO set calls and delays. The program also launches an additional thread that prints to a serial monitor via UART. This basic multithreading program was possible due to FreeRTOS running on the board after being flashed (it is the default with Espressif-IDF).

Progress / Schedule

According to the gant chart, I completed my part of the “FreeRTOS Setup for ESP32/STM32”. However, “Bluetooth Communication Implementation” is still work-in-progress, and I could not fully finish it this week, so it will carry on to next week.

Most of my time spent went into setting up development environments for microcontrollers, and figuring out the correct software dependencies for our project. This video in particular was pretty helpful in getting set up for macOS. Some code, along with our PCB schematics/layout are in this GitHub repository. Overall, I’m mostly on track. I don’t have an official task for next week, which gives me some slack for Bluetooth communication. I’ll also help Caitlyn with STM32 code.

Deliverables / Next Steps

Next week, I will:

• Finish pushing some of the ESP32 setup code to our GitHub repo.
• Start implementing with wireless communication with 2 microcontrollers.

Accomplished

So far, I have confirmed the use of the XIAO ESP32S3 as the ESP32 platform for this project. The board supports Bluetooth Low Energy (BLE 5.0), which makes it a good candidate for communicating with the STM32Wx family (I have a XIAO ESP32S3 of my own and have tested BLE services with my laptop, with some starter code from the Arduino IDE). On the STM32 side, I have searched the avilable options and identified that the STM32WB series is most relevant, since it includes an integrated BLE stack and has development boards such as the Nucleo-WB55 that provide convenient debugging and GPIO access through STLINK. I have also set up development enviornments for both platforms: Arduino IDE / PlatformIO for the ESP32S3 and STM32CubeIDE / CubeMX for the STM32. In addition, I have reviewed documentation and example projects for BLE communication on both chips to understand their capabilities and constraints. I also found this video to be helpful with BLE  / firmware drivers setup for the STM32WB55.

 Progress / Schedule

At this point, the main task underway is finalizing the STM32 board selection and preparing for proof-of-concept testing. The Nucleo-WB55 is the leading candidate, as it is well-documented, actively supported (frequent posts in ST Community forums), and includes the BLE middleware needed for this project. Once the hardware is secured, I will be able to begin prototyping a minimal BLE connection. The plan is to first establish a simple communication channel where one device (likely the ESP32) advertises a BLE service and the other (STM32) connects to it. This milestone is targeted for completion within the next couple of weeks to stay aligned with the overall project schedule.

Devlierables / Next Steps

The immediate deliverables will include (1) finalized hardware selection of the STM32Wx board, and (2) a working BLE proof-of-concept demonstrating connectivity between the ESP32S3 and STM32. The proof-of-concept will serve as the foundation for the kart’s communication features, such as streaming IMU/flex sensor data or sending control commands. Documentation of the configuration steps, code, and test results will also be included as part of upcoming deliverables to ensure reproducibilty and staying on track with our schedule.