Release mbed lib v124 + mbed os 5.1.2 #2499
Conversation
Add a test to repeatedly malloc and free from different threads to test if these functions are thread safe.
…llow programming the sensor via mbed APIs See issue(#1746)
Software trigger for ST NUCLEO F1x series boards: Issue: #1672 (comment)
To be more consistant with ST targets, this commit change analog and pwm channel definitions to PeripheralPins.c
To be more consistant with ST targets, this commit change analog and pwm channel definitions to PeripheralPins.c
Add binaries for the Cortex-M7 architecture. These binaries are identical the the Cortex-M3 versions.
Signed-off-by: Mahadevan Mahesh <[email protected]>
Set well defined limits for the heap and configure GCC and ARMCC to correctly check these. IAR already correctly checked its heap. This also statically declares the main thread stack so the linker is responsible for its placement.
Decrease the main stack size for the nrf51 so there is more heap space available.
When new or new[] fails to allocate space trigger an error.
With the latest K64F linker file the initial stack is out of sync with INITIAL_SP when uVisor is not present. This patch removes the incorrect declaration.
Since the heap and stack are no longer shared, stack checking on the main thread can be turned back on. This allows stack overflows on the main thread to be caught quickly.
Test the following components of the heap and stacks: -Heap and interrupt stack are at the expected locations -Entire heap can be used -Heap limit is properly enforced and returns NULL when out of of memory
Decrease the interrupt stack of the NUC472 from 12KB to 8KB. This frees up enough space to allow the core tests to run.
Set the initial stack pointer to the end of ram so it matches INITIAL_SP defined in RTX_CM_lib.h.
The config store tests use more than 2K of the interrupt stack, causing an overflow. This patch bumps the K64F interrupt stack size to 4K for ARMCC and GCC. The IAR interrupt stack is left untouched since it is 32K.
The RTC1 counter can increase while the new value for the CC register used by the os tick is computed. As a result, when interrupts are enabled again RTC1 counter and CC register value are equal. If these two values are equal then the interrupt for the CC channel used by the OS tick will be generated the next time the RTC counter reach that value. In other words, the next OS tick will occur 131 seconds latter. This issue possibly concern all NRF51 targets with 32K of RAM but is only visible on NRF51_DK target when their is heavy BLE load.
MBED_A28 test is the same as MBED_A27 test. This is a CAN loopback test without any peripheral or wire. It can then be added in the common list.
Previously, build_mbed_libs didn't take into account the configuration. This is a problem when doing a binary release, since mbed_lib.json contains configuration data relevant to the binary release.
`build_lib` wasn't aware of configuration data, so some of the source files that depends on configuration data fail to compile. This commit fixes that by making `build_lib` aware of configuration data.
From the discussion on issue #2068: Functions marked deprecated in the mbed library should notate when the deprecation was started to allow efficient removal once a set amount of time has expired. Added the following macro: MBED_DEPRECATED_SINCE("version", "message string") Example usage: MBED_DEPRECATED_SINCE("v5.1", "don't foo any more, bar instead") void foo(int arg); Adopted in existing deprecations: - FunctionPointer - RtosTimer - Thread
Example:
MBED_DEPRECATED_SINCE("mbed-os-5.1", "don't foo any more, bar instead")
void foo(int arg);
Fails to build spi HAL
|
Is the policy to include new tests as well as new targets and bug fixes when porting to the release branch? This would make sense if it is a new test for existing code but not if it is a test for a new or updated feature on master ? We probably need some well defined and documented rules on this. |
Yes, the docs should be made available soon. I would say yew targets and new tests yes but not for new features. Lets sync on Monday and write it all down. |
|
/morph test |
|
We have a good example here of poorly distinguished commits: |
|
Stylize utils.py looks like it probably shouldn't have come to the release branch as it is a refactor again by the looks of it rather than a bug. However this one was committed straight to master so there aren't even any additional comments that I can see! |
|
My review of which commits have come across, highlights just how extremely hard this is to manage at the moment. How do we decide whether changes for documentation/style/refactor etc need to come across ? Especially if the changes have been committed directly to master and/or haven't been tagged as bugs, or as affecting a particular release?! It just shows that we need to get a rigid and reliable process in place asap if we want releases to go smoothly and go out on time... |
Result: SUCCESSYour command has finished executing! Here's what you wrote!
Outputmbed Build Number: 672 All builds and test passed! |
|
@mbed-bot: TEST HOST_OSES=ALL |
We should not be moving patches across after the 5.2 release. Maintainers should be instructing contributors an which commits to cherry-pick and make a pr against the appropriate active release branch. We just need some docs and git foo steps to help people learn this process since it'll be new |
|
[Build 822] |
|
Tests results are OK (822). LPC 4088 does not fit one specific SPI test into flash, others are without regression. |
|
LGTM 👍 @bridadan need to restrict OS to just windows I think even if options are passed for now. Lots of interface firmware failures when running in linux and mac CI environment. |
|
mbed lib v124 and rtos v120 is out |
|
tags mbed-os-5.1.2 and mbed_lib_rev124 pushed |
|
The mbed 2 CI should now only run on windows, even if you specify ALL |
Taken patches from master up until 0f2566b
Two additions that are not on master and will be sent there - mbed lib v124 commit + removing KL27Z IAR (does not compile), should be fix on master (there's a PR that needs testing)
Note: We should not use
[sth] messagein the git commit message headline because when applying patches, git thinks it's a subject and skips it. The format shall besth - message.I'll change a label to ready for merging once the release is out.
@adbridge @sg- @screamerbg