[Silicon Labs] Adding support for EFR32MG1 wireless SoC #3157

stevew817 · 2016-10-28T06:38:57Z

Description

This pull request is adding support for the EFR32MG1 family of wireless SoCs. Functionality-wise, this port should be complete. We have also created a driver for using the radio wih Nanostack.

Status

READY

Migrations

NO

Deploy notes

This PR touches the mbed-added platform header for mbed TLS, in order to provide support for hardware acceleration. The configuration for that is the same as for enabling TRNG, i.e. through a "device_has" entry.

Steps to test or reproduce

Compile for THUNDERBOARD_SENSE

Adding target definitions and the HAL implementation for EFR32 Mighty Gecko

Initial check-in of hardware acceleration support on EFR32 for mbed TLS (AES, SHA and ECC).

First check-in of the EFR32 radio driver for Nanostack

0xc0170 · 2016-10-28T08:08:09Z

@stevew817 Can you share the tests results please?

stevew817 · 2016-10-28T18:12:35Z

@0xc0170 I'll get you the test results after the weekend.

stevew817 · 2016-11-07T10:52:29Z

Test results pasted under. I opened #3215 to cover the two failing tests, since IMO the two sub-test fails are due to a testing methodology issue.

RESULTS2.txt

Silicon Labs targets use a default, unchangeable baud rate of 115200 on the stdio serial-USB bridge.

stevew817 · 2016-11-07T11:47:49Z

@0xc0170 @bridadan Please review.

0xc0170 · 2016-11-07T13:23:43Z

@sbutcher-arm @yanesca : please review, regarding mbedtls - commit c0301b1

bridadan

Because of the size of the diff I can't comment on the specific line, but in targets.json, you've added the target EFR32MG1P132f256GM48, which contains a lowercase f in it. All target names should use capital letters, could you make this change please?

Also, I see that you've added the extra label 256K to the target however I can't see from the diff where it's used (GitHub hiding half the diff isn't helping here). Can you explain this a bit?

And lastly, I see that you've added the Greentea change here to respect the stdout baud rate. This is a good change, however do you think you could submit it as a separate PR so it can have a bit more visibility since it affects the testing of all platforms?

bridadan · 2016-11-07T16:20:48Z

Also, do you have test results for IAR and ARM compilers as well?

stevew817 · 2016-11-08T09:58:53Z

@bridadan Sure.

I fixed the stray lowercase. Good catch!
The extra 256K label is to switch between different linker scripts depending on the flash size (as we're doing for EFM32). Currently, the EFR32 series only has 256K parts, but this is not going to remain the case in the future.
It shouldn't affect any other platforms, since MBED_CONF_PLATFORM_STDIO_BAUD_RATE is defined to 9600 for all platforms except EFM32/EFR32?
I'll run through ARM and IAR tonight

stevew817 · 2016-11-08T13:34:27Z

@bridadan Here are the test results. Same deepsleep timer/ticker tests are failing (see my previous comment about those), but there's a few rtos fails on IAR. Do you know more about those? It seems strange to me that these would only fail on IAR.

RESULTS-IAR.txt
RESULTS-ARM.txt

stevew817 · 2016-11-08T13:53:38Z

Update on IAR: the tests-mbedmicro-rtos-mbed-basic test is passing on multiple subsequent runs. I think the fail exhibited on the documented run is due to something else that was running on my machine, messing with the input timing (since the failure was due to a drift check).

stevew817 · 2016-11-08T14:19:49Z

Update 2: All tests are passing on IAR too, after reducing the stack size on the failing tests. I keep wondering, why doesn't mbed set the stack size inside of the tests to something more bite-sized instead of DEFAULT_STACK_SIZE?

bridadan · 2016-11-08T16:45:25Z

Thanks for the changes! The targets.json fix looks good!

The extra 256K label is to switch between different linker scripts depending on the flash size (as we're doing for EFM32). Currently, the EFR32 series only has 256K parts, but this is not going to remain the case in the future.

OK good to know!

It shouldn't affect any other platforms, since MBED_CONF_PLATFORM_STDIO_BAUD_RATE is defined to 9600 for all platforms except EFM32/EFR32?

It shouldn't, yes. I also suggested putting it in a separate PR so if we needed to revert it it'd be easy to revert just that change and not this whole PR. It's just a preference of mine, but it doesn't need to block this PR.

Update on IAR: the tests-mbedmicro-rtos-mbed-basic test is passing on multiple subsequent runs. I think the fail exhibited on the documented run is due to something else that was running on my machine, messing with the input timing (since the failure was due to a drift check).

Yes, unfortunately the timing tests are susceptible to failures if the host machine is under load. If it passed on subsequent runs then that should be ok.

Update 2: All tests are passing on IAR too, after reducing the stack size on the failing tests

Can you update your PR with these changes?

I keep wondering, why doesn't mbed set the stack size inside of the tests to something more bite-sized instead of DEFAULT_STACK_SIZE?

Any thoughts @c1728p9 ?

Updated available RAM size and increased reserved heap to 4K

stevew817 · 2016-11-08T17:35:16Z

@bridadan Updated results after last changes:
RESULTS-ARM2.txt
RESULTS-IAR2.txt

stevew817 · 2016-11-09T08:20:14Z

@bridadan If you're happy with the current PR, can you remove your change request so that the PR can be merged?

bridadan

LGTM

bridadan · 2016-11-09T19:39:00Z

/morph test

stevew817 · 2016-11-09T22:05:32Z

Kinda. Thinking around TLS acceleration happening in a directory like feature/mbedtls/targets/TARGET_MCU_CRYPTO where a MCU can add that label and get support. This is how LwIP was done. Given these hal interfaces are from mbedtls we shouldn't use DEVICE_ until (or unless) there is a mbed c hal for symmetric crypto operations.

I feel I'm lacking some kind of context here to parse that statement...
@sg- IMO, it is cleaner in terms of PRs (you can directly see that no common code has been touched if all changes are in targets\) to have all partner-code inside the targets/ directory. That code can then be guarded by the relevant FEATURE_ folder if necessary for header inclusion (such as with nanostack drivers) instead of spreading out hardware implementations accross a bunch of different modules. Just my $.02, and the reason I submitted the PR as such.

mbed-bot · 2016-11-09T22:58:09Z

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 1035

All builds and test passed!

sg- · 2016-11-10T02:54:44Z

IMO, it is cleaner in terms of PRs (you can directly see that no common code has been touched if all changes are in targets\

Makes perfect sense.

That code can then be guarded by the relevant FEATURE_ folder if necessary for header inclusion

Currently there can only be a single FEATURE_X folder in any build.

Context is that mbed TLS team are looking at asymmetric acceleration. As implemented, there is already symmetric acceleration interfaces available. Either way, DEVICE_ should be reserved for mbed OS HAL implementations for the time being. It maybe best for mbed TLS specific config hooks. All under consideration.

sg- · 2016-11-14T15:53:22Z

@stevew817 to move this forward, can we remove the TLS acceleration for now. @sbutcher-arm will provide more guidance on how to fit acceleration in when ready.

0xc0170 · 2016-11-16T17:07:13Z

@stevew817 bump

mbed compile doesn't support two different FEATURE_X folders being merged, so we'll have to move our nanostack driver into the Nanostack folder for the time being.

…family" This reverts commit a0f62b1.

This reverts commit c0301b1.

stevew817 · 2016-11-18T10:21:57Z

@0xc0170 @sg- Done.

stevew817 · 2016-11-22T21:17:37Z

@0xc0170 Poke.

stevew817 · 2016-11-26T13:24:44Z

@0xc0170 What is taking so long?

adbridge · 2016-11-28T10:14:48Z

/morph test

mbed-bot · 2016-11-28T11:39:05Z

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 1174

All builds and test passed!

stevew817 · 2016-12-01T08:52:07Z

Anything else needed for this PR?

0xc0170 · 2016-12-01T13:53:23Z

LGTM

Ports for Upcoming Targets 3241: Add support for FRDM-KW41 ARMmbed/mbed-os#3241 3291: Adding mbed enabled Maker board with NINA-B1 and EVA-M8Q ARMmbed/mbed-os#3291 Fixes and Changes 3062: TARGET_STM :USB device FS ARMmbed/mbed-os#3062 3213: STM32: Refactor us_ticker.c + hal_tick.c files ARMmbed/mbed-os#3213 3288: Dev spi asynch l0l1 ARMmbed/mbed-os#3288 3289: Bug fix of initial value of interrupt edge in "gpio_irq_init" function. ARMmbed/mbed-os#3289 3302: STM32F4 AnalogIn - Clear VBATE and TSVREFE bits before configuring ADC channels ARMmbed/mbed-os#3302 3320: STM32 - Add ADC_VREF label ARMmbed/mbed-os#3320 3321: no HSE available by default for NUCLEO_L432KC ARMmbed/mbed-os#3321 3352: ublox eva nina - fix line endings ARMmbed/mbed-os#3352 3322: DISCO_L053C8 doesn't support LSE ARMmbed/mbed-os#3322 3345: STM32 - Remove TIM_IT_UPDATE flag in HAL_Suspend/ResumeTick functions ARMmbed/mbed-os#3345 3309: [NUC472/M453] Fix CI failed tests ARMmbed/mbed-os#3309 3157: [Silicon Labs] Adding support for EFR32MG1 wireless SoC ARMmbed/mbed-os#3157 3301: I2C - correct return values for write functions (docs) - part 1 ARMmbed/mbed-os#3301 3303: Fix #2956 #2939 #2957 #2959 #2960: Add HAL_DeInit function in gpio_irq destructor ARMmbed/mbed-os#3303 3304: STM32L476: no HSE is present in NUCLEO and DISCO boards ARMmbed/mbed-os#3304 3318: Register map changes for RevG ARMmbed/mbed-os#3318 3317: NUCLEO_F429ZI has integrated LSE ARMmbed/mbed-os#3317 3312: K64F: SPI Asynch API implementation ARMmbed/mbed-os#3312 3324: Dev i2c common code ARMmbed/mbed-os#3324 3369: Add CAN2 missing pins for connector CN12 ARMmbed/mbed-os#3369 3377: STM32 NUCLEO-L152RE Update system core clock to 32MHz ARMmbed/mbed-os#3377 3378: K66F: Enable LWIP feature ARMmbed/mbed-os#3378 3382: [MAX32620] Fixing serial readable function. ARMmbed/mbed-os#3382 3399: NUCLEO_F103RB - Add SERIAL_FC feature ARMmbed/mbed-os#3399 3409: STM32L1 : map ST HAL assert into MBED assert ARMmbed/mbed-os#3409 3416: Renames i2c_api.c for STM32F1 targets to fix IAR exporter ARMmbed/mbed-os#3416 3348: Fix frequency function of CAN driver. ARMmbed/mbed-os#3348 3366: NUCLEO_F412ZG - Add new platform ARMmbed/mbed-os#3366 3379: STM32F0 : map ST HAL assert into MBED assert ARMmbed/mbed-os#3379 3393: ISR register never re-evaluated in HAL_DMA_PollForTransfer for STM32F4 ARMmbed/mbed-os#3393 3408: STM32F7 : map ST HAL assert into MBED assert ARMmbed/mbed-os#3408 3411: STM32L0 : map ST HAL assert into MBED assert ARMmbed/mbed-os#3411 3424: STM32F4 - FIX to add the update of hdma->State variable ARMmbed/mbed-os#3424 3427: Fix stm i2c slave ARMmbed/mbed-os#3427 3429: Fix stm i2c fix init ARMmbed/mbed-os#3429 3434: [NUC472/M453] Fix stuck in lp_ticker_init and other updates ARMmbed/mbed-os#3434

stevew817 added 5 commits October 27, 2016 23:21

[EFM32] Move board controller pin setting to config system

5a88513

[EFM32] Move board controller pin setting to config system

214d1be

[EFR32] Add initial support for EFR32

035c08d

Adding target definitions and the HAL implementation for EFR32 Mighty Gecko

[EFR32] Adding hardware acceleration for mbed TLS

c0301b1

Initial check-in of hardware acceleration support on EFR32 for mbed TLS (AES, SHA and ECC).

[EFR32] Initial radio driver

01446f3

First check-in of the EFR32 radio driver for Nanostack

0xc0170 added the needs: review label Oct 28, 2016

[EFR32] Move the mbedTLS hardware acceleration code to EFR32 family

a0f62b1

stevew817 added 2 commits November 7, 2016 11:54

[EFR32] Set default USB serial baudrate

f344c0d

Silicon Labs targets use a default, unchangeable baud rate of 115200 on the stdio serial-USB bridge.

Make GreenTea respect STDIO baud rate

3cfdf8f

bridadan suggested changes Nov 7, 2016

View reviewed changes

[EFR32] fix typo in targets.json

0f20cd1

[EFR32] Prevent compiling Nanostack driver without Nanostack

0f1101e

stevew817 added 3 commits November 8, 2016 18:32

[EFR32] Fix linker script for ARMCC

dc71c66

Updated available RAM size and increased reserved heap to 4K

[EFR32] Make RTX using ARMCC aware of reserved stack and heap

b6ff439

[EFR32] Reduce test stack sizes on EFR32

b64fa3a

bridadan approved these changes Nov 9, 2016

View reviewed changes

0xc0170 added needs: work and removed needs: CI needs: review labels Nov 16, 2016

stevew817 added 4 commits November 18, 2016 10:58

[EFR32] Move Nanostack driver to Nanostack folder

ad77371

mbed compile doesn't support two different FEATURE_X folders being merged, so we'll have to move our nanostack driver into the Nanostack folder for the time being.

Revert "[EFR32] Move the mbedTLS hardware acceleration code to EFR32 …

ed905b7

…family" This reverts commit a0f62b1.

Fix broken file

ef690f7

Revert "[EFR32] Adding hardware acceleration for mbed TLS"

245e2e2

This reverts commit c0301b1.

adbridge added needs: CI needs: review and removed needs: work labels Nov 28, 2016

0xc0170 removed the needs: CI label Dec 1, 2016

0xc0170 added ready for merge release-version: 5.3.1 and removed needs: review ready for merge labels Dec 1, 2016

0xc0170 merged commit ab2e869 into ARMmbed:master Dec 2, 2016

amq mentioned this pull request Oct 8, 2017

Add missing device_name for targets with bootloader #5253

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Silicon Labs] Adding support for EFR32MG1 wireless SoC #3157

[Silicon Labs] Adding support for EFR32MG1 wireless SoC #3157

stevew817 commented Oct 28, 2016

0xc0170 commented Oct 28, 2016

stevew817 commented Oct 28, 2016

stevew817 commented Nov 7, 2016

stevew817 commented Nov 7, 2016

0xc0170 commented Nov 7, 2016

bridadan left a comment

bridadan commented Nov 7, 2016

stevew817 commented Nov 8, 2016

stevew817 commented Nov 8, 2016

stevew817 commented Nov 8, 2016

stevew817 commented Nov 8, 2016

bridadan commented Nov 8, 2016

stevew817 commented Nov 8, 2016 •

edited

Loading

stevew817 commented Nov 9, 2016

bridadan left a comment

bridadan commented Nov 9, 2016

stevew817 commented Nov 9, 2016

mbed-bot commented Nov 9, 2016

sg- commented Nov 10, 2016

sg- commented Nov 14, 2016

0xc0170 commented Nov 16, 2016

stevew817 commented Nov 18, 2016

stevew817 commented Nov 22, 2016

stevew817 commented Nov 26, 2016

adbridge commented Nov 28, 2016

mbed-bot commented Nov 28, 2016

stevew817 commented Dec 1, 2016

0xc0170 commented Dec 1, 2016

[Silicon Labs] Adding support for EFR32MG1 wireless SoC #3157

[Silicon Labs] Adding support for EFR32MG1 wireless SoC #3157

Conversation

stevew817 commented Oct 28, 2016

Description

Status

Migrations

Deploy notes

Steps to test or reproduce

0xc0170 commented Oct 28, 2016

stevew817 commented Oct 28, 2016

stevew817 commented Nov 7, 2016

stevew817 commented Nov 7, 2016

0xc0170 commented Nov 7, 2016

bridadan left a comment

Choose a reason for hiding this comment

bridadan commented Nov 7, 2016

stevew817 commented Nov 8, 2016

stevew817 commented Nov 8, 2016

stevew817 commented Nov 8, 2016

stevew817 commented Nov 8, 2016

bridadan commented Nov 8, 2016

stevew817 commented Nov 8, 2016 • edited Loading

stevew817 commented Nov 9, 2016

bridadan left a comment

Choose a reason for hiding this comment

bridadan commented Nov 9, 2016

stevew817 commented Nov 9, 2016

mbed-bot commented Nov 9, 2016

Result: SUCCESS

Output

sg- commented Nov 10, 2016

sg- commented Nov 14, 2016

0xc0170 commented Nov 16, 2016

stevew817 commented Nov 18, 2016

stevew817 commented Nov 22, 2016

stevew817 commented Nov 26, 2016

adbridge commented Nov 28, 2016

mbed-bot commented Nov 28, 2016

Result: SUCCESS

Output

stevew817 commented Dec 1, 2016

0xc0170 commented Dec 1, 2016

stevew817 commented Nov 8, 2016 •

edited

Loading