[UBLOX_EVK_ODIN_W2 + IAR] Fails to register over WiFi

[bridadan]

Branch: oob_test-mbed-os-5.4

When the UBLOX_EVK_ODIN_W2 is built with the IAR toolchain (with mbed CLI -t IAR option, the -i make_iar exporter, and the -i iar IDE exporter), the device connects to WiFi but fails to register with mbed Connector. It works with GCC_ARM and ARM.

@bulislaw Is it possible this is an issue with the IAR binary driver that's present in mbed OS? Does the basic WiFi socket example work with IAR?

Logs:

Starting mbed Client example in IPv4 mode
[EasyConnect] Using WiFi (ODIN)
[EasyConnect] Connecting to WiFi AndroidAP
[EasyConnect] Connected to Network successfully
[EasyConnect] IP address 192.168.43.54
[EasyConnect] MAC address d4:ca:6e:70:48:37

SOCKET_MODE : TCP
Connecting to coap://api.connector.mbed.com:5684
simulate button_click, device not registered
simulate button_click, device not registered
simulate button_click, device not registered
simulate button_click, device not registered
simulate button_click, device not registered
simulate button_click, device not registered

[ERROR:] M2MInterface::SecureConnectionFailed

[ciarmcom]

ARM Internal Ref: IOTCLT-1529

[JanneKiiskila]

@bridadan @bulislaw

Has anyone done some ODIN UBLOX testing with this: https://github.com/ARMmbed/mbed-os-cliapp using IAR? Seems you're suspecting some issue and well, it's not a client issue in reality.

[bulislaw]

mbed-os-example-wifi works fine for both iar and export make iar.

@andreaslarssonublox

[JanneKiiskila]

Wifi example doesn't use mbedTLS at all, right? That might explain it.
Could be mbedTLS timeout or handshake issue.

[bulislaw]

Not sure how good our test coverage is there, but the tests were passing.

[JanneKiiskila]

Does the WiFi example use the async APIs at all? Client uses ASYNC socket APIs. Those are not tested at all elsewhere as far as I understand.

[bulislaw]

No, wifi example tests mostly wifi and very simple HTTP transaction to verify the link is up.

[bulislaw]

To answer you next question, no we don't have any networking tests run on wifi at the moment. It's planned, we have the tests for Ethernet, but they won't be run on WiFi before we unify the network interfaces (finger crossed for it to happen for 5.5).

[yogpan01]

@bridadan @bulislaw @0xc0170 Is the memory map linker script for IAR quite different from ARMCC and GCC options ? I think there is a difference between ARMCC, GCC and IAR linker scripts. They define different size of stack, heap memory areas for different compilers and that can be the reason for failure for IAR build because client needs more memory (because of TLS certificate handshake) , this example is clearly crossing the memory boundary for IAR builds.

[bulislaw]

There's one big issue with IAR it has to have it HEAP defined at compiler time, so that's done in the linker script. But allocation issue should be easy to spot.

[yogpan01]

@bulislaw from the error that @bridadan posted above , it seems that the malloc in mbedTLS is failing which is causing this issue.

[bulislaw]

I'll take your word for it :) Odin has 256K of RAM, not sure how much is needed for the client. @andreaslarssonublox is there any way to squeeze a little bit more of memory for the HEAP so the behavior is the same across the toolchains?

[yogpan01]

Client definitely doesn't need 256 k RAM but if the memory map script for IAR toolchain is configured to utilize only a very limited memory size which might be lower than client needs then we have an issue.
Having the same HEAP size across different toolchain should ensure the same behaviour for all of them.

[bulislaw]

We can't have it 'the same' unfortunately, because ARM/GCC can use it dynamic and set at boot time, while IAR needs it hardcoded at build time. But maybe @andreaslarssonublox can help you make it work.