bitbo03/system: implement communication_timeout_reset

[benma]

Tested by inserting this into workflow/pairing.rs at top of the confirm function:

extern crate std;
hal.system().communication_timeout_reset(-70);
std::thread::sleep(core::time::Duration::from_secs(5));

Without the reset, the sleep will destroy the workflow because of the timeout. WIth the reset, it proceeds successfully.

[NickeZ]

Can we wait with this until it is necessary? In the bb02 this is necessary because the main loop is blocked for some operations, right? I hope that won't be the case for bb03 if we don't paint ourselves into that corner again.

[benma]

Can we wait with this until it is necessary? In the bb02 this is necessary because the main loop is blocked for some operations, right? I hope that won't be the case for bb03 if we don't paint ourselves into that corner again.

Don't think it can wait. The slow operations will be in BB03 too, which I think solely come from securechip operations, which are not async yet. I'd rather have this for a little longer and not work on making securechip ops async for now.

[NickeZ]

NAK, my experience so far with the STM SDK is that we cannot block the main loop.

[benma]

NAK, my experience so far with the STM SDK is that we cannot block the main loop.

Okay, then it will be a no-op #1890.

Will leave this in draft mode in case we can find a STM workaround to avoid reworking the securechip ops to be async.