# SAE handshake blocks all application threads for 1.7 to 4.6 s on MM8108-EKH05 (Zephyr, MM-IoT-SDK) **URL:** \ **Category:** Embedded\ **Created:** [October 26, 2026, 10:19pm UTC](https://community.morsemicro.com/t/sae-handshake-blocks-all-application-threads-for-1-7-to-4-6-s-on-mm8108-ekh05-zephyr-mm-iot-sdk/2127 "2026-10-26T22:19:24Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Scott\_Lovett](https://avatars.discourse-cdn.com/v4/letter/s/4bbf92/32.png) [@Scott\_Lovett](https://community.morsemicro.com/u/Scott_Lovett)\ **Post date:** [October 26, 2026, 10:19pm UTC](https://community.morsemicro.com/t/sae-handshake-blocks-all-application-threads-for-1-7-to-4-6-s-on-mm8108-ekh05-zephyr-mm-iot-sdk/2127/1 "2026-10-26T22:19:25Z")
I’m running the MM-IoT-SDK on the MM8108-EKH05 (STM32U585, Zephyr 3.7.1) as a mobile station that associates to a HaLowLink 2 (WPA3-SAE) intermittently from the edge of range, and I’ve traced a long application stall to the supplicant. With a 1 ms timer-interrupt sampler I see the `evtloop` thread (created at priority 0 in `umac_evtloop.c:109` / `mmosal_shim_zephyr.c:89`) running continuously for: - about 0.94 s in `wpa_s_setup_sae_pt` (password element, computed for groups 19, 20 and 21 since no group list is passed), - about 1.69 s in `sme_send_authentication` building the SAE commit, - about 1.70 s in `sae_process_commit` / `sae_derive_k_ecc` processing the AP’s commit. A full exchange is about 4.6 s, during which every application thread is starved (scheduler not locked, interrupts not masked; it is simply priority 0 compute). My sensor sampling threads at priorities 7 and 8 lose that whole window on every association attempt. Three questions: 1. Is the `evtloop` priority of 0 required for correct radio timing, or is it safe to lower it so application threads can preempt the SAE math? If there’s a supported way to set it, I’d rather use that than patch the shim. 2. Does the supplicant support using the STM32U5’s PKA (hardware ECC) for the SAE group operations, or is there a hook for it? Software ECC at this cost is the whole stall. 3. Is PMKSA caching supported end to end (station and HaLowLink 2), so that a reconnect to a recently seen AP skips SAE? I’m already keeping the supplicant state across reconnects and restricting to group 19, which removes the 0.94 s step but not the commits. Happy to share the sampler output or a minimal reproduction. Versions: MM8108-EKH05: - MM-IoT-SDK: 2.10.4, Morse Micro’s release of 13 Mar 2026. - Radio chip firmware in that SDK: rel\_1\_17\_6\_2026\_Feb\_23. - Zephyr: 3.7.1. It comes from Morse Micro’s mm-iot-zephyr, which our workspace has at c9e2c11 (10 Sep 2026, with our patches applied). HaLowLink 2 (the AP at 10.77.0.11): - OpenWrt 23.05.6, Morse build 2.11.13 (r0+24542-ada60cb7ea). - Radio firmware and driver: rel\_1\_17\_9\_2026\_Apr\_20. morse\_cli and the kernel driver report the same. - Kernel: 5.15.189. Thank you! ---
**Author:** ![ldennis](https://avatars.discourse-cdn.com/v4/letter/l/3ab097/32.png) [@ldennis](https://community.morsemicro.com/u/ldennis)\ **Post date:** [October 27, 2026, 7:33am UTC](https://community.morsemicro.com/t/sae-handshake-blocks-all-application-threads-for-1-7-to-4-6-s-on-mm8108-ekh05-zephyr-mm-iot-sdk/2127/2 "2026-10-27T07:33:46Z")
Hi @Scott_Lovett Thanks for the detailed write up! We actually enabled use of the STM32U5 PKA in the 2.10 mm-iot-sdk, I suspect this has not been added to the Zephyr port. I will raise this with the Zephyr team. If you would like to have a go at porting it yourself, I would look at the `mm-iot-sdk` as a reference. In the mm-iot-sdk build system we enable it with `BUILD_WITH_MBEDTLS_ECC_HW_CRYPTO=y` and `BUILD_SUPPLICANT_CRYPTO_FROM_SOURCE=y`. That will pull in extra files + defines in the platform here: > We also dropped out compilation of the option groups 20 and 21 in our recent 2.14 release. To take the runtime benefits against an older SDK, the recommended approach is to explicitly set `sta_args.sae_owe_ec_groups[0] = 19` As an aside I would recommend updating to the latest mm-iot-zephyr release if you can, which is based on 2.13. That will bring in various improvements in the SDK and the FW, particularly for mm8108. Hope that helps ---
**Author:** ![Scott\_Lovett](https://avatars.discourse-cdn.com/v4/letter/s/4bbf92/32.png) [@Scott\_Lovett](https://community.morsemicro.com/u/Scott_Lovett)\ **Post date:** [October 27, 2026, 11:59am UTC](https://community.morsemicro.com/t/sae-handshake-blocks-all-application-threads-for-1-7-to-4-6-s-on-mm8108-ekh05-zephyr-mm-iot-sdk/2127/3 "2026-10-27T11:59:26Z")
Thanks @idennisidennis, that’s very helpful. We’re already restricting to group 19, and we’ll try porting the PKA support into our Zephyr build today. Two follow-ups: 1. Is it safe to run the supplicant event thread below the highest priority, or does the driver depend on it? 2. Does PMKSA caching work with SAE in the MCU stack, so reassociation to the same AP skips the full exchange? Anything needed on the HaLowLink 2 side? 3. Would an MM8108 station on chip firmware 2.0 (mm-iot-zephyr 0.1.0) work with a HaLowLink 2 on 1.17.9, or does the HaLowLink 2 need a matching firmware update first? _Quick Update:_ We ported the STM32U5 PKA ECC path into our Zephyr 3.7 build (wrapping mmint\_crypto\_ec\_point\_mul, software fallback kept). Two findings for anyone else doing this: - The PKA’s INITOK needs the RNG running, and Zephyr 3.7’s entropy driver switches the RNG off between refills, so we back-ported Zephyr 4.4’s “keep RNG on while PKA is in use” check. - ST’s HAL doesn’t check the PKA error word after a scalar multiply, so a failure can come back as OK with a wrong point. Result with SAE group 19: the supplicant thread’s longest blocking stretch per authentication went from about 1.75 s to about 0.2 s, and connect time from 7.4 s to 4.1 s. Thanks for the pointer. Also, if the Zephyr team adds PKA support, could you let us know which release it lands in? ---
**Author:** ![ajudge](https://avatars.discourse-cdn.com/v4/letter/a/c2a13f/32.png) [@ajudge](https://community.morsemicro.com/u/ajudge)\ **Post date:** [October 27, 2026, 10:58pm UTC](https://community.morsemicro.com/t/sae-handshake-blocks-all-application-threads-for-1-7-to-4-6-s-on-mm8108-ekh05-zephyr-mm-iot-sdk/2127/4 "2026-10-27T22:58:26Z")
Hi @Scott_Lovett Speaking as he Zephyr team here. The priority of the Zephyr port has been portability across microcontroller vendors, this means where possible, we’ve been relying on vendor provided drivers and Zephyr’s libraries which as you’ve seen definitely leaves room on the table for performance improvements. Our post 0.1.0 focus is on performance, and we hope to have some useful improvements coming in the near future. * * * In the version you are using, we were relying on Zephyr’s mbedtls - though with some minimum configuration we’ve provided to enable everything required for Wi-Fi HaLow. If I recall correctly, this has an option to call crypto PSA drivers where supported. It might be worth having a look at additional mbedtls configuration to see if that is easy enough to turn on. Unfortunately, from Zephyr 4.4, mbedtls has moved on to version 4, with TF-PSA-Crypto providing crypto implementations. To retain compilation, we opted to compile the mbedtls version provided by the MM-IoT-SDK in such a way that it doesn’t collide with the Zephyr provided mbedtls to retain portability. This has effectively locked users into software crypto, without SoC specific changes which break that portability. We have some changes internally prepared better to support this change, but it they are fairly major and are undergoing validation. The complexity comes as TF-PSA-Crypto is lacking functionality required for WPA3 - see [ARM PSA crypto 1.4.0: Implement WPA3-SAE support · Issue #709 · Mbed-TLS/TF-PSA-Crypto · GitHub](https://github.com/Mbed-TLS/TF-PSA-Crypto/issues/709). Anyway, apologies for the complication here. My best suggestion would be to look at enabling mbedtls psa drivers in 3.7. I’m optimistic that is an easy feature to configure to enable hardware crypto. If that’s not possible, pulling in the ecp\_alt files described by ldennis into the mbedtls build at later versions, and breaking SoC portability may be required in the interim. ---
**Author:** ![Scott\_Lovett](https://avatars.discourse-cdn.com/v4/letter/s/4bbf92/32.png) [@Scott\_Lovett](https://community.morsemicro.com/u/Scott_Lovett)\ **Post date:** [October 28, 2026, 12:13pm UTC](https://community.morsemicro.com/t/sae-handshake-blocks-all-application-threads-for-1-7-to-4-6-s-on-mm8108-ekh05-zephyr-mm-iot-sdk/2127/5 "2026-10-28T12:13:35Z")
> [@ajudge](#): > > Hi @Scott_Lovett > > Speaking as he Zephyr team here. > The priority of the Zephyr port has been portability across microcontroller vendors, this means where possible, we’ve been relying on vendor provided drivers and Zephyr’s libraries which as you’ve seen definitely leaves room on the table for performance improvements. Our post 0.1.0 focus is on performance, and we hope to have some useful improvements coming in the near future. > > * * * > > In the version you are using, we were relying on Zephyr’s mbedtls - though with some minimum configuration we’ve provided to enable everything required for Wi-Fi HaLow. If I recall correctly, this has an option to call crypto PSA drivers where supported. It might be worth having a look at additional mbedtls configuration to see if that is easy enough to turn on. > > Unfortunately, from Zephyr 4.4, mbedtls has moved on to version 4, with TF-PSA-Crypto providing crypto implementations. To retain compilation, we opted to compile the mbedtls version provided by the MM-IoT-SDK in such a way that it doesn’t collide with the Zephyr provided mbedtls to retain portability. This has effectively locked users into software crypto, without SoC specific changes which break that portability. > > We have some changes internally prepared better to support this change, but it they are fairly major and are undergoing validation. The complexity comes as TF-PSA-Crypto is lacking functionality required for WPA3 - see [ARM PSA crypto 1.4.0: Implement WPA3-SAE support · Issue #709 · Mbed-TLS/TF-PSA-Crypto · GitHub](https://github.com/Mbed-TLS/TF-PSA-Crypto/issues/709) . > > Anyway, apologies for the complication here. My best suggestion would be to look at enabling mbedtls psa drivers in 3.7. I’m optimistic that is an easy feature to configure to enable hardware crypto. > If that’s not possible, pulling in the ecp\_alt files described by ldennis into the mbedtls build at later versions, and breaking SoC portability may be required in the interim. Awesome, thank you. That context helps. We went the interim route: wrapping mmint\_crypto\_ec\_point\_mul in our Zephyr 3.7 build so P-256 multiplies go to the PKA, with the stock software multiply as fallback. It’s now validated in testing (0.2s against 3.6s) in real world conditions. Much appreciated!