libublox-odin-w2-driver.a incompatible with current master

[VeijoPesonen]

Description

• Type: Bug
• Priority: Major

---

Bug

The binary interface has changed in a way that the binary driver is unusable. The change causing the issue was introduced in commit PR #5428 . The binary driver would need to be recompiled to support changes incorporated to the OS side. Probably requires recompilation of other binary blobs which use the OS services.

Target
u-blox EVK-ODIN-W2

Toolchain:
GCC_ARM

Toolchain version:

arm-none-eabi-g++.exe (GNU Tools for ARM Embedded Processors 6-2017-q2-update) 6.3.1 20170620 (release) [ARM/embedded-6-branch revision 249437]

mbed-os sha:
1394bf95f

Expected behavior
Able to execute Greentea wifi testcase WIFI-CONSTRUCTOR

Actual behavior

[1511263825.04][CONN][INF] found KV pair in stream: {{__testcase_name;WIFI-SCAN}}, queued...
[1511263825.08][CONN][RXD] >>> Running case #1: 'WIFI-CONSTRUCTOR'...
[1511263825.13][CONN][INF] found KV pair in stream: {{__testcase_start;WIFI-CONSTRUCTOR}}, queued...
[1511263825.16][CONN][RXD] Operator new out of memory

Steps to reproduce

mbedls
+-------------------+----------------------+-------------+-------------+--------------------------+-----------------+
| platform_name     | platform_name_unique | mount_point | serial_port | target_id                | daplink_version |
+-------------------+----------------------+-------------+-------------+--------------------------+-----------------+
| UBLOX_EVK_ODIN_W2 | UBLOX_EVK_ODIN_W2[0] | E:          | COM8        | ************************ | 0221            |
+-------------------+----------------------+-------------+-------------+--------------------------+-----------------+
mbed test --compile -c -t GCC_ARM -m UBLOX_EVK_ODIN_W2 --app-config .\TESTS\network\wifi\template_mbed_app.txt -n tests-network-wifi
mbedhtrun -f .\BUILD\tests\UBLOX_EVK_ODIN_W2\GCC_ARM\TESTS\network\wifi\wifi.bin -d E: -p COM8:9600

[mikaleppanen]

@kjbracey-arm Could you describe how the interface from libraries (e.g. from ublox driver) to mbed OS should be made so that we do not run into these kind of problems with future changes.

[0xc0170]

130fffaf8 - This is the commit referenced above. This broke the binary compatibility with this driver (one change - removing _attr private member) 😭 😦

@ARMmbed/team-ublox Can you please update the drivers for upcoming 5.7 (the feature freeze is soon, so would be updated?).

[kjbracey]

I'm not sure we have a general scheme here - I don't believe mbed OS has ever made any effort to preserve binary compatibility, only source compatibility.

If a binary blob is calling any mbed OS APIs, particularly C++ ones, then it's going to be vulnerable to changes.

What I would suggest is what we effectively did with Nanostack - the binary blob contains no C++ and makes no OS calls apart from limited standard C library ones. Instead it calls adapter functions in "nanostack-hal-mbed-cmsis-rtos", all of which are in source form, so can cope with any OS changes. Then the person supplying the binary blob can be in control of the APIs used by the binary.

Either that, or be prepared to issue a new binary at some appropriate point in each release cycle.

[0xc0170]

What I would suggest is what we effectively did with Nanostack - the binary blob contains no C++ and makes no OS calls apart from limited standard C library ones. Instead it calls adapter functions in "nanostack-hal-mbed-cmsis-rtos", all of which are in source form, so can cope with any OS changes. Then the person supplying the binary blob can be in control of the APIs used by the binary.

We shall look at it if binaries are part of our code base (not everything can be open sourced, however that would be good if that is the case).

Either that, or be prepared to issue a new binary at some appropriate point in each release cycle.

This is what has been the case (having updates for minor releases).

[0xc0170]

130fffa - This is the commit referenced above. This broke the binary compatibility with this driver (one change - removing _attr private member) 😭 😦

To be certain, @ARMmbed/team-realtek - this should not affect your libraries, is that correct?

[tung7970]

@0xc0170 There are two libraries, peripheral and wlan. I believe the peripheral library is pure HAL code, and wlan one does not call mbed c++ APIs. @Archcady Please confirm.

[andreaslarssonublox]

@0xc0170 We will generate a new ODIN binary in the next couple of days.

[0xc0170]

Thanks for the prompt updates 💯

[0xc0170]

@andreaslarssonublox How is the update going?

[andreaslarssonublox]

@0xc0170 we will create the PR today.

[VeijoPesonen]

Tested Ok