Support Request on STM32 and Morse-Micro-IoT-SDK-2.5.2 Usage

Hi everyone,

I am developing a custom board based on STM32 microcontrollers and have started exploring the resources you provide for integrating with your Wi-Fi HaLow modules.
I have a few technical questions and would greatly appreciate your support.

My project involves sending UDP packets at high frequency, between 5 and 10 milliseconds, and simultaneously managing multiple CAN lines. After analyzing the minimum requirements for the Morse-Micro-IoT-SDK-2.5.2 and the NUCLEO boards compatible with your devkits, I have identified the STM32 F4, WB, and U5 series as the main options.

To meet the need for managing multiple CAN lines without using external modules (such as SPI-based CAN controllers), I am considering the STM32F439 series. Although this microcontroller is not very recent, I find it a reliable solution.
However, I would like to know if you think it is suitable for my requirements, given the available hardware resources: 2MB of flash memory and 256KB of RAM.

Additionally, I would like to understand whether microcontrollers with integrated hardware accelerators for cryptographic functions (e.g., AES, MD5, SHA) are critical for Wi-Fi HaLow or if they are unnecessary in this context. Are there any specific recommendations or considerations regarding these features to improve performance with your modules or SDK?

In the coming months, I will have the opportunity to develop and test code on different NUCLEO boards to validate my setup and evaluate its performance.

Finally, while exploring your SDK, I appreciated the well-organized code structure and practical examples provided, but I found it challenging to understand how to start a project from scratch. I am used to working with STM32CubeIDE and HAL/LL libraries, so I am trying to figure out how to integrate with your development environment and follow your best practices.

Thank you in advance for your help and any suggestions you can provide! :smiley:

Hey @aletinti

I apologise if my response today is brief. I’m currently traveling and writing detailed responses on my phone is challenging!

2MB of Flash and 256kB of RAM meets our recommended minimum. So this should be sufficient! Our docs recommend 2MB+/192kB+

Regarding cryptographic accelerators on the host processor - these are only used at association time (and some corner cases). If you don’t have these crypto blocks available then you will find your association times to be a bit longer with software crypto compared to when hardware crypto is used. In saying that, our default libmorse.a should be host side software crypto anyway, so you’re unlikely to be using hardware acceleration unless you’ve used libmorse.nocrypto.a.
Note that aside from association, other cryptographic functions related to Wi-Fi will be handled by the MM6108.

However, do you intend to use TLS or some other application level security in your project? Don’t forget to consider the upper layer cryptographic needs as well!

We do have some support for STM32Cube by way of a pack which can be installed. See Releases · MorseMicro/mm-iot-cmsis · GitHub. This can be installed into your project with STM32CubeMX.

That pack is a little out of date unfortunately, which is why it was buried as a release artefact, we have an update coming imminently, and I’ll make sure to include usage documentation with that update.

I’ll let you know when it is online!

1 Like

Thank @ajudge very much for your reply!
I’ve had a look at the release, and after checking the /HaLow_example/.project example file, I feel more comfortable with the environment. Once I have the test boards available, I will definitely try this type of development.

One last technical question concerns clock speeds:

  • What are the maximum speeds you can achieve with your modules over SDIO and SPI with STM microcontrollers?
  • Are F4/U5 fast enough to handle your chip at its maximum speed, or would you recommend me switch to a more powerful series?

I’m asking because I’m concerned that, with high throughput and a very short interval between packet, the microcontroller might face bottlenecks, especially if it’s also handling large amounts of data processing.

What experiences and results have you had in similar scenarios?
Thanks again for your support! :blush:

Our primary internal test platform is the STM32U575, and for the microcontrollers we’ve tested, this is our best performing platform.
We do conduct some basic throughput testing on the STM32F429 amongst a couple of others. The data below should cover both questions. All measurements in Mbps.

Device UDP RX UDP TX TCP RX TCP TX
U575 SPI 13 17.5 8 6.5
U575 SDIO 19.5 22.5 9 7
F429 SPI 13.8 15.8 8 6.5

I’ll need to confirm the exact parameters used for these tests. Packet spacing, payload size, bus clock speed amongst many other variables can impact measured network throughput.

TCP throughput is further impacted by a number of additional variables. One immediate example is memory limitations preventing window size scaling and network stack configuration for protocol specific features (eg selective acknowledgements, congestion control and so on).

Networking can get complex! Hopefully the numbers above serve as a suitable guide.