Wisun: crash on TLS handshake for NUCLEO_WB55RG

[AlefeFelipe]

Description of defect

The program is crashing on the wisun TLS process for the NUCLEO_WB55RG when using the hardware acceleration (MBEDTLS_CONFIG_HW_SUPPORT), which is active by default. This happens for both, border router and node.

Mbed log:

[INFO][wsbs]: authentication start
[INFO][fhss]: fhss Configuration set, UC channel: 44, BC channel: 45, UC CF: 2, BC CF: 0, channels: BC 43 UC 43, uc dwell: 255, bc dwell: 255, bc interval: 0, bsi:0, ch retries: 0
[INFO][wsps]: Delete old keys, new PAN ID: 54349 network name: Wi-SUN Network
[INFO][ksep]: Initial-key init
[INFO][wsps]: EAPOL target: 6e:70:0f:5f:97:16:50:d6
[INFO][wsps]: Initial EAPOL-Key trickle I: [360,500] 468, t: 462
[INFO][ksep]: Initial EAPOL-Key send, PMKID not set PTKID not set GTKL 0
[INFO][ksep]: Initial-key finished
[INFO][fhss]: fhss Configuration set, UC channel: 44, BC channel: 255, UC CF: 2, BC CF: 2, channels: BC 43 UC 43, uc dwell: 255, bc dwell: 255, bc interval: 1020, bsi:64198, ch retries: 0
[INFO][fhss]: TX slot length: 54ms
[INFO][eaps]: EAP-TLS init
[INFO][eaps]: EAP-TLS recv REQ type IDENTITY id 1 flags 0 len 5
[INFO][eaps]: EAP-TLS start
[INFO][eaps]: EAP-TLS: send RESPONSE type IDENTITY id 1 flags ff len 18
[INFO][eaps]: EAP-TLS recv REQ type TLS id 2 flags 20 len 6
[INFO][eaps]: EAP-TLS: send RESPONSE type TLS id 2 flags 0 len 92
[INFO][eaps]: EAP-TLS recv REQ type TLS id 3 flags c0 len 610
[INFO][eaps]: EAP-TLS: send RESPONSE type TLS id 3 flags 0 len 10
[INFO][eaps]: EAP-TLS recv REQ type TLS id 4 flags 0 len 79
[INFO][tlsl]: no wisun fields on cert

++ MbedOS Fault Handler ++

FaultType: HardFault

Context:
R   0: 2000B5AC
R   1: FFFFFFFF
R   2: 00000000
R   3: 20030000
R   4: 00000000
R   5: 2000B5AC
R   6: 20013250
R   7: 200123CC
R   8: 2000B4C4
R   9: 00000000
R  10: 2000B4E8
R  11: 00000034
R  12: 08001319
SP   : 2000B478
LR   : 08004515
PC   : 0805A844
xPSR : 610F0000
PSP  : 2000B410
MSP  : 2002FFC0
CPUID: 410FC241
HFSR : 40000000
MMFSR: 00000082
BFSR : 00000000
UFSR : 00000000
DFSR : 00000008
AFSR : 00000000
MMFAR: 00000000
Mode : Thread
Priv : Privileged
Stack: PSP

-- MbedOS Fault Handler --

++ MbedOS Error Info ++
Error Status: 0x80FF013D Code: 317 Module: 255
Error Message: Fault exception
Location: 0x805A844
Error Value: 0x2000E568
Current Thread: nanostack_event_thread Id: 0x2000BAE8 Entry: 0x801BD65 StackSize: 0x1800 StackMem: 0x2000A2E8 SP: 0x2000B478 
For more info, visit: https://mbed.com/s/error?error=0x80FF013D&tgt=NUCLEO_WB55RG
-- MbedOS Error Info --

Info from https://github.com/ARMmbed/mbed-os-example-fault-handler project

Crash Info:
    Crash location = HAL_CRYP_DeInit [0x0805A844] (based on PC value)
    Caller location = mbedtls_aes_free [0x08004515] (based on LR value)
    Stack Pointer at the time of crash = [2000B478]
    Target and Fault Info:
        Processor Arch: ARM-V7M or above
        Processor Variant: C24
        Forced exception, a fault with configurable priority has been escalated to HardFault
        Data access violation. Faulting address: 00000000

Target(s) affected by this defect ?

NUCLEO_WB55RG

Toolchain(s) (name and version) displaying this defect ?

GCC_ARM - arm-none-eabi-gcc (GNU Arm Embedded Toolchain 9-2020-q2-update) 9.3.1 20200408 (release)

What version of Mbed-os are you using (tag or sha) ?

mbed-os-6.12.0, but it seems not be working since mbed-os-6.9.0

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

mbed-cli 1.10.4

How is this defect reproduced ?

Just run the https://github.com/ARMmbed/mbed-os-example-mesh-minimal project for the node and the https://github.com/PelionIoT/nanostack-border-router project for the border router, using for both one of the the wisun configs

[felipeLeast]

Hi guys, I'm having the same issue here. Anyone have any ideas? I think this came after the Cube update for the STM32WB. I don't know if there's any relation here. I've tried to run the example code for the mbed-tls on version 6.12 and 6.8 for this board and a few messages appear to be different.

@jeromecoutant can it, maybe, have something to do with that?

[jeromecoutant]

Hi Could you remove HAL_CRYP_DeInit call: https://github.com/ARMmbed/mbed-os/blob/master/connectivity/drivers/mbedtls/TARGET_STM/aes_alt.cpp#L174 and check ?

[AlefeFelipe]

@jeromecoutant It worked, but then when the CRYP peripheral will be deinitialized? I'm worried it will generate another problem later

[jeromecoutant]

HAL_CRYP_DeInit doesn't make so much things... I don't think there is a risk removing it...

[jeromecoutant]

If you have applied the patch, please raise a PR :-) Thx

[0xc0170]

As it's been almost a year without any update, I'll close this as won't fix.