Mbed-os: Wifi broken on Cypress targets after #12425

[kyle-cypress]

Description of defect

After the merge of #12425, tests-network-wifi fails because WIFI-CONNECT-NOCREDENTIALS times out.
If I check out a9cb876b3948887fc3b44717e26788e0928ad418 , which is the merge of #12737 (the previous PR to go in before #12425), the test succeeds.
Similar behavior is seeing with mbed-os-example-wifi, which also hangs on scan.

Target(s) affected by this defect ?

CY8CKIT_062_WIFI_BT
CY8CPROTO_062_4343W
Possibly others

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

GCC_ARM 6.3.1

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

af4c8a94f3913ceda9069ec79cba81a793d695fe

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

mbed-cli 1.10.2

How is this defect reproduced ?

mbed test -t GCC_ARM -m CY8CPROTO_062_4343W -n wifi

[0xc0170]

@kjbracey-arm Can you review? timing changed in wifi tests after 12425?

[kjbracey-arm]

Could this also be a binary compatibility issue? I can't immediately think of any binary breakages due to the Chrono work, but there may be something, eg in the definition of Timer?

[ciarmcom]

Thank you for raising this detailed GitHub issue. I am now notifying our internal issue triagers.
Internal Jira reference: https://jira.arm.com/browse/MBOTRIAGE-2655

[0xc0170]

cc @ARMmbed/mbed-os-ipcore

[kyle-cypress]

There aren't any binary images on these targets that interact with the mbed APIs. The only blobs are:

• Prebuilt CM0p image. This just starts the CM4 then goes to sleep to wait for IPC calls, which it services independent of anything from mbed.
• Radio firmware. This is not executed on the MCU, just set unmodified down to the radio.

So I can't think of any situations where binary compatibility would be an issue.

[0xc0170]

Thanks @kyle-cypress , might be a timing then. There is now another timing related issue to the latest changes to master https://github.com/ARMmbed/mbed-os/issues/12920 (lets see how this relate).

[0xc0170]

Thanks @kyle-cypress , might be a timing then. There is now another timing related issue to the latest changes to master #12920 (lets see how this relate).

There's an update in 12920 (seems to be related to deep sleep locking), would you be able to provide details about the target if it uses tickless and if any suggestions there fixes the problem here (just to know if this is related or not)

[0xc0170]

GCC_ARM 6.3.1

As another issue was closed because of the older version, @kyle-cypress can you retest with the latest one? Just in case. Although there seems to be timing related issue but want to be sure.

[kyle-cypress]

@0xc0170 , several data points for you:

1. I tested with the Q4 release of GCC 9 and saw the same behavior.
2. The target does use tickless. If I disable tickless, the test passes.
3. If I attach an empty idle hook, the test also passes.
   Are there any other experiments from #12920 that would be useful for me to run?

[kjbracey-arm]

As the failure conditions exactly match, I hope this is fixed by #12938. (Although there is another failure with different conditions reported in 12920's comments that I'm still investigating)

[0xc0170]

12938 was merged, @kyle-cypress please retest the latest master

[kjbracey-arm]

Check also #12941 if that didn't fix it.

[kyle-cypress]

Latest master alone still doesn't work.
But #12941 (rebased onto latest master) does.
Thanks!

[0xc0170]

Awesome ! #12941 landed, can we close this one?

[kyle-cypress]

Yep. Just verified that the fix on latest master with both CY8CKIT_062_WIFI_BT and CY8CPROTO_062_4343W.