-
Notifications
You must be signed in to change notification settings - Fork 3k
Watchdog API update #10645
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
Watchdog API update #10645
Conversation
I assume all the review comments of the original PR (#10066) have been addressed. The purpose of this PR is to re-run the CI tests after rebasing to current |
@fkjagodzinski, thank you for your changes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes already got reviewed, in #10066 , should be good.
We open this new PR only because Raj's on long holiday, we want to get this PR going and merged
Test run: FAILEDSummary: 1 of 11 test jobs failed Failed test jobs:
|
The feature branch needs a rebase to get python3 fix (causing the failures here). |
-Added API to register muliple threads to watchdog drivers -Watchdog timeout reconfigures everytime whenever new register thread with longer timeout period -New APIs for watchdog wd_register(const osThreadId_t tid, const uint32_t timeout) to register to watchdog wd_unregister(const osThreadId_t tid) to unregister to watchdog kick(const osThreadId_t tid) to refresh the watchdog
- mbed_watchdog_mgr has interface name mbed_wdog_manager_start(),mbed_wdog_manager_stop(),mbed_wdog_manager_kick() - HwWatchdog is going to attach with LowPowerTIcker for periodic callback functionality - mbed_wdog_manager_start() will either get start either by BL/RTOS Aps,it reads the timeout value specified via macro and macro gets defined in target.json file. - mbed_wdog_manager_start() internally configure below HAL hw watchdog with timeout specified via target.json - mbed_wdog_manager_start() internally divide the timeout(specified in target.json) by the 2 and attach LowPowerTicker with periodic callback of hw_kick() - mbed_wdog_manager_start() internally create one instance of sw watchdog class,to access the static list data structure of sw watchdog class - mbed_wdog_manager_kick() function periodically get called and refresh the hw watchdog to avoid watchdog reset - converted C++ code into C based APIs - added boolean to control watchdog start and stop - Added detach from ticker on stop API
-SW watchdog has interface name start(),stop(),kick() Sw watchdog internally has static list and shared across multiple instance of SW watchdog - Sw watchdog initialize timeout value,unique string via constructor whenever threads created sw watchdog object -Threads make sure pass proper timeout value,Unique string while creating the instance. -start() called by components(BLE,WIFI etc.,),it adds the entry into static list with few details current count ,etc., -kick() called by registered components(BLE,WIFI etc.) to reset current count to zero. -is_alive - interface API to mbed_watchdog_manager -implementation optimization
- Added Hw watchdog periodic kick calls software watchdog is_alive check
-Added the unit test case for testing Hw watchdog -Added the supported stubs files
-Added the mock class function to mock mbed_assert_internal -Added the unit test case to test start,kick,stop -Modified the interface api name from is_alive to process -added the unit test cases for process
- Changed the process into static method - used the singletonptr for creating the low power ticker instance - Added the mbed stub into cmake build for cellularnonipsocket,loramacrypto
-Modified the device dont have support of lp ticker will ticker for watchdog callback register
-Created global instance of either LowPowerTicker or Ticker
7a0abd1
to
19272b7
Compare
OK, I rebased all commits to the current This PR is ready for the CI. |
@ARMmbed/mbed-os-maintainers please start CI if possible |
CI started |
Test run: FAILEDSummary: 6 of 7 test jobs failed Failed test jobs:
|
Internal CI error, restarted |
Can we have CI start on this again please? @ARMmbed/mbed-os-maintainers |
As soon as RC2 is completed, we can ! |
CI restarted |
I had to abort the CI job, we are experiencing internal errors. investigating |
Test run: FAILEDSummary: 6 of 7 test jobs failed Failed test jobs:
|
CI started |
Test run: FAILEDSummary: 1 of 11 test jobs failed Failed test jobs:
|
Update the watchdog timing requirements: 1. The watchdog should trigger at, or after the timeout value. 2. The watchdog should trigger before twice the timeout value.
I couldn't reproduce recent CI failures locally. Both:
failed the same assertion
which means 850 ms was not long enough for the watchdog to fire. As long as the watchdog fires before 1600 ms mark (twice the requested timeout) it's OK with new timing requirements (#8857 (comment)). The patch that updates watchdog timing tests is supposed to be merged after this PR, so to keep the history of this PR clean, I updated only the failed @0xc0170 , this is ready for another CI run. |
Hi @ARMmbed/mbed-os-maintainers, could you tag this PR for mbed-os 5.13.1? becasue this is expected to be delivered by then at least |
Functionality change can only be published in 5.14, not in patch release. |
@SeppoTakalo |
Seems all the tests are passed, can we merge this PR to feature branch ? |
@ARMmbed/mbed-os-maintainers |
Let's get this moving along on the feature branch 👍 |
Description
Bring changes from #10066 to
feature-watchdog
branch. Original description below:Pull request type
Reviewers
@rajkan01 @0xc0170 @donatieng @jeromecoutant @jamesbeyond
Release Notes