Space for event loop is allocated twice for mesh configurations about mbed-cloud-client-example HOT 18 CLOSED

@teetak01 @JanneKiiskila @kjbracey-arm
Is this just configuration issue, or should mbed-os have a mechanism in place for cloud client to use the nanostack event loop in co-operation with the mbed-mesh-api?

from mbed-cloud-client-example.

IIRC, the assumption originally when that was written was that mbed-mesh-api's init would get in first, and allocate a big heap to run Nanostack. Cloud client would be the second caller, and that was okay because it used a tiny dynamically-allocated heap - was only used for the event loop, as it used system malloc for all its main structures.

from mbed-cloud-client-example.

Obviously this is all a bit fragile, and I guess something has changed. Looking to see where mesh_system_init is called, I see it

• in the constructor of Nanostack, which would kick in the moment you create an EthernetInterface with it as the default stack.
• in MeshInterfaceNanostack::initialize

Seems like it should probably be in MeshInterfaceNanostack's constructor too.

Can you reorder the test app to ensure the network interface is located for the first time before the client code activates?

from mbed-cloud-client-example.

If you do want to share init code with mbed-mesh-api, we could arrange that, but then you would be sharing the config setting, and those would be defaulting to "big enough for Nanostack", so you'd have to have app config to pull that back down when you knew Nanostack wasn't in use.

from mbed-cloud-client-example.

Can you reorder the test app to ensure the network interface is located for the first time before the client code activates?

Those are quite coupled together and I am not cloud client expert. @teetak01 could you take a look?

from mbed-cloud-client-example.

It's possible that you have already located the network interface first (via NetworkInterface::get_default_instance(), and the issue is due to the lack of init in MeshInterfaceNanostack's constructor.

By code inspection this sequence would initialise the HAL:

LoWPANNDInterface lowpan();
lowpan.initialize(&NanostackRfPhy::get_default_instance())

But MeshInterface::get_target_default_instance() does this:

LoWPANNDInterface lowpan(&NanostackRfPhy::get_default_instance());

and that apparently does not. I think that's a bug.

from mbed-cloud-client-example.

mcc_common_setup.cpp calls the NetworkInterface::get_default_instance, that is called from simplem2mclient.h
SimpleM2MClient has a member MbedCloudClient which has a member ServiceClient which has a member ConnectorClient, which calls ns_hal_init in it's constructor. The member MbedCloudClient is constructed before calling the mcc_common_setup.

from mbed-cloud-client-example.

Yes, the initialising of HAL seems to be a bug and probably fixes issues with EUI64, but doesn't solve this issue straight away.

from mbed-cloud-client-example.

Adding @mikter @artokin

from mbed-cloud-client-example.

Could a get_default_instance call could be done first in the initializer list? Bit subtle, I know...

from mbed-cloud-client-example.

Let's see, at least seems to be possible to do it in the initializer list.
Still the later calls to ns_hal_init are not doing anything, is this intentional that without Nanostack those would still be called? Couldn't just some preprocessor flag solve this race?

from mbed-cloud-client-example.

mbed client uses the ns_hal, so needs it initialised, even if Nanostack isn't in use. Those other calls will start doing something when Nanostack is out of use.

from mbed-cloud-client-example.

ARM Internal Ref: IOTCLT-3172

from mbed-cloud-client-example.

Changing the constructor https://github.com/ARMmbed/mbed-cloud-client-example/blob/master/source/simplem2mclient.h#L49
so that the mcc_platform_init_connection is first in the initializer-list and calling _cloud_client() last on the initializer-list still causes the ConnectorClient to be initialised first thus causing it to call the ns_hal_init first. Are the member objects constructed already before going through the initializer-list?

from mbed-cloud-client-example.

Not sure what happened after changing the initialising order. I have 2 different radio versions, seems that the SPI with the other one doesn't work properly anymore, other is working without problems.

from mbed-cloud-client-example.

Hmm, seems that using tr_info in the mesh_system_init caused the issues with the other version of the radio shield.

Reordering the app so that network interface gets initialised first and thus mesh_system.c calls the ns_hal_init first doesn't seem to bring any ill effects. Now the statically allocated memory is used for the Nanostack heap and calls from cloud client to ns_hal_init are returning immediately.

from mbed-cloud-client-example.

Will be fixed to Client 2.2.0 release.

from mbed-cloud-client-example.

This has been fixed in 2.2.0 release.

from mbed-cloud-client-example.