[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.

[andreaslarssonublox]

Thanks for the feedback. I tried to just increase the heap size in the linker script:
mbed-os\targets\TARGET_STM\TARGET_STM32F4\TARGET_UBLOX_EVK_ODIN_W2\device\TOOLCHAIN_IAR\stm32f439xx_flash.icf

We can probably just increase it. When increasing it to 0xF000 it seemed to work. However there is a risk it won't work with other apps since it's hard-coded and very dependent on the use case. Is there a way of defining the heap size in some app configuration file instead @bulislaw ?

[0xc0170]

We can probably just increase it. When increasing it to 0xF000 it seemed to work. However there is a risk it won't work with other apps since it's hard-coded and very dependent on the use case. Is there a way of defining the heap size in some app configuration file instead @bulislaw ?

Whats the current size? is it around 48k ? How much RAM does we have available for these targets? what should be the sensible default value?

[yogpan01]

@0xc0170 @bulislaw Any resolution for this now ?

[0xc0170]

@yogpan01 please review this patch (increasing heap size for those 2 platforms to 1/2 RAM) - ARMmbed/mbed-os#3871

[yogpan01]

@0xc0170 This looks fine.
Btw , we have similar issues in K64F board as well with IAR, ARMmbed/mbed-os#3466 , can something similar be done for K64F as well . It will unblock our client on K64F , IAR as well.

[0xc0170]

Btw , we have similar issues in K64F board as well with IAR, ARMmbed/mbed-os#3466 , can something similar be done for K64F as well . It will unblock our client on K64F , IAR as well.

Please send a patch (it with the client and IAR))

[bridadan]

Looks like I can't build with the latest branch of oob_test_mbed-os-5.4. I verified that switching back to commit 5270321 (which I believe was the first RC of mbed OS 5.4) does let the application compile (but of course the application doesn't run correctly).

C:\Users\bridan01\Documents\dev\mbed-os-example-client>mbed compile -m UBLOX_EVK_ODIN_W2 -t IAR
c:\python27\lib\site-packages\fuzzywuzzy\fuzz.py:35: UserWarning: Using slow pure-python SequenceMatcher. Install python-Levenshtein to remove this warning
  warnings.warn('Using slow pure-python SequenceMatcher. Install python-Levenshtein to remove this warning')
Building project mbed-os-example-client (UBLOX_EVK_ODIN_W2, IAR)
Scan: .
Scan: FEATURE_BLE
Scan: FEATURE_COMMON_PAL
Scan: FEATURE_LWIP
Scan: FEATURE_UVISOR
Scan: FEATURE_ETHERNET_HOST
Scan: FEATURE_LOWPAN_BORDER_ROUTER
Scan: FEATURE_LOWPAN_HOST
Scan: FEATURE_LOWPAN_ROUTER
Scan: FEATURE_NANOSTACK
Scan: FEATURE_NANOSTACK_FULL
Scan: FEATURE_THREAD_BORDER_ROUTER
Scan: FEATURE_THREAD_END_DEVICE
Scan: FEATURE_THREAD_ROUTER
Scan: FEATURE_STORAGE
Scan: mbed
Scan: env
Link: mbed-os-example-client
Error[Lp011]: section placement failed
            unable to allocate space for sections/blocks with a total estimated
                      minimum size of 0x34934 bytes (max align 0x8) in
                      <[0x200001b0-0x2002ffff]> (total uncommitted space
                      0x2fe50).
Error[Lp021]: the destination for compressed initializer batch "P2-1" is placed
          at an address that is dependent on the size of the batch, which is
          not allowed when using lz77 compression. Consider using "initialize
          by copy with packing = zeros" (or none) instead.
[ERROR] Error[Lp011]: section placement failed
            unable to allocate space for sections/blocks with a total estimated
                      minimum size of 0x34934 bytes (max align 0x8) in
                      <[0x200001b0-0x2002ffff]> (total uncommitted space
                      0x2fe50).
Error[Lp021]: the destination for compressed initializer batch "P2-1" is placed
          at an address that is dependent on the size of the batch, which is
          not allowed when using lz77 compression. Consider using "initialize
          by copy with packing = zeros" (or none) instead.

[mbed] ERROR: "python" returned error code 1.
[mbed] ERROR: Command "python -u C:\Users\bridan01\Documents\dev\mbed-os-example-client\mbed-os\tools\make.py -t IAR -m UBLOX_EVK_ODIN_W2 --source . --build .\BUILD\UBLOX_EVK_ODIN_W2\IAR" in "C:\Users
\bridan01\Documents\dev\mbed-os-example-client"

Just for fun I tried changing the heap size for that target like was done in this PR: https://github.com/ARMmbed/mbed-os/pull/3871/files#diff-e4c37ceb1dc7db22e3b98d6883f0dfe8L20

The value I chose was 0x12000 which worked! Though I don't how/if this is a general solution though.

[0xc0170]

Thanks Brian for reporting

cc @mazimkhan (to be aware of this)

[bulislaw]

Wasn't the heap change tested? I think @andreaslarssonublox suggested 0xF000 maybe we should go with it, I mean there will still be the limitation of IAR, but we will address the client issue for this release. We can always tweak it later.

[mazimkhan]

Heap change was tested with tls-client example. Above failure means this example (+ libs) requires > 3/8 i.e. > 71K of RAM for static and global data . This largely depends on app and associated libs design. Most of the bigger chunks can be allocated from heap instead of statically declared.
Or perhaps there should be a way to override heap & stack allocations from app config.

I created a map file in IAR workbench. It shows both lwip that uses 0x6414 i.e. 25K and ethernet that uses Rx & Tx buffers 0x17d0 i.e. 5K each of RAM.
See the map file below.
name.map.txt

For now we can find something that suites most of the examples. tls-client at least requires 0x10000 i.e. 64K of heap.

[yogpan01]

@mazimkhan @bulislaw @0xc0170 This example now doesn't compile. Did someone fix this issue for example-client ?

[0xc0170]

@mazimkhan @bulislaw @0xc0170 This example now doesn't compile. Did someone fix this issue for example-client ?

Whats the error? Is it overflow in the section reported above by Brian or ?

[yogpan01]

@0xc0170 Yes the above one reported by Brian. I am now updating README of this example with this as "KNOWN ISSUE".

[MarceloSalazar]

Why are we still having this issue in the 5.4.1 OOB?

[bridadan]

FYI, waiting on this PR to be merged: ARMmbed/mbed-os#3920

[teetak01]

@bridadan I think this issue is fixed. Closing.