Skip to content

Release candidate for mbed-os-5.15.0-rc2 #12082

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 34 commits into from
Dec 12, 2019
Merged

Conversation

adbridge
Copy link
Contributor

No description provided.

Qinghao Shi and others added 30 commits December 11, 2019 10:45
If the fault handler was hit before the stdio console was used and
initialised, the initialisation code caused a "mutex in ISR" trap,
stopping the register dump from happening.

Temporarily set the `error_in_progress` flag at the top of the fault
handler, and restore it before calling `mbed_error`. Take the
opportunity to suppress fault dumps on recursive crashes, much as is
done inside `mbed_error`.
At IAR linking, the default method of 'initialize by copy' is 'auto', which will estimate
different packing algorithms, including complex 'lz77', for smallest memory footprint. But
the algorithm itself can consume some SRAM and cause OOM at linking time for NANO130, which
just has 16KiB SRAM. To avoid this error, always choose 'none' packing algorithm.
This adjustment is to pass compile on IAR on which heap configuration is hard-coded and cannot be adjusted according to staic SRAM usage.
Related PR:

#10924

The above PR adds functions to disable/enable serial input/output. If both serial input and serial output are disabled, the peripheral is freed. If either serial input or serial output is re-enabled, the peripheral is reinitialized.

I missed this change while working on the static pinmap and unfortunately it has an impact on it. The reinitialization is a problem for static pinmap. Now the HAL init()/init_direct() function is called not only in the constructor (but also when re-enabling the peripheral). In the current version, even if static pinmap constructor was used to create an object (and init_direct() HAL API), when reinitialization is done it uses init() HAL API. This must be split.

If static pinmap constructor is used, then the peripheral must be always initialized using HAL init_direct() function. If regular the constructor is used, then the peripheral must be initialized using HAL init() function. The same split also must be done while setting flow control during reinitialization.
This is done in order to enable static pin-map for Mbed Cloud Client Example. This should give extra ROM savings, ~1KB.
Currently any misconfiguration of, for example, bootloader feature will cause the
build system to just silently drop it and continue building which can lead to
completed builds of something the user didn't want to build in worst case and
failing builds after compilation (=wasted time) in the best.
We removed catching and passing, we want to know for any misconfiguration if bootloader
is supported. Regions should check if bootloader is supported. In case not, just return.
Otherwise we catch any error.

This should help us to uncover missing regions or other config error (in case bootloader
is enabled via bootloader_supported set to true).
The config failes with an exception that was previously ignored.
Until the error is fixed:
    "start not found in targets.json.".format(active_memory)
An error to be fixed:
tools.config.ConfigException: Missing a memory that is read, write in CMSIS Pack data
device_name is missing
This should be reverted once bootloader is supported.
@adbridge
Copy link
Contributor Author

ci started

This reverts commit eedfd64.

The only changes in this commit are white space changes which
are actually wrong and breaking the astyle checks.
@adbridge
Copy link
Contributor Author

CI restarted

@adbridge
Copy link
Contributor Author

Also triggered branch job for release-candidate

@mbed-ci
Copy link

mbed-ci commented Dec 11, 2019

Test run: SUCCESS

Summary: 12 of 12 test jobs passed
Build number : 1
Build artifacts

@adbridge
Copy link
Contributor Author

restarted branch test, looks like there was a possible license error

@mbed-ci
Copy link

mbed-ci commented Dec 11, 2019

Test run: SUCCESS

Summary: 12 of 12 test jobs passed
Build number : 2
Build artifacts

@adbridge
Copy link
Contributor Author

release_candidate branch job upgraded to use ARMC 6.13 so hopefully that will fix the issues. Branch job restarted

@adbridge adbridge merged commit 5d7f5bd into mbed-os-5.15 Dec 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants