Not all e-h impls are super robust in error cases, and can sometimes end up waiting "forever" in error states. I've observed this with the nrf52840 acting as an I2C controller, with a mis-configured peripheral. The CLI times out, as the worker never responds (it's still waiting for the end of the I2C receive).
We should do (at least) one of the following to improve robustness:
Make sure to enable a watchdog that is serviced by the idle loop, to ensure we at least return to a workable state in case of errors
Add a "Software reset" command to the ICD, which is sent in the case of message timeouts noticed by the host (phm or phm-cli).
Ideally, all HALs would be more robust, but this is probably a reasonable workaround for now. This may also cause odd errors, as the serialport will probably detach in the case of soft resets.
Not all e-h impls are super robust in error cases, and can sometimes end up waiting "forever" in error states. I've observed this with the nrf52840 acting as an I2C controller, with a mis-configured peripheral. The CLI times out, as the worker never responds (it's still waiting for the end of the I2C receive).
We should do (at least) one of the following to improve robustness:
Ideally, all HALs would be more robust, but this is probably a reasonable workaround for now. This may also cause odd errors, as the serialport will probably detach in the case of soft resets.