-
Notifications
You must be signed in to change notification settings - Fork 3k
Fix UART initialization for NRF52 #6771
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
Conversation
/morph build |
Build : SUCCESSBuild number : 1882 Triggering tests/morph test |
Test : FAILUREBuild number : 1696 |
Exporter Build : SUCCESSBuild number : 1531 |
/morph test |
Test : FAILUREBuild number : 1697 |
/morph test |
Test : FAILUREBuild number : 1700 |
Delayed initialization can cause problems when both UARTE instances are in use. This change causes each UART object to initialize the underlying UARTE instance immediately.
/morph build |
Build : SUCCESSBuild number : 1892 Triggering tests/morph test |
Exporter Build : SUCCESSBuild number : 1539 |
Test : FAILUREBuild number : 1708 |
/morph test |
Test : FAILUREBuild number : 1710 |
How does PR affects lp timeout? 😕 An issue on master with this test and the target? |
It doesn't. @studavekar and I suspects that something was merged the past week that introduces some instability on the NRF52. That's when the instability began. |
It should be now green /morph build |
Build : SUCCESSBuild number : 1927 Triggering tests/morph test |
Exporter Build : SUCCESSBuild number : 1572 |
Test : SUCCESSBuild number : 1749 |
Description
Delayed initialization can cause problems when both UARTE instances
are in use. This change causes each UART object to initialize the
underlying UARTE instance immediately.
Pull request type