Skip to content

Add nanostack support for KW41Z #6622

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Jan 14, 2019
Merged

Conversation

mmahadevan108
Copy link
Contributor

@mmahadevan108 mmahadevan108 commented Apr 12, 2018

Signed-off-by: Mahesh Mahadevan [email protected]

Description

Add Thread support for FRDM KW41Z board. This was tested using the mesh-minimal application.

Pull request type

[ ] Fix
[ ] Refactor
[ ] New target
[X] Feature
[ ] Breaking change

@mmahadevan108
Copy link
Contributor Author

cc @maclobdell @karsev @0xc0170

@SeppoTakalo
Copy link
Contributor

@mikter @artokin Do you have time to review this?

Also, do we have this board in Oulu for testing?

@0xc0170 0xc0170 requested review from mikter and artokin April 13, 2018 10:42
@mmahadevan108
Copy link
Contributor Author

This PR requires the below fix to be inside mbed-os:
https://github.com/ARMmbed/sal-stack-nanostack-private/pull/1585

#define MAC_PACKET_SIZE 127 //MAX MAC payload is 127 bytes
static uint8_t PHYPAYLOAD[MAC_PACKET_SIZE];

//TODO: verify these values
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does this mean "verify these values"

}
}

static void rf_mac_set_pending(uint8_t status) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

{ new line

#ifndef NANOSTACK_PHY_KW41Z_H_
#define NANOSTACK_PHY_KW41Z_H_

#include "mbed.h"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Include what is required here, not mbed.h

@mmahadevan108
Copy link
Contributor Author

@0xc0170 . Thanks for your review. I have updated per your comments. The TODO comment statement in the code was a copy-paste from another driver.

@cmonr
Copy link
Contributor

cmonr commented Apr 17, 2018

@mmahadevan108 That private PR indicates that the patch isn't in mbed-os yet. Is this still the case, and should we expect a seperate PR for that patch, or has it already made it into mbed-os?

@@ -573,7 +573,7 @@
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M0+",
"supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
"extra_labels": ["Freescale", "MCUXpresso_MCUS", "KSDK2_MCUS", "FRDM"],
"extra_labels": ["Freescale", "MCUXpresso_MCUS", "KSDK2_MCUS", "FRDM", "FRAMEWORK_5_3_3"],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I take it this is the first device to use this label?
Is this label meant to be some sort of placeholder? I think we coud probably name it something a bit more descriptive.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also agree. If you cannot find anything related to this by searching Google with FRAMEWORK_5_3_3 then the label is not descriptive enough.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is related to MCUXpresso SDK radio driver version.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to have multiple ones in the tree?

Or can it be combined with other flags?

Or can it be made more verbatim like "MCUXPRESSO_FRAMEWORK_5_3_3"

@SeppoTakalo
Copy link
Contributor

@mikter is that referenced Nanostack change already published in Mbed OS?
ARMmbed/sal-stack-nanostack-private#1585

@SeppoTakalo
Copy link
Contributor

Note:
We are trying to find capacity to test this internally against other driver implementations in our RF lab.

@JuhPuur
Copy link
Contributor

JuhPuur commented Apr 17, 2018

We tested the driver with commit 01bb1f94d1f7ed8a67f64bc4f50f723eaafd2335

Energy detection scan has failed to scan channels, with zero energy on most channels. There is no network traffic seen on channels.

Indirect data transmission has failed with error message "Wrongly dropped".
nanostack/source/MAC/IEEE802_15_4/mac_indirect_data.c

We will retest with the updated commit soon.

@artokin
Copy link
Contributor

artokin commented Apr 17, 2018

The PR ARMmbed/sal-stack-nanostack-private#1585 is not yet merged to Mbed OS. It will be merged to mbed-os-5.9 release.

@mmahadevan108
Copy link
Contributor Author

@JuhPuur Are you testing against mbed-os repo. This will not work without the fix from
ARMmbed/sal-stack-nanostack-private#1585

@JuhPuur
Copy link
Contributor

JuhPuur commented Apr 18, 2018

Re-tested with the fix included. Same issues.

@mmahadevan108
Copy link
Contributor Author

I would like to run this test to debug, where do I get it.

@JuhPuur
Copy link
Contributor

JuhPuur commented Apr 18, 2018

The tests are unfortunately not yet released to partners.
Have not yet verified, but it is possible that indirect transmission fails as the driver is setting pending bit wrong.

@0xc0170
Copy link
Contributor

0xc0170 commented Jan 8, 2019

We will start CI but noticed first Travis failures - we include workaround in travis config . Can you rebase to get it in, travis should be green

@mmahadevan108
Copy link
Contributor Author

We will start CI but noticed first Travis failures - we include workaround in travis config . Can you rebase to get it in, travis should be green

Rebased and also removed include of mbed.h

@0xc0170
Copy link
Contributor

0xc0170 commented Jan 9, 2019

We fixed Travis failures on master hours ago, and this change should be propagated here via rebase. We will start CI right after travis fix.

I can rebase this later today if not yet done. Sorry for the trouble

@mmahadevan108
Copy link
Contributor Author

@0xc0170 I have rebased this PR

@0xc0170
Copy link
Contributor

0xc0170 commented Jan 9, 2019

CI started

@mbed-ci
Copy link

mbed-ci commented Jan 9, 2019

Test run: FAILED

Summary: 1 of 11 test jobs failed
Build number : 1
Build artifacts

Failed test jobs:

  • jenkins-ci/mbed-os-ci_greentea-test

@cmonr cmonr removed the needs: CI label Jan 10, 2019
@mmahadevan108
Copy link
Contributor Author

Test run: FAILED

Summary: 1 of 11 test jobs failed
Build number : 1
Build artifacts

Failed test jobs:

  • jenkins-ci/mbed-os-ci_greentea-test

I am not clear how to address the network test failures seen.

@SeppoTakalo
Copy link
Contributor

@mmahadevan108 By default the Greentea tries to run network tests for all boards that provide default network interface, as this does by default.

However, our test environment does not (yet) have properly working Mesh network available. Therefore you need to tell Greentea run that by default, use NO_NETWORK test configuration.

See example here for KW24D platform: https://github.com/ARMmbed/mbed-os/blob/master/tools/test_configs/target_configs.json#L54..L57

This NO_NETWORK disables the default network interface for Greentea builds, until mbed_app.json is provided. This leads to build of DNS and network interface tests being skipped.

Once you copy&paste the KW24D section for your board, the test run should pass.

Signed-off-by: Mahesh Mahadevan <[email protected]>
@mmahadevan108
Copy link
Contributor Author

Thank you. I have updated this PR with the change suggested.

@mmahadevan108
Copy link
Contributor Author

@0xc0170 Anything needed for this PR from my end?

@0xc0170
Copy link
Contributor

0xc0170 commented Jan 11, 2019

CI started

@mbed-ci
Copy link

mbed-ci commented Jan 11, 2019

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 2
Build artifacts

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.