Issue with lack of hardware support causing mbed_hal-reset_reason test failure

[dustin-crossman]

Description of defect

During the mbed_hal-reset_reason greentea test the device is reset using DAP and the test expects to see a PIN_RESET reason upon reset (host_tests/reset_reason.py lines: 146-153). The Cypress PSoC6 hardware does not support a reset reason for a DAP reset. During a DAP reset the reset reason registers are the same as during a basic power on and is therefore unable to differentiate the reasons. There is no way to indicate that the test is invalid for the particular hardware under test and, therefore, the test should be disabled/bypassed.

Target(s) affected by this defect ?

Tested on CY8CPROTO_062_4343W but should be seen on all Cypress PSoC6 hardware

Toolchain(s) (name and version) displaying this defect ?

Tested on GCC_ARM but should be toolchain-agnostic

What version of Mbed-os are you using (tag or sha) ?

The cypress reset reason hal api implementation is not yet merged but this branch has an implementation: https://github.com/dustin-crossman/mbed-os/tree/cyhal_reset_reason_issue

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

mbed-cli: 1.10.1

How is this defect reproduced ?

mbed test -t GCC_ARM -m CY8CPROTO_062_4343W -n "tests-mbed_hal-reset_reason"

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOTRIAGE-2311

[yarbcy]

@0xc0170 Please review. This issue is reported by Cypress team.

[yarbcy]

@0xc0170 ?

[0xc0170]

cc @maciejbocianski @mprse

[0xc0170]

Not all reset reasons are supported by a target, test checks 3 reset reasons - assuming they are always present - software, pin reset and watchdog. In this case, pin reset is not available?

I don't see get_capabilities functionality so we can't check what reset reasons are actually supported by a target and can be tested. Is that correct? Would adding this function to HAL, help to skip this pin test as it is not available for the target reported above.

[dustin-crossman]

Yes, in this case, pin reset is not available.

Yea adding a get_capabilities would be a good addition I think. It would additionally allow testing of more reset reasons (e.g wake_low_power), assuming they can be programmatically triggered and hardware support exists.

[0xc0170]

cc @maciejbocianski @mprse

cc @ARMmbed/mbed-os-hal Please review, looks like reset reason needs also an extension

[fkjagodzinski]

Agreed, a xxx_get_capabilities() style function looks like a good solution here. I'll try to take care of this in the following week.

[jamesbeyond]

Is this issue also the same cause for the failure of watchdog test ?

[dustin-crossman]

@jamesbeyond What watchdog test failure do you mean? I didn't really see a watchdog test failure (my testing never got there since it failed out before that point). Is there a general watchdog test failure being observed with other hardware?

[jamesbeyond]

On our end, we are seeing CY8CPROTO_062_4343W target failing at following greentea test:

• tests-mbed_drivers-watchdog
• tests-mbed_drivers-watchdog_reset
• tests-mbed_hal-sleep
• tests-mbed_hal-sleep_manager
• tests-mbed_hal-watchdog
• tests-mbed_hal-watchdog_reset

So have you seen these @dustin-crossman ?
I am not sure if these failures is related to this issue.

[dustin-crossman]

@jamesbeyond
Looking at some greentea logs from a couple days ago I see that the drivers-watchdog* and hal-watchdog* tests all passed on a CY8CPROTO_062_4343W. I do see failures on the hal-sleep* tests but that is an expected failure on our end.

Regardless, I don't think any of that is related to the reset reason issue.

[jamesbeyond]

Hey @dustin-crossman, why is the sleep failure is expected, what is the cause?
If there is no plan to address the sleep failures, isn't that make sense we can turn off the SLEEP feature in https://github.com/ARMmbed/mbed-os/blob/master/targets/targets.json#L9164

[dustin-crossman]

The sleep failures occur because our UART hardware prevents the board from entering sleep while there is traffic over UART (like during GT tests). We're looking at workarounds on our end. The boards are still capable of sleep mode for most purposes so that's why we keep the SLEEP feature on.

[dustin-crossman]

Hey @fkjagodzinski how goes implementing the get_capabilities() function for this issue?

[fkjagodzinski]

@dustin-crossman I'm really sorry to keep you waiting this long. Unfortunately, I was busy with other stuff, but I think I'll finally be able to update our code in following days.

[dustin-crossman]

Great! Thanks a bunch!

[fkjagodzinski]

@dustin-crossman, please see #12139.

[ifyall]

@dustin-crossman confirmed in a post on #12139 that the PR will allow us to address this issue. A future PR from Cypress will be necessary to fully close the issue. We (Cypress) will create that PR once #12139 is committed to master.

Thanks,

Ian