EFM32: update emlib to 5.9.1 #12547
EFM32: update emlib to 5.9.1 #12547
Conversation
| @@ -46,17 +46,6 @@ Gecko Platform 2.6.0.0 (32-bit MCU SDK 5.8.0.0) | |||
| - Added LETIMER_CounterGet() and LETIMER_CounterSet() functions to | |||
| em_letimer. | |||
| - Added TIMER_SyncWait() function to em_timer. | |||
| * Changed | |||
There was a problem hiding this comment.
Was there a reason for removing this section?
There was a problem hiding this comment.
It was a duplicate of the "Added" section.
There was a problem hiding this comment.
Whoops. Thanks for the keen eye, I'll notify the internal team.
|
Thanks a lot, @amq ! As you surely have noticed, all files in emlib are now explicitly ZLib licensed, which should make this kind of PR smooth sailing. |
|
@amq, thank you for your changes. |
Nice ! License checked all passed ! |
|
CI started |
Test run: FAILEDSummary: 1 of 4 test jobs failed Failed test jobs:
|
|
Please review build failures: |
|
|
|
@ARMmbed/mbed-os-core Please review failures in the boot IAR file. |
Most references I found for IAR, they use tVectorEntry type. We need this for a pragma later, thus we should use the same type. Found in ARMmbed#12547
Following IAR guide for RAM vector table, this is in the code snippet there: ``` extern void * __vector_RAM_table []; void main(void) ``` Found in ARMmbed#12547
|
Looking at this again once I got the license , the file Following https://www.iar.com/support/tech-notes/general/execute-in-ram-after-copying-from-flashrom-v5.20-and-later/ - we use vector table pragma in iar boot as its written in the optional section there. The header file should be updated - we are getting this line here: not the code on the line 68. If we get the line 68: it should be fine, shouldn't it be? @stevew817 Please review |
|
@0xc0170 You're getting both line 68 and 70. The #if IAR closes before line 70, meaning the preprocessor will swap out the __Vectors on line 70 with __vector_table, so that line 68 expands to Doesn't your fix in #12696 fix this? |
|
I was having a bit of a grumble there that I'm a bit sceptical about putting a declaration in a public header and forcing everyone to agree on it. As it's not a C structure, there might be valid reasons for wanting different types. Having it in a header is usually to get agreement on types - the linker would tell you if you got the name wrong, but not the type. Public headers lets the compiler warn you on type/prototype mismatches. Here you specifically don't need that. There's no error-checking value. I'd favour private |
|
Thanks @stevew817 for explanation. That means the file mbed-os/targets/TARGET_Silicon_Labs/TARGET_EFM32/TARGET_EFM32GG11/device/system_efm32gg11b.c should have what it needs (system_efm32gg11b.h do not need to have that vector table declared and exposed to upper layers. It causes the conflict as @kjbracey-arm explains). The suggestion is to move vector_table declarations from header file to code file. And this should be unblocked. |
|
Sure. @amq could you fix that manually in your PR? I'll open a ticket on my end to get this fixed in a future release, but to move things along, we can have slight modifications in here I feel. |
|
@stevew817 so, move the entire block? |
|
@stevew817 @0xc0170 please review |
|
CI started (travis restarted to report back status) |
|
client restarted |
Test run: FAILEDSummary: 1 of 6 test jobs failed Failed test jobs:
|
|
All passed, but Travis has not updated its status. I restarted it |
|
The last try for Travis. As it completes all green, this will go in |
Summary of changes
This upgrades Silicon Labs 32-bit MCU SDK (aka emlib) from 5.3.3 to 5.9.1
The changes are mostly bugfixes and new additions. See the changelog file for more details.
Impact of changes
While none of the mbed-os/hal functionality should be impacted, users should still test their programs, especially if they are depending on some undocumented behavior or are using emlib directly. I believe that the release of the major 6.0 version is a suitable time slot for such a change.
Migration actions required
None.
Documentation
None
Pull request type
Test results
EFM32GG_STK3700
EFM32PG12_STK3402
EFM32GG11_STK3701
Reviewers
@stevew817