EFR32FG support #5271

@@ -243,6 +243,7 @@ osMutexAttr_t             singleton_mutex_attr;
        #define HEAP_START      ((unsigned char*)__end__)
        #define HEAP_SIZE       ((uint32_t)((uint32_t)INITIAL_SP - (uint32_t)HEAP_START))
    #endif
+#else


@0xc0170 This seems to be out of place?

stevew817 · 2017-10-10T15:25:54Z

targets/TARGET_Silicon_Labs/TARGET_EFM32/TARGET_EFR32FG1/device/TOOLCHAIN_GCC_ARM/efr32fg1p.ld

+
+MEMORY
+{
+  FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 1024k


EFR32FG1 has 256k of flash and 32k of ram...

Whoops, didn't notice the switch between the PG1B and PG12B.

stevew817 · 2017-10-10T17:25:52Z

targets/targets.json

+        "public": false,
+        "bootloader_supported": true
+    },
+    "EFR32FG12_SLWRB4254A": {


This should be called EFR32FG12_BRD4254A to keep in line with the naming scheme. The OPN for the standalone radio board is SLWRB*, but the board's part number is BRD*, which is what we are using here on mbed.

stevew817 · 2017-10-10T17:26:16Z

targets/TARGET_Silicon_Labs/TARGET_SL_RAIL/mbed_lib.json

@@ -30,6 +30,10 @@
        "EFR32MG1_BRD4150": {
            "sl-rail.has-2p4": true,
            "sl-rail.has-subgig": true
+        },
+        "EFR32FG12_SLWRB4254A": {


This should be called EFR32FG12_BRD4254A

stevew817 · 2017-10-10T17:26:52Z

targets/TARGET_Silicon_Labs/TARGET_SL_RAIL/mbed_lib.json

@@ -30,6 +30,10 @@
        "EFR32MG1_BRD4150": {
            "sl-rail.has-2p4": true,
            "sl-rail.has-subgig": true
+        },


I think you need to add EFR32FG1_BRD4250B as well?

stevew817 · 2017-10-10T17:29:41Z

I'm assuming you copied the device header files from your SDK install in Simplicity Studio?

ryankurte · 2017-10-11T20:46:08Z

Yep, headers are all copied from the SDK version 5.1.3 from Simplicity Studio.

mbed-ci · 2017-10-11T21:00:32Z

Build : SUCCESS

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

Triggering tests

/test mbed-os

mbed-ci · 2017-10-11T23:33:04Z

Build : SUCCESS

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

Triggering tests

/test mbed-os

mbed-ci · 2017-10-11T23:52:20Z

Build : SUCCESS

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

Triggering tests

/test mbed-os

0xc0170 · 2017-10-19T11:17:46Z

@ryankurte What is the status of this PR after the update?

ryankurte · 2017-10-20T00:26:08Z

Made the fixes proposed by @stevew817, so provided they're happy I think it's good to go?

Tested running mbed client stack all ok, though I am having some wacky issues with mbed-trace and haven't got an EFR32MG to test whether it's broken on both.

theotherjimmy · 2017-10-23T15:24:18Z

/test mbed-os

theotherjimmy · 2017-10-23T15:25:22Z

@stevew817 Could you take another look?

stevew817

LGTM!

adbridge · 2017-10-31T15:30:39Z

/morph test

mbed-ci · 2017-11-29T20:55:48Z

Automatic CI verification build not done, please verify manually.

Cleaned up changes to mbed_boot.c Rename SLWRB4254A -> BRD4254A

Cleaned up changes to mbed_boot.c Rename SLWRB4254A -> BRD4254A Fixed (Removed) INITIAL_SP override in target.json Reordered target definitions Fix INITIAL_SP override Removed incorrect radio configs

ryankurte · 2017-12-21T00:07:53Z

targets/targets.json

@@ -2951,7 +2951,7 @@
    },
    "EFR32MG12P332F1024GL125": {
        "inherits": ["EFM32"],
-        "extra_labels_add": ["EFR32MG12", "EFR32_12", "1024K", "SL_RAIL", "SL_CRYPTO"],
+        "extra_labels_add": ["EFR32_12", "EFR32MG12", "EFR32_12", "1024K", "SL_RAIL", "SL_CRYPTO"],


Added EFR32_12 and EFR32_1 labels missing from PR #5579

ryankurte · 2017-12-21T00:11:38Z

@0xc0170 @stevew817 updated against #5579 with new RAIL. This PR now /only/ introduces the device and board support for the FG device family.

Note that PR #5742 (parameter error) and issue #5735 (missing configs) will need to be resolved for correct radio operation.

adbridge · 2017-12-29T13:15:03Z

@ryankurte Does this now support all 3 compile chains?

0xc0170 · 2018-01-08T12:04:47Z

I'm going to mark this as 'changes requested', pending the merge of #5579.

It was integrated, this is ow ready for review?

cmonr · 2018-01-12T16:58:51Z

@stevew817 ^^^

ryankurte · 2018-01-14T20:55:59Z

AFAIK the new RAIL should work with all platforms (@stevew817). I don't know what executes those tests, or where from, or have the other toolchains to personally test with.

I need to refactor out the library duplication I seem to have caused (see #5735), but the the RAIL cross platform issue applies to all targets with RAIL, not just this one, and could become a separate issue along with the fixes in #5742?

Also as a related aside, would y'all be open to a PR of some intrinsically safe single producer/consumer queues and memory pools? Because it seems critical for driver development, and we seem to keep having to implement them because the OS ones don't work in an interrupt context.

theotherjimmy · 2018-01-22T17:31:13Z

@ryankurte

would y'all be open to a PR of some intrinsically safe single producer/consumer queues and memory pools?

Yes, I think so. @geky @c1728p9

cmonr · 2018-02-05T16:46:03Z

@ryankurte @stevew817 is this PR still dependent on #5735 and #5742 ?

geky · 2018-02-05T17:31:03Z

would y'all be open to a PR of some intrinsically safe single producer/consumer queues and memory pools?

Oh, I thought the rtos was irq safe where useful. For example you can put/get to queues in irq:
https://github.com/ARMmbed/mbed-os/blob/master/rtos/Queue.h#L107
https://github.com/ARMmbed/mbed-os/blob/master/rtos/Queue.h#L122

Which parts fall apart in irq context?

Does the event queue work in this case? It's irq safe and rtos agnostic:
C++ api: https://github.com/ARMmbed/mbed-os/tree/master/events
C api: https://github.com/ARMmbed/mbed-os/tree/master/events/equeue

I'd be curious to know what we're missing for irq context, in which case new prs are always welcome.

ryankurte · 2018-02-06T22:17:17Z

@geky the main problem with the queue is that you can't allocate memory or use a memory pool (because of the stats events) from the ISR. So while you can enqueue things, you can't make anything to enqueue without a custom memory pool anyway.

@cmonr depending on the result of #5735 I may no longer be able to work on this. It's only an interdependence in that the both need to be fixed, either way (without changes, or with either set of changes) the current state is broken ¯\(ツ)/¯

geky · 2018-02-06T22:35:09Z

I believe the alloc and dealloc are irq safe:
https://github.com/ARMmbed/mbed-os/blob/master/rtos/Mail.h#L84-L92

What do you mean by stats events?

ryankurte · 2018-02-06T23:14:20Z

The memory pool by default causes RTX events that as best I can tell are for collection of pool statistics, which afaik require a syscall and results in an error in rtos/TARGET_CORTEX/rtx5/RTX/Source/rtx_evr.c#L1633. I might be wrong / it might be something else, but this is where I got by stepping out of error with the debugger.

It's stated here that malloc is not officially thread safe (and there's a bunch more discussion around the pool etc.). Unfortunately I didn't document the failure, but as far as I remember malloc uses a global mutex, and mutexes don't work in ISRs for the same reason.

geky · 2018-02-06T23:20:53Z

Ah, if it is that specific line that is failing, that's actually due to creating the Mail object in irq, different from allocating from the Mail object. Allocating from the Mail object should end up here, though I'm not sure what goes on in the event recorder calls. If EvtRtxMemoryPoolAlloc results in a memory allocation or mutex, that's definitely a bug on our side.

ryankurte · 2018-02-07T02:31:29Z

Yeah it ends up at the line you mentioned, I meant to point out that it does a whole lot of "event recording" in a whole lot of cases which is not good (tm) from an ISR.

In summary:

memory pools don't like ISRs because they use events for collecting stats (which can be turned off from the look of it, but whaat)
malloc isn't really ISR safe (and realloc is bad practice in predictable embedded firmware anyway)
Mail etc. fail poorly because they're constructed from 1
All of this is completely insane to debug because the error() trap is in the os thread which means you have no easy access to context for what actually caused the problem

That said, it is all more related to the #5742 stuff RAIL than this.

cmonr · 2018-02-12T16:58:01Z

@ryankurte Are you still working on this PR?

cmonr · 2018-02-27T06:27:12Z

Closing due to inactivity. @ryankurte feel free to reopen if this is a mistake or further activity is still planned or in progress.

0xc0170 added the needs: review label Oct 9, 2017

ryankurte force-pushed the feature/efm32fg-support branch 3 times, most recently from df52436 to b818d9d Compare October 9, 2017 11:23

ryankurte mentioned this pull request Oct 10, 2017

Fix for Nanostack threading on EFR32 devices #5270

Merged

stevew817 reviewed Oct 10, 2017

View reviewed changes

theotherjimmy added the scope: new-target label Oct 23, 2017

stevew817 approved these changes Oct 23, 2017

View reviewed changes

adbridge added needs: preceding PR needs: CI labels Oct 31, 2017

ryankurte mentioned this pull request Dec 18, 2017

SLIP TX does not appear to ever be started PelionIoT/sal-stack-nanostack-slip#11

Open

ryankurte force-pushed the feature/efm32fg-support branch 2 times, most recently from d9f0635 to c15ee12 Compare December 18, 2017 02:37

Working on new chip support

39fdb86

Cleaned up changes to mbed_boot.c Rename SLWRB4254A -> BRD4254A

ryankurte force-pushed the feature/efm32fg-support branch from c15ee12 to 8d145e4 Compare December 20, 2017 23:53

Working on new chip support

d74d7af

Cleaned up changes to mbed_boot.c Rename SLWRB4254A -> BRD4254A Fixed (Removed) INITIAL_SP override in target.json Reordered target definitions Fix INITIAL_SP override Removed incorrect radio configs

ryankurte force-pushed the feature/efm32fg-support branch from 8d145e4 to d74d7af Compare December 21, 2017 00:01

ryankurte commented Dec 21, 2017

View reviewed changes

theotherjimmy added needs: review and removed needs: work labels Jan 8, 2018

cmonr added needs: work and removed needs: review labels Jan 25, 2018

cmonr closed this Feb 27, 2018

cmonr removed the needs: work label Feb 27, 2018

EFR32FG support #5271

EFR32FG support #5271

Uh oh!

Conversation

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

Uh oh!

Description

Status

Related PRs

Uh oh!

0xc0170 commented Oct 9, 2017

Uh oh!

ryankurte commented Oct 9, 2017

Uh oh!

mbed-ci commented Oct 10, 2017

Triggering tests

Uh oh!

mbed-ci commented Oct 10, 2017

Uh oh!

mbed-ci commented Oct 10, 2017

Uh oh!

mbed-ci commented Oct 10, 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!

stevew817 commented Oct 10, 2017

Uh oh!

ryankurte commented Oct 11, 2017

Uh oh!

mbed-ci commented Oct 11, 2017

Triggering tests

Uh oh!

mbed-ci commented Oct 11, 2017

Triggering tests

Uh oh!

mbed-ci commented Oct 11, 2017

Triggering tests

Uh oh!

0xc0170 commented Oct 19, 2017

Uh oh!

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

Uh oh!

Uh oh!

theotherjimmy commented Oct 23, 2017

Uh oh!

theotherjimmy commented Oct 23, 2017

Uh oh!

stevew817 left a comment

Choose a reason for hiding this comment

Uh oh!

adbridge commented Oct 31, 2017

Uh oh!

mbed-ci commented Nov 29, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ryankurte commented Dec 21, 2017

Uh oh!

adbridge commented Dec 29, 2017

Uh oh!

0xc0170 commented Jan 8, 2018

Uh oh!

cmonr commented Jan 12, 2018

Uh oh!

ryankurte commented Jan 14, 2018

Uh oh!

theotherjimmy commented Jan 22, 2018

Uh oh!

cmonr commented Feb 5, 2018

Uh oh!

ryankurte commented Oct 8, 2017 •

edited

Loading

ryankurte commented Oct 20, 2017 •

edited

Loading

geky commented Feb 5, 2018 •

edited

Loading

ryankurte commented Feb 6, 2018 •

edited

Loading