Hardware acceleration is not functional

[juhaylinen]

Description

• Type: Bug
• Priority: Major

---

Bug

Target
UBLOX_EVK_ODIN_W2

Toolchain:
GCC_ARM|ARM|IAR

mbed-cli version:
(1.2.2)

mbed-os sha:
ad284b2 (mbed-os-5.8.0)
or
addec7b (mbed-os-5.8.1)

Expected behavior
DTLS handshake works and device connects to mbed cloud

Actual behavior
DTLS handshake fails and device fails to connect to mbed cloud

Steps to reproduce
clone https://github.com/ARMmbed/mbed-cloud-client-example

Edit file mbed_cloud_client_user_config.h to change transport mode from TCP to UDP
-#define MBED_CLOUD_CLIENT_TRANSPORT_MODE_TCP
+#define MBED_CLOUD_CLIENT_TRANSPORT_MODE_UDP

update mbed-os version to 5.8.0 or 5.8.1
compile the client example for UBLOX_EVK_ODIN_W2

---

Connection works if TCP is used
Workaround for UDP connection issue is to disable SHA256 hardware acceleration from file
https://github.com/ARMmbed/mbed-os/blob/master/features/mbedtls/targets/TARGET_STM/TARGET_STM32F4/TARGET_STM32F439xI/mbedtls_device.h

[teetak01]

@juhaylinen the public example does not support Mbed OS 5.8 yet. It will be enabled only with 1.3.1 version of Cloud Client.
[Mirrored to Jira]

[JanneKiiskila]

@andreaslarssonublox

[Mirrored to Jira]

[TuomoHautamaki]

@ARMmbed/team-ublox
[Mirrored to Jira]

[SeppoTakalo]

NOTE: Broken after this PR which enabled HW acceleration #5630

[Mirrored to Jira]

[JanneKiiskila]

Ping - @adustm - any ideas/input to this?

[Mirrored to Jira]

[adustm]

Hello,

Do you think this could be related to this ?
#6003

I don't think that PR#5630 has been merged in 5.8.0 but much earlier.

[Mirrored to Jira]

[juhaylinen]

Yes, I think it's related.
#5630 broke Odin's wifi connectivity and it was partly fixed in #6032. (Commits 67772a5 and 34099ba)
Issue in DTLS handshake was found recently
[Mirrored to Jira]

[adustm]

Could you clarify if the use case UDP mode + mbed-os 5.8.0 + UBLOX_EVK_ODIN_W2 is working ?

Kind regards
[Mirrored to Jira]

[andreaslarssonublox]

We'll have a look at it. Internal Jira ticket: TE_OM2-175.
[Mirrored to Jira]

[JanneKiiskila]

@andreaslarssonublox @adustm - any news on this case?

[Mirrored to Jira]

[0xc0170]

We'll have a look at it. Internal Jira ticket: TE_OM2-175.

Please keep us updated
[Mirrored to Jira]

[andreaslarssonublox]

Can you check this @asifrizwanubx?
[Mirrored to Jira]

[asifrizwanubx]

We will update on it soon.
[Mirrored to Jira]

[JanneKiiskila]

Any news on this one?

[Mirrored to Jira]

[asifrizwanubx]

is it reproducible on mbed-os-5.9.0?
[Mirrored to Jira]

[asifrizwanubx]

Work around didn't worked on mbed-os-5.9.0
[Mirrored to Jira]

[asifrizwanubx]

I am getting build error on 5.8.0

Compile [ 16.3%]: m2mnsdlinterface.cpp

[Error] m2mnsdlinterface.cpp@762,24: 'COAP_STATUS_BUILDER_BLOCK_SENDING_DONE' was not declared in this scope
[ERROR] .\mbed-cloud-client\mbed-client\source\m2mnsdlinterface.cpp: In member function 'uint8_t M2MNsdlInterface::received_from_server_callback(nsdl_s*, sn_coap_hdr_s*, sn_nsdl_addr_s*)':
.\mbed-cloud-client\mbed-client\source\m2mnsdlinterface.cpp:762:24: error: 'COAP_STATUS_BUILDER_BLOCK_SENDING_DONE' was not declared in this scope
             } else if (COAP_STATUS_BUILDER_BLOCK_SENDING_DONE == coap_header->coap_status &&
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Mirrored to Jira]

[teetak01]

You are using 1.4.0 version of Cloud Client? You can either downgrade back to 1.3.2 or test with Mbed OS 5.9.x. This is also broken with 5.9.3/master.

1.4.0 Cloud Client has dependency to mbed-coap 4.5.0 (Which is not available in Mbed OS 5.8.x)
[Mirrored to Jira]

[asifrizwanubx]

I have done investigation of odin drivers but there is no relation between odin drivers with disable\enable SHA256 hardware acceleration. The workaround didn't worked with the trace enable due to which I was not able to narrow down the issue. Any Suggestion?
[Mirrored to Jira]

[asifrizwanubx]

DTLS handshake also fails on Ethernet interface of UBLOX_EVK_ODIN_W2 with enable SHA256 hardware acceleration. I have no other ST board (hardware acceleration supported) due to which I will not able to verify the SHA256 hardware acceleration and DTLS. Could you please verify the same scenario on any other ST board?
[Mirrored to Jira]

[asifrizwanubx]

mbed-cloud-client-example not supported for NUCLEO_F439ZI with bootloader.

D:\GIT\TE_OM2-175\mbed-cloud-client-example>python tools/combine_bootloader_with_app.py -m NUCLEO_F439ZI -a BUILD/NUCLEO_F439ZI/GCC_ARM/mbed-cloud-client-example.bin -o combined.bin
usage: combine_bootloader_with_app.py [-h]
                                      [-m {k64f,nucleo_f429zi,ublox_evk_odin_w2}]
                                      [-b BOOTLOADER] -a APP [-c APP_ADDR]
                                      [-d HEADER_ADDR] -o OUTPUT
                                      [-s SET_VERSION] [-nb]
combine_bootloader_with_app.py: error: argument -m/--mcu: invalid choice: 'nucleo_f439zi' (choose from 'k64f', 'nucleo_f429zi', 'ublox_evk_odin_w2')

Tried without the bootloader, stuck on "developer flow"

Mbed OS version 5.9.0
mcc_platform_storage_init() - bd->size() = 7759462400
mcc_platform_storage_init() - BlockDevice init OK.
Start simple mbed Cloud Client
Start developer flow

[Mirrored to Jira]

[SeppoTakalo]

I would assume the bootloader to be exactly the same between Ublox ODIN W2 and F439ZI, but it is named after ODIN in the Client.
[Mirrored to Jira]

[asifrizwanubx]

F439ZI app didn't worked with Ublox ODIN W2 bootloader .
[Mirrored to Jira]

[asifrizwanubx]

@SeppoTakalo

Is there any way of enabling minimum logging, which will not effect the application.
[Mirrored to Jira]

[SeppoTakalo]

@asifrizwanubx Not a generic one.

Some modules use mbed-trace library, which can be enabled by having "mbed-trace.enable": 1, in App json and then defining printing functions for it.

For example:

void trace_printer(const char* str)
{
    printf("%s\r\n", str);
    cmd_output();
    fflush(stdout);
}

// in main()
mbed_trace_init();
mbed_trace_print_function_set( trace_printer );

[Mirrored to Jira]

[asifrizwanubx]

I tried this one but it seems me that it effect the timing issue of DTLS. Even the working scenario start failing.
[Mirrored to Jira]

[SeppoTakalo]

Yes, printing to serial port slows down the application.
But that is the only trace line out from the device. Unfortunately.

Enabling buffering on serial port might help a little bit
"platform.stdio-buffered-serial": true, in mbed_app.json does this.

That would allow printf() to quickly push stuff into serial buffer which is then handled by UARTSerial class. It uses interrupt to pump out the data. So tracing should now have minimal effect, until the buffer is full.

Buffer size can be changed by "drivers.uart-serial-txbuf-size": 512 (or bigger)

Name: drivers.uart-serial-txbuf-size
    Description: Default TX buffer size for a UARTSerial instance (unit Bytes))
    Defined by: library:drivers
    Macro name: MBED_CONF_DRIVERS_UART_SERIAL_TXBUF_SIZE
    Value: 256 (set by library:drivers)

Name: platform.stdio-buffered-serial
    Description: Use UARTSerial driver to obtain buffered serial I/O on stdin/stdout/stderr. If false, unbuffered serial_getc and serial_putc are used directly.
    Defined by: library:platform
    Macro name: MBED_CONF_PLATFORM_STDIO_BUFFERED_SERIAL
    Value: 1 (set by application[*])

[Mirrored to Jira]

[RobMeades]

Just FYI, I have found in the past that using mbed-trace over the serial port is too intrusive, introduces too many delays, however the ODIN module supports SWO and recent changes in mbed should allow printf() to be routed out over SWO, which should be less intrusive.

So if you have SWO support in your debugger and you have a debugger (with either GDB or some SWO reading SW in the case of the Segger debugger) connected, all you should have to do is add the following code to your application to divert prints to SWO:

#include "SerialWireOutput.h"

// Hook into the weak function and allow Serial Wire Output
namespace mbed {
    FileHandle *mbed_target_override_console(int)
    {
         static SerialWireOutput swo;
         return &swo;
    }
}

[Mirrored to Jira]

[SeppoTakalo]

SerialWireOutput.h is under #if defined(DEVICE_ITM) and only very few devices enable that.
[Mirrored to Jira]

[RobMeades]

@asifrizwanubx we should maybe put ITM support on the list for ODIN as it's really rather useful if you don't want to give up a serial port for debug purposes or want to suffer the delay of serial port operations.
[Mirrored to Jira]

[JanneKiiskila]

@ARMmbed/team-ublox - any news on this one? This one has been pending quite long time w/o any resolution.

[Mirrored to Jira]

[asifrizwanubx]

@JanneKiiskila

As I already mentioned above this is due to hardware acceleration.

DTLS handshake also fails on Ethernet interface of UBLOX_EVK_ODIN_W2 with enable SHA256 hardware acceleration. I have no other ST board (hardware acceleration supported) due to which I will not able to verify the SHA256 hardware acceleration and DTLS. Could you please verify the same scenario on any other ST board?
[Mirrored to Jira]

[teetak01]

@asifrizwanubx from our tests (with mbed-cloud-client-example):

Board	Stack	DTLS	TLS
Nucleo F429ZI	LWIP IPv4	OK	OK
Nucleo F411RE	WIFI IDW01M1 IPv4	NOK	OK
Ublox Odin W2	WIFI IPv4	NOK	OK
Ublox Odin W2	LWIP IPv4	NOK	OK
[Mirrored to Jira]

[asifrizwanubx]

@teetak01
F429ZI (STM32F429ZI) has no support for cryptographic acceleration (hardware acceleration).
[Mirrored to Jira]

[hesee]

Experiencing similar issue with STM32F437 DTLS handshake when enabling crypto HW accel. Mbed OS 5.9.5 & Mbed Cloud Client 1.4.0
[Mirrored to Jira]

[teetak01]

I was able to connect with Ublox Odin EVK W2 + DTLS after disabling the HW support.

diff --git i/features/mbedtls/platform/inc/platform_mbed.h w/features/mbedtls/platform/inc/platform_mbed.h
index efb5b6d..c0208a5 100644
--- i/features/mbedtls/platform/inc/platform_mbed.h
+++ w/features/mbedtls/platform/inc/platform_mbed.h
@@ -22,7 +22,7 @@
 #endif
 
 #if defined(MBEDTLS_CONFIG_HW_SUPPORT)
-#include "mbedtls_device.h"
+//#include "mbedtls_device.h"
 #endif

Internal ticket: https://jira.arm.com/browse/IOTSSL-2507

[Mirrored to Jira]

[asifrizwanubx]

@teetak01

I was able to connect with Ublox Odin EVK W2 + DTLS after disabling the HW support.

its already mentioned in the description of issue by @juhaylinen. Ublox Odin EVK W2 + DTLS is working without HW cryptographic. Could you explain the difference?
[Mirrored to Jira]

[teetak01]

@asifrizwanubx same thing. I only verified with out latest development version and moved the issue to correct team to properly fix the issue. This has been hanging way too long here.

Also another change that is needed is:

        "STM_EMAC": {
             "lwip.pbuf-pool-size" : 16,
             "lwip.mem-size"       : 12500
        }

For many boards something like this is also required to make the DTLS handshake to go through.

[Mirrored to Jira]

[JanneKiiskila]

Mbed OS 5.10 might change that a tad bit (for better), as the packet handling for UDP has been optimized in MbedTLS side (ref: Mbed-TLS/mbedtls#1951, Mbed-TLS/mbedtls#1918).

[Mirrored to Jira]

[screamerbg]

CC @adustm @bcostm @LMESTM
[Mirrored to Jira]

[screamerbg]

See #6545 (comment)
[Mirrored to Jira]

[teetak01]

@screamerbg I would rename this issue as "Mbed OS hardware acceleration is broken". This is not board-specific. See my comments above for workaround and internal ticket.
[Mirrored to Jira]

[Patater]

Note that this issue appears to be what @kjbracey-arm observed in #5079 (comment)
[Mirrored to Jira]

[adbridge]

Internal Jira reference: https://jira.arm.com/browse/IOTCRYPT-437

[0xc0170]

@oliverjharper Closing in Jira will close it also on Github (should this be reopened?).