[efr32] update to RAIL 2.x by jwhui · Pull Request #2401 · openthread/openthread

jwhui · 2017-12-06T17:10:50Z

This update also makes the following changes:

Initialize chip using halInitChipSpecific() provided by RAIL HAL.
Use RAIL_HoldRxPacket() to move rx processing out of interrupt context
Eliminate critical sections from otPlatRadio* APIs.
Use UART driver provided by Gecko SDK.

Resolves #2372
Resolves #2379

//cc @tomas-c @plasticchris @xiaom-GitHub

jwhui · 2017-12-06T20:53:48Z

@tomas-c, this seems to be working pretty well for me in my limited testing. Would you like to test it out?

tomas-c · 2017-12-07T15:35:53Z

@jwhui Ahh nice, had been thinking of doing the switch to Rail 2 and the UART driver too. Will test.

xiaom-GitHub · 2017-12-07T15:49:21Z

examples/platforms/efr32/rail_config.h

Thanks for updating to RAIL 2.0 👍 . Please remove duplicated RADIO_CONFIG_XTAL_FREQUENCY and other parameters from openthread-core-efr32-config.h if we put auto-generated header file here.

Thanks! Updated.

al1img · 2017-12-11T22:15:27Z

examples/platforms/efr32/uart.c

Is this line really needed? Other platforms send nothing on otPlatUartEnable.

This was left over from my own testing. Removed!

al1img · 2017-12-11T22:54:14Z

examples/platforms/efr32/uart.c

Why not use non blocking UARTDRV_Transmit? As I see OT is not designed to be blocked in process drivers call. I think sending big buffer may introduce RF packet drops etc. I notice some issue with EFR32 in case intensive data exchange and sending logs via uart. It looks like the root cause was delay in processTransmit but I didn't investigate it so much.

I'll switch this to non-blocking soon.

Updated to use non-blocking UARTDRV_Transmit.

al1img · 2017-12-11T22:55:51Z

examples/platforms/efr32/radio.c

Shall OT_RADIO_CAPS_TRANSMIT_RETRIES be added as well?

Does RAIL implement automatic retransmissions on no ack?

I didn't find any info about retransmissions. So, most probably doesn't implement.

tomas-c · 2017-12-15T16:51:16Z

Tested CLI app (used the latest update with async UART). All basic tests mentioned in the porting guide pass. Will soon check with wpantund and a bigger network of devices.

tomas-c · 2017-12-21T11:33:40Z

This pull request seems to fix issue #2372.

Not sure if this was an issue with old RAIL implementation (couldn't test due to #2372) but I have noticed the network is much less stable than with SiLabs Thread v2.3.1.0 stack.

Had four devices continuously sending messages to each other. With SiLabs stack I didn't have single missed message over 12 hour period.

With OpenThread I had hundreds of missed messages over the same period with the same setup (same CCA threshold, same transmit power, same channel).

jwhui · 2017-12-21T18:29:23Z

@tomas-c, thanks for testing and providing feedback! I found a bug in handling RAIL's received packet FIFO. In particular, packets that were in process of being received could be discarded by the example driver. I have updated the example driver to avoid this. When you get a chance, try out the latest and let me know if you see improvement.

tomas-c · 2017-12-22T15:20:54Z

@jwhui Good catch! Been running for three hours already and no lost messages so far.

jwhui · 2017-12-22T16:36:27Z

@tomas-c, great to hear!

tomas-c · 2017-12-28T21:30:17Z

examples/platforms/efr32/uart.c

Spinel docs say flow control must be used. I had framing errors at higher baud rates if it's not enabled.

Tested and works if:

Change uartdrvFlowControlNone to uartdrvFlowControlHwUart

Change 0,0 at the end of this struct to RETARGET_CTS_LOCATION, RETARGET_RTS_LOCATION

@tomas-c, thanks! I updated this PR with your proposed changes.

tomas-c · 2017-12-29T18:55:14Z

examples/platforms/efr32/uart.c

Given UARTDRV_Transmit is asynchronous and aBuf can be reclaimed after otPlatUartSend returns, we should copy aBuf contents, not just its pointer.

Ah, just saw that layer above makes sure the buffer is not touched until this is done. Disregard.

This update also makes the following changes: - Initialize chip using `halInitChipSpecific()` provided by RAIL HAL. - Use `RAIL_HoldRxPacket()` to move rx processing out of interrupt context - Eliminate critical sections from `otPlatRadio*` APIs. - Use UART driver provided by Gecko SDK.

tomas-c · 2018-01-08T12:54:37Z

I got the system to run for 36h without any issues, with

latest code from this PR
115200 baud rate
hardware flow control
all NCP logging disabled
OPENTHREAD_CONFIG_NCP_TX_BUFFER_SIZE increased to 4096
OPENTHREAD_CONFIG_NCP_UART_TX_CHUNK_SIZE increased to 512
uart.c modified to use a 256 byte ring buffer being serviced by two UARTDRV_Receive() calls in 32 byte chunks

It's difficult to tell at this point which of these were necessary (will not have time to investigate for a while) but might be that the latest changes from this PR and default settings are enough to get a stable network with EFR32.

jwhui · 2018-01-08T17:31:33Z

@tomas-c, thanks for the feedback again! Do you think this PR is good for merge? If we find more issues, we can address them in subsequent PRs.

tomas-c · 2018-01-08T18:43:03Z

This seems to work better than the current Rail 1.x based version and I can't think of any improvements besides maybe increasing UART RX DMA buffer size to something bigger than 1 byte but it's tricky and should probably come as a separate PR.

I'd say let's merge this!

erbp · 2018-01-08T19:39:11Z

@tomas-c I'm new to openThread, but have built this version for my efr32 dev boards and was wondering how you were testing the stability? You mentioned test sending messages between nodes, was this UDP messages? Do you have a test app that is not included in this repository to do this? I wanted to test sending messages between my dev boards over the thread network, but wasn't sure how to go about this easily.

Thanks.

tomas-c · 2018-01-09T09:59:49Z

@erbp If you just want to test whether sending messages works - you can probably just follow the platform readme file and use the ping command. You can also follow the CLI app example or a more involved CLI app + NCP example.

I myself use a bunch of Linux devices running wpantund with NCPs connected to them. I have an existing setup with SiLabs Thread stack so just switched it out with OpenThread to test. Can't really share it but on Linux with wpantund you can write a simple Python script to send UDP packets or even use CoAP.

As for how to send UDP messages directly from the devices without wpantund - someone else might be more equiped to point you in the right direction.

jwhui · 2018-01-09T17:46:55Z

@tomas-c, thanks for your help on this PR!

jwhui added enhancement P4 platform: efr32 work-in-progress labels Dec 6, 2017

jwhui force-pushed the efr32 branch 4 times, most recently from fea1575 to 5447cb8 Compare December 6, 2017 20:01

jwhui removed the work-in-progress label Dec 6, 2017

jwhui force-pushed the efr32 branch 4 times, most recently from f7ec1ca to 1de1790 Compare December 6, 2017 20:45

jwhui added the work-in-progress label Dec 6, 2017

jwhui force-pushed the efr32 branch 2 times, most recently from 580cc37 to b9eb44d Compare December 6, 2017 21:09

This was referenced Dec 6, 2017

efr32 CSMA done twice? #2379

Closed

STATUS_NOMEM on SiLabs EFR32 #2372

Closed

jwhui force-pushed the efr32 branch 2 times, most recently from 335ac38 to 31a51cd Compare December 6, 2017 23:35

xiaom-GitHub reviewed Dec 7, 2017

View reviewed changes

jwhui force-pushed the efr32 branch from 31a51cd to 874660d Compare December 7, 2017 17:40

al1img reviewed Dec 11, 2017

View reviewed changes

jwhui force-pushed the efr32 branch 2 times, most recently from 9c87993 to 782bb8a Compare December 15, 2017 01:59

jwhui force-pushed the efr32 branch from 782bb8a to 0ae907c Compare December 20, 2017 17:09

jwhui force-pushed the efr32 branch from 0ae907c to 783cf68 Compare December 21, 2017 18:26

jwhui force-pushed the efr32 branch 2 times, most recently from 2faceca to 9ecaacb Compare December 21, 2017 19:23

tomas-c reviewed Dec 28, 2017

View reviewed changes

tomas-c reviewed Dec 29, 2017

View reviewed changes

jwhui force-pushed the efr32 branch from 9ecaacb to d9f3f09 Compare January 3, 2018 17:50

jwhui removed the work-in-progress label Jan 8, 2018

tomas-c approved these changes Jan 9, 2018

View reviewed changes

jwhui merged commit e668f0c into openthread:master Jan 9, 2018

jwhui deleted the efr32 branch January 9, 2018 17:47

al1img mentioned this pull request Jan 22, 2018

Enable HW Flow control for NCP by default #2498

Closed

dismirlian mentioned this pull request Mar 20, 2019

Questions about the EFR32 radio driver #3642

Closed

romacdon mentioned this pull request Sep 8, 2020

EFR32MG12 UART Initialisation overrides hal-config baud-rate value with a constant #5502

Closed

Conversation

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

Uh oh!

Uh oh!

jwhui commented Dec 6, 2017

Uh oh!

tomas-c commented Dec 7, 2017

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!

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!

tomas-c commented Dec 15, 2017

Uh oh!

tomas-c commented Dec 21, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jwhui commented Dec 21, 2017

Uh oh!

tomas-c commented Dec 22, 2017

Uh oh!

jwhui commented Dec 22, 2017

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!

tomas-c commented Jan 8, 2018

Uh oh!

jwhui commented Jan 8, 2018

Uh oh!

tomas-c commented Jan 8, 2018

Uh oh!

erbp commented Jan 8, 2018

Uh oh!

tomas-c commented Jan 9, 2018

Uh oh!

jwhui commented Jan 9, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

jwhui commented Dec 6, 2017 •

edited

Loading

tomas-c commented Dec 21, 2017 •

edited

Loading