-
Notifications
You must be signed in to change notification settings - Fork 977
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
MXRT1050: Issue a hardware reset #702
MXRT1050: Issue a hardware reset #702
Conversation
This is to bring the hardware to a known state before drag-n-drop Signed-off-by: Mahesh Mahadevan <[email protected]>
/morph test |
Looks great! |
/morph test |
There's an issue with CI, will restart once the nodes are back running |
/morph test |
CI has a license issue, will be fixed. |
/morph test |
Yet not fixed, hopefully early this week |
@mmahadevan108 - can you provide a pre-built binary that we can start testing with? |
@mmahadevan108 does this help with the issues we have seen with pyOCD in pyocd/pyOCD#808? PyOCD is the flashing method we would prefer to use. |
/morph test |
Restarting tests |
/morph test |
Failures not related in tests, all fine here |
This is to bring the hardware to a known state before drag-n-drop.
Failures were seen when running automated mbed-os tests as drag-n-drop would fail when the completed test left the platform in a low-power state.
Issuing a hardware reset before drag-n-drop would put the platform back to default reset state.
Signed-off-by: Mahesh Mahadevan [email protected]