add support for SILICA_SENSOR_NODE platform #5104

architech-boards · 2017-09-14T15:08:43Z

Tests done with 3 toolchains on Windows:

uVision V5.24.2.0: test_iar.txt
DS5 ARM Compiler 5.06u4: test_arm.txt
GNU Tools for ARM Embedded Processors 6-2017-q2-update) 6.3.1 20170620: test_gcc_arm.txt

theotherjimmy · 2017-09-14T15:11:46Z

@architech-boards It looks like you based this on a release. We can only accept pull requests (PRs) based on master. Please rebase your PR onto master.

theotherjimmy · 2017-09-14T15:12:48Z

@architech-boards While your link is correct, "uVision 5.24.2.0" is not the IDE or version of IAR.

architech-boards · 2017-09-14T16:18:20Z

You are right, IAR is 7.80.2.11975.
I'm going to rebase it

architech-boards · 2017-09-15T07:12:41Z

@theotherjimmy I rebased my commits, I'm not sure if it is ok now, commands used:
git remote add upstream git://github.com/ARMmbed/mbed-os.git
git fetch upstream
git rebase upstream/master
git push -f origin master

theotherjimmy · 2017-09-15T14:27:40Z

@architech-boards It looks like yo did a rebase correctly. I still see Anna's "Added versioning define block for new minor release." commit, which is what originally indicated to me that you based this branch on a release (she only adds that commit, and others like it, to the release branches).

architech-boards · 2017-09-15T14:56:09Z

Yes exactly, I don't know how to remove Annas's commit. I tried but unsuccessfully. Thanks.

theotherjimmy · 2017-09-15T15:04:39Z

You could do an interactive rebase (git rebase -i origin/master) and just delete the line related to that commit.

0xc0170 · 2017-09-20T12:54:40Z

features/nanostack/FEATURE_NANOSTACK/mbed-mesh-api/source/mesh_system.c

@@ -31,7 +31,7 @@

 /* Heap for NanoStack */
 #if !MBED_CONF_MBED_MESH_API_USE_MALLOC_FOR_HEAP
-static uint8_t app_stack_heap[MBED_CONF_MBED_MESH_API_HEAP_SIZE + 1];
+static uint8_t app_stack_heap[MBED_CONF_MBED_MESH_API_HEAP_SIZE + 1] __attribute__(( section( "mesh_heap") ));


What is this change? I believe this section is not defined for all targets. Or is this valid?

L476JG memory is splitted in 2 banks with not consecutive addresses. In the original project only 96kb SRAM1 is used but this memory is not enought for the project. We moved this array to the 32kb SRAM2 bank which the original project don't use. See the STM32L476XX.ld file modified.

This is target specific then, should not be in this code, you should be able to place object files in the sections (might be better place in the linker to do this than in this generic file).

@SeppoTakalo please review this

I changed the STM32L476XX.ld file with:

.mesh_heap (COPY): { *mesh_system.o } > SRAM2

and removed attribute(( section( "mesh_heap") ));
The bin file is built without errors and the .map files seems good: mbed-os-sensor-node.map.txt

but when I compile this mbed-os version for the mbed-os-example-client the demo doesn't run:

Starting mbed Client example
[EasyConnect] IPv6 mode
[EasyConnect] Using Mesh
[EasyConnect] Connecting to Mesh..
[EasyConnect] MAC address
[EasyConnect] Connection to Network Failed -3012!
Connection to Network Failed - exiting application...

Please can you help me?

cc @JanneKiiskila

@SeppoTakalo might be able to help out a bit more, but well - more logs would definitely be needed. Easy-connect itself does nothing there, it's just abstracting the network stack differences into one function we call from the app side.

@SeppoTakalo - we have one of those boards available here in Oulu.

Please note that there is some funny thing on-going with the MAC address. In all normal scenarios the MAC address printing should work - however, in case - there is no MAC? Is the radio driver working?

Please note that there is some funny thing on-going with the MAC address.
Yes it's true. In the mbed_app.json I have: "spirit1.mac-address": "{0x23, 0x23, 0x23, 0x23, 0x23, 0x23, 0x23, 0x23}"

This with trace enabled:

Starting mbed Client example
[EasyConnect] IPv6 mode
[EasyConnect] Using Mesh
[EasyConnect] Connecting to Mesh..
[DBG ][SPIRIT]: rf_register (728)
[DBG ][SPIRIT]: rf_ack_loop (608)
[DBG ][SPIRIT]: rf_register (775)
[EasyConnect] MAC address
[EasyConnect] Connection to Network Failed -3012!

Connection to Network Failed - exiting application...

If I comment this (just for test):
/*.mesh_heap (COPY):
{
mesh_system.o
} > SRAM2/
from the .ld file, the radio works:

Starting mbed Client example
[EasyConnect] IPv6 mode
[EasyConnect] Using Mesh
[EasyConnect] Connecting to Mesh..
[DBG ][core]: Allocate Root Tasklet
[DBG ][6lo ]: P.Init

[DBG ][core]: NS Root task Init
[DBG ][sck ]: Socket Tasklet Generated
[DBG ][SPIRIT]: rf_register (728)
[DBG ][SPIRIT]: rf_ack_loop (608)
[DBG ][SPIRIT]: rf_interface_state_control (466)
[DBG ][SPIRIT]: rf_register (775)
[DBG ][SPIRIT]: get_mac_address (797)
[DBG ][SPIRIT]: rf_get_mac_address (559), adr0=23, adr1=23, adr2=23, adr3=23, adr4=23, adr5=23, adr6=23, adr7=23
[DBG ][SPIRIT]: rf_set_mac_address (547), adr0=23, adr1=23, adr2=23, adr3=23, adr4=23, adr5=23, adr6=23, adr7=23
[DBG ][SPIRIT]: rf_set_mac_address (547), adr0=23, adr1=23, adr2=23, adr3=23, adr4=23, adr5=23, adr6=23, adr7=23
[DBG ][nslp]: connect()
[DBG ][mle ]: MLE service init size 32
[DBG ][sck ]: Socket id 0 allocated
[DBG ][m6LND]: Using PSK security mode.
[DBG ][m6LND]: Channel: 1
[DBG ][m6LND]: Channel page: 2
[DBG ][m6LND]: Channel mask: 2
[DBG ][mMIB]: Set key 1
[INFO][addr]: Address added to IF 1: fe80::2123:2323:2323:2323

But without my original modification the client won't connect to the mbed connector due to memory overflow problems.

I believe we all agree this change should not be here, and we need to identify the root cause of this problem.

@JanneKiiskila you noted that you have these boards in Oulu, or @MarceloSalazar in Cambridge to reproduce the problems they are having?

0xc0170 · 2017-09-20T12:55:08Z

mbed.h

+#endif
+
+#define MBED_ENCODE_VERSION(major, minor, patch) ((major)*10000 + (minor)*100 + (patch))
+#define MBED_VERSION MBED_ENCODE_VERSION(MBED_MAJOR_VERSION, MBED_MINOR_VERSION, MBED_PATCH_VERSION)        #define MBED_H


As pinpointed earlier, please rebase interactively to remove this change

thank you, rebase done, removed the commit

0xc0170 · 2017-09-20T13:03:39Z

@architech-boards Let us know if you need any assistance with rebase

SeppoTakalo · 2017-09-22T09:44:28Z

This seems to add new platform, but what is the radio driver?
How can we study the problem if we don't know which radio it failed.
Also, if the work is to port a new radio driver, try starting with the https://github.com/ARMmbed/mbed-os-example-mesh-minimal application instead of Client. It is much easier to debug.

MarceloSalazar · 2017-09-23T10:46:32Z

@architech-boards could you please share links to your forked mesh-minimal and client application (pointing at this PR mbed OS branch) to help us investigate further?

architech-boards · 2017-09-25T10:43:45Z

This seems to add new platform, but what is the radio driver?
Why new radio driver? We are using stm-spirit1-rf-driver.git from mbed-os-example-client.
If you want see a working version compilable for our board you can download our repository:

hg clone https://[email protected]/users/AVNETSilica/code/mbed-os-sensor-node/

This is a porting from mbed-os-example-client. It uses the last mbed-os version.

could you please share links to your forked mesh-minimal and client application (pointing at this PR mbed OS branch) to help us investigate further?
We have only this repo: mbed-os-sensor-node and it is the porting from mbed-os-example-client.

SeppoTakalo · 2017-09-25T11:24:40Z

@architech-boards
Thanks for the info.
I'm having trouble understanding why do you fork the Client repository if your changes are going to land on the Mbed OS?

Also, what you linked, points to private clone of Easy-connect. However it links to main Spirit RF driver with quite new Git hash, so it seems OK.

Have you ever been able to successfully create mesh network with these nodes?
What border router are you using? is is running and connected to IPv6 network. Are you able to provide log file from its serial output.
Do you have any RF sniffer that is able to capture packets between these nodes and border router?
Can you use mesh-minimal example instead so we can first debug the mesh issue and then IPv6 connectivity issues?
From the mbed_app.json:
- Can you enable Nanostack's debug traces by turning on the "mbed-trace.enable": true option
- Use feature NANOSTACK_FULL in the "target.features_add" line instead of LOWPAN_ROUTER? to get all debug prints.

architech-boards · 2017-09-25T13:12:55Z

I'm having trouble understanding why do you fork the Client repository if your changes are going to land on the Mbed OS?
This repository is for our seminars. So customers can download it and try to run it on the board. In this repository there is also "extra source code" just for the hands-on (at mbed-os-sensor-node\mbed-os\targets\TARGET_STM\TARGET_STM32L4\TARGET_STM32L476xG\TARGET_SILICA_SENSOR_NODE\SDK).
Also, what you linked, points to private clone of Easy-connect.
Yes because we have to reset the spirit device before to call the constructor stm-spirit1-rf-driver. So I created a new class just to reset the spirit and then call the stm-spirit1-rf-driver constructor. This because I can't modify directly the stm-spirit1-rf-driver source code.
Have you ever been able to successfully create mesh network with these nodes?
Yes with 20 nodes connected contemporaneously, wtithout problems.
What border router are you using? is is running and connected to IPv6 network.
Yes, We are using the NUCLEO_F429ZI board with the SPIRIT module X-NUCLEO-IDS01A4. I modified the nanostack-border-router repository just to be able to connect the 20 nodes without any problem. You can find a guide here (with the firmware binary downloadable): http://sensor-node.readthedocs.io/en/latest/demo.html (ps. I have to correct the English)
Sure, Ipv6.
Are you able to provide log file from its serial output.
Yes, soon I'm going to send the file.
Do you have any RF sniffer that is able to capture packets between these nodes and border router?
yes
Can you use mesh-minimal example instead so we can first debug the mesh issue and then IPv6 connectivity issues?
I never used it. But we have not created a new radio driver. So why debug the mesh issue? The mesh works if I don't change the .ld file with the attribute: *mesh_system.o. I think this problem is about linker and memory map not the radio driver directly.
From the mbed_app.json:
ok if you want it.

Please, try to compile my repository, you will see that the mesh works. And the clients connects to the mbed connector. I think the problem is about .ld file.

architech-boards · 2017-09-28T17:12:33Z

Hello, I forked and changed 2 repositories as requested. These repos work with our board.

https://github.com/architech-boards/mbed-os-example-mesh-minimal
https://github.com/architech-boards/mbed-os-example-clien

nb. use my json file from the "configs" directory

JanneKiiskila · 2017-09-28T18:21:52Z

We'll get that new config added to the mbed-os-example-client repo easily. When can we have the required mbed-os changes in?

0xc0170 · 2017-10-02T13:38:11Z

I would like to move this target along. As we are having problem with client, do you think we should split this (simplify) patch? The nanostack change should not be here as noted previously. @architech-boards what do you think?

0xc0170 · 2017-10-06T08:53:26Z

I would like to move this target along. As we are having problem with client, do you think we should split this (simplify) patch? The nanostack change should not be here as noted previously. @architech-boards what do you think?

Any update? Please can yo uresolve conflict (rebase will also eliminate circle-ci failure plus possibly jenkins cI).

What is the status of client failures with linker script update to place mesh in the second RAM bank?

SeppoTakalo · 2017-10-06T10:01:21Z

Where are the linker files for IAR and ARM toolchains?

This adds support only for GCC.

0xc0170 · 2017-10-06T11:29:43Z

Where are the linker files for IAR and ARM toolchains?

It inherits from STM32L476JG thus getting the same support (all 3 toolchains), verified via targats.json file edit here and files for STM32L476xG.

This means that whatever change is needed for that mesh, needs to be done in all 3 linker files (better organization of 2 RAM banks) for connectivity

SeppoTakalo · 2017-10-06T11:38:39Z

Then why do they provide linker file for GCC instead of inheriting it also?

Getting target to work with Mbed OS is one goal, getting enough RAM to run it with mesh application is another goal.

These two should be handled in separate pull requests.

0xc0170 · 2017-10-06T12:08:05Z

Getting target to work with Mbed OS is one goal, getting enough RAM to run it with mesh application is another goal.

Agree, the same proposal I made above. @architech-boards Please see the latest comments, and tell us what you think.

Then why do they provide linker file for GCC instead of inheriting it also?

Not certain here. there could be then 2 linker script files here. @architech-boards Can you review the inheritance, and which linker scripts are provided, clarify please.

architech-boards · 2017-10-06T13:02:22Z

Getting target to work with Mbed OS is one goal, getting enough RAM to run it with mesh application is another goal.
Agree, the same proposal I made above. @architech-boards Please see the latest comments, and tell us what you think.

We have talked yesterday with @MarceloSalazar and we agree about remove our LD file and the attribute in the mesh_system.c. Our priority now is get the target to work with Mbed OS. So getting enought RAM to run it with mesh application is not important at this point.
Have I to create a new commit that removes these changes?

Then why do they provide linker file for GCC instead of inheriting it also?
Not certain here. there could be then 2 linker script files here. @architech-boards Can you review the inheritance, and which linker scripts are provided, clarify please.

@MarceloSalazar knows the details about the memory problem because yesterday we have talked with him about why there is this problem. I think he will talk to you internally.

0xc0170 · 2017-10-09T12:52:31Z

Have I to create a new commit that removes these changes?

First, rebase your branch on top of latest master (resolve the conflict that is here). look at ``git rebase master` once master is up to date (your local master = upstream/master).

You can then just create a new commit to revert that nanostack change, or use git revert for that specific commit that is adding that attribute (if it is in a separete commit).

architech-boards · 2017-10-11T14:43:50Z

I rebased it and I created a new commit to revert that nanostack change. For me it is ready to be reviewed and merged. Thank you!

mbed-ci · 2017-10-11T17:08:43Z

Build : SUCCESS

Build number : 128
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/5104/

Triggering tests

/test mbed-os

0xc0170 · 2017-10-13T13:46:16Z

Changes look good to me now. Waiting for CI to complete

studavekar · 2017-10-16T01:40:00Z

/morph build

mbed-ci · 2017-10-16T02:25:12Z

Build : SUCCESS

Build number : 179
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/5104/

Skipping test trigger, missing label 'NEED CI'

mbed-ci · 2017-10-16T18:41:28Z

Build : SUCCESS

Build number : 186
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/5104/

Triggering tests

/test mbed-os

mbed-ci · 2017-10-17T02:06:07Z

Test : FAILURE

Build number : 86
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/5104/86

0xc0170 · 2017-10-17T13:04:38Z

/morph test

mbed-ci · 2017-10-17T14:09:55Z

Test : FAILURE

Build number : 91
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/5104/91

0xc0170 · 2017-10-18T09:50:17Z

/morph build

mbed-ci · 2017-10-18T10:06:24Z

Build : SUCCESS

Build number : 221
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/5104/

Triggering tests

/morph test
/morph uvisor-test

0xc0170 · 2017-10-18T10:10:39Z

/morph uvisor-test

mbed-ci · 2017-10-18T12:47:05Z

Test : SUCCESS

Build number : 110
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/5104/110

theotherjimmy added the needs: work label Sep 14, 2017

0xc0170 requested changes Sep 20, 2017

View reviewed changes

theotherjimmy added the scope: new-target label Sep 22, 2017

Roberto Spelta added 4 commits October 10, 2017 13:58

added SILICA_SENSOR_NODE in target.json

b328654

copy of L476RG target

a95acda

peripherals pins adaptation

4d75cbe

copy of L476RG ld file

e466685

Roberto Spelta added 8 commits October 10, 2017 13:58

modification to .ld to improve memory

f63dfce

added TARGET_STM32L476JG define in mbed_rtx.h

c5e6689

modified mesh_system.c to improve memory

cf24dcf

added clock_source for tests

3fd009e

setted pin USBTX and USBRX

182d689

added IAR export for STM32L476JG

b969979

fixed pin LEDs

7af6e88

removed memory allocation

35736f5

0xc0170 approved these changes Oct 13, 2017

View reviewed changes

adbridge added needs: CI and removed needs: work labels Oct 16, 2017

0xc0170 added ready for merge release-version: 5.6.3 and removed needs: CI labels Oct 18, 2017

0xc0170 merged commit 2af7213 into ARMmbed:master Oct 19, 2017

0xc0170 removed the ready for merge label Oct 19, 2017

add support for SILICA_SENSOR_NODE platform #5104

add support for SILICA_SENSOR_NODE platform #5104

Uh oh!

Conversation

architech-boards commented Sep 14, 2017

Uh oh!

theotherjimmy commented Sep 14, 2017

Uh oh!

theotherjimmy commented Sep 14, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

architech-boards commented Sep 14, 2017

Uh oh!

architech-boards commented Sep 15, 2017

Uh oh!

theotherjimmy commented Sep 15, 2017

Uh oh!

architech-boards commented Sep 15, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

theotherjimmy commented Sep 15, 2017

Uh oh!

0xc0170 Sep 20, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

architech-boards Sep 25, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

0xc0170 commented Sep 20, 2017

Uh oh!

SeppoTakalo commented Sep 22, 2017

Uh oh!

MarceloSalazar commented Sep 23, 2017

Uh oh!

architech-boards commented Sep 25, 2017

Uh oh!

SeppoTakalo commented Sep 25, 2017

Uh oh!

architech-boards commented Sep 25, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

architech-boards commented Sep 28, 2017

Uh oh!

JanneKiiskila commented Sep 28, 2017

Uh oh!

0xc0170 commented Oct 2, 2017

Uh oh!

0xc0170 commented Oct 6, 2017

Uh oh!

SeppoTakalo commented Oct 6, 2017

Uh oh!

0xc0170 commented Oct 6, 2017

Uh oh!

SeppoTakalo commented Oct 6, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

0xc0170 commented Oct 6, 2017

Uh oh!

architech-boards commented Oct 6, 2017

Uh oh!

theotherjimmy commented Sep 14, 2017 •

edited

Loading

architech-boards commented Sep 15, 2017 •

edited

Loading

0xc0170 Sep 20, 2017 •

edited

Loading

architech-boards Sep 25, 2017 •

edited

Loading

architech-boards commented Sep 25, 2017 •

edited

Loading

SeppoTakalo commented Oct 6, 2017 •

edited

Loading