arm_nwk_interface_up returns -5 (6LoWPAN bootstrap start failed)

[shahab5]

Hi,

I am porting this example application of mbed-client to a ARM m4 based platform with different PHY chip.

The sequence of instructions executed are,

app_start registers PHY APIs, two of which get called immediately (rf_interface_state_control & rf_address_write). _device_id, _mesh_network_handler and _network_interface_id are initialized.

Followed by connect()

eventOS_scheduler is used instead of minar for testing purposes.

After a set of events, nd_tasklet_main is called, with ARM_LIB_TASKLET_INIT_EVENT followed by APPLICATION_EVENT. nd_tasklet_configure_and_connect_to_network() calls arm_nwk_interface_up( with network_interface_id = 0). It returns -5 and

Bootstrap start failed

Can someone point me to error codes of this API? Did I miss anything? Is the sequence of API calls documented? If so, please point.

Thanks, Shahab

[ciarmcom]

ARM Internal Ref: ONME-2551

[shahab5]

I apologize for being restless, but I am badly stuck. Quick help is much appreciated.

Thanks

[shahab5]

Hi,

Please can somebody update this ?

Thanks

[artokin]

Hi Shahab,

NanoStack documentation can be found from https://docs.mbed.com/docs/arm-ipv66lowpan-stack/en/latest/12_API_network/index.html. Unfortunately return value -5 is not documented for arm_nwk_interface_up(...). -5 is returned if nanostack is not properly configured by using arm_nwk_interface_configure_6lowpan_bootstrap_set(...).

Your API call sequence sounds right, scheduler is running and you get events to mbed-mesh-api.

BR, Arto

[kjbracey]

-5 covers a range of "not fully configured" errors. Do you get any terminal trace?

The basic initialisation sequence is covered here: https://github.com/ARMmbed/sal-stack-nanostack/blob/master/docs/07_API_initialize.md

Maybe check the return codes on earlier configuration calls in nd_tasklet_configure_and_connect_to_network? Perhaps some invalid parameter was passed into one of them.

[shahab5]

Thanks for the answers.

Upon reading the latest docs on sal-stack-nanostack, I realized that the stack version in use was old (but compatible with the mbed-client application).

Updated to the latest mbed-client-6lowpan-example and stack. This issue is no longer seen upon porting to my platform.

I have reached Start 6LoWPAN ND Bootstrap message. However, the MCU waits forever in eventOS_scheduler_wait() for interrupts in the ported code.

Kindly, shed some light on the next sequence of steps.

Thanks, Shahab

[kjbracey]

When performing the 6LoWPAN-ND bootstrap, the first thing that should happen is a channel scan - beacon requests being sent on 1 or more channels. The stack should be making calls to the driver to transmit those packets, and you should be calling the stack from interrupt when you receive packets.

If no beacons are received, the boot should time out and the tasklet should retry.

eventOS_scheduler_wait() should never wait forever, as there should be a fair few periodic events happening. There's a regular 100ms timer event.

Have interrupts been mistakenly disabled (PRIMASK)? Imbalance in platform_enter_critical?

[shahab5]

@kjbracey-arm Thanks for the solution, indeed interrupts were disabled. Fixed it.

Now the stack has initiated scan, the beacon request seems to have few things messed up.

1.Ack.req is set

2. Dest. PAN and Dest. Address are 0x00 instead of 0xFF.

FYI, I have used sal-stack-nanostack/armcc/lowpan_host libraries.

Attached is a comparison of the packets sent by FRDM board (mbed-client-6lowpan-example) vs my device.

Kindly, correct me if I made any mistake(s).

Thanks, Shahab

[kjbracey]

Is Nanostack actually passing you incorrect packets?

It should be giving you the MAC header and payload. Did Nanostack really ask you to transmit "23 08 D9 00 00 00 00 07"?

Are you running the same mbed-client-6lowpan-example application and nanostack on both systems? You need to rule out factors other than the radio driver.

[shahab5]

@kjbracey-arm Indeed Nanostack has provided "23 08 D9 00 00 00 00 07" to the API rf_start_cca with a length of 8 bytes.

Yes, I am running the same application on both the systems.

[shahab5]

I was using an archive file (.a file created using all .o's in stack) created using arm-none-eabi-ar earlier.

Instead using ar command directly to archive the dot Os did the job. The nanostack is now sending correct sequence of data to be transmitted "03 08 D9 FF FF FF FF 07".

Thanks for all the help. Closing this issue.

Regards, Shahab