Skip to content

FIX: LPUART clock source selection should be left to serial driver #12409

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 1 commit into from
Feb 13, 2020

Conversation

LMESTM
Copy link
Contributor

@LMESTM LMESTM commented Feb 11, 2020

Summary of changes

This PR fixes the clock source initialization of LPUART1.

The clock source selection of LPUART depends on System clocks but also on
the serial baudrate. There is a specific computation done in serial driver
targets/target_STM/serial_api.c

At first start-up the LPUART1 clock selected in SetSysClock was anyway
overridden by the serial driver, so this was of no effect. But in case
of deep sleep SetSysClock is called again, while the driver isn't, so
SetSyClock was corrupting the serial clock configuration.

So let's remove these few lines of code which are causing trouble.

Impact of changes

No further impact foreseen.

Documentation

none


Pull request type

[x] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Fixes #12309


Test results

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[x] Tests / results supplied as part of this PR

Tested OK with example application provided in Issue #12309 testing with 115200 and 9600 baudrates.


Reviewers

@jeromecoutant


The clock source selection of LPUART depends on System clocks but also on
the serial baudrate. There is a specific computation done in serial driver
targets/target_STM/serial_api.c

At first start-up the LPUART1 clock selected in SetSysClock was anyway
overridden by the serial driver, so this was of no effect. But in case
of deep sleep SetSysClock is called again, while the driver isn't, so
SetSyClock was corrupting the serial clock configuration.

So let's remove these few lines of code which are causing trouble.
@jeromecoutant
Copy link
Collaborator

@JeanMarcR

@ciarmcom ciarmcom requested review from jeromecoutant and a team February 11, 2020 18:00
@ciarmcom
Copy link
Member

@LMESTM, thank you for your changes.
@jeromecoutant @ARMmbed/mbed-os-maintainers please review.

Copy link
Collaborator

@jeromecoutant jeromecoutant left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ST CI tests OK

@mergify mergify bot added needs: CI and removed needs: review labels Feb 12, 2020
@0xc0170
Copy link
Contributor

0xc0170 commented Feb 12, 2020

ci started

@mbed-ci
Copy link

mbed-ci commented Feb 13, 2020

Test run: FAILED

Summary: 1 of 11 test jobs failed
Build number : 1
Build artifacts

Failed test jobs:

  • jenkins-ci/mbed-os-ci_dynamic-memory-usage

@0xc0170
Copy link
Contributor

0xc0170 commented Feb 13, 2020

Job restarted (internal fault)

@0xc0170 0xc0170 added the release-version: 6.0.0-alpha-2 Second pre-release version of 6.0.0 label Feb 13, 2020
@0xc0170 0xc0170 merged commit 7658681 into ARMmbed:master Feb 13, 2020
@mergify mergify bot removed the ready for merge label Feb 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release-version: 6.0.0-alpha-2 Second pre-release version of 6.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

STM32L4R5ZI printf doesn't work with Tickless/PowerManagement
5 participants