You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
issue any command that uses this io as i2c initiator SCL (like "glasgow run i2c-initiator --port A -V 3.3 scan")
glasgow is waiting endlessly for SCL to go high
I suggest to add a generous, but still reasonable timeout (like 1 second) for this case. Also return an explicit error message like "timeout, SCL stuck low" or similar.
I think this kind of error is not uncommon when testing or developing. Cases that come to mind are:
wrong IO pin selected
flaky connection
external pullup resistors not connected or forgotten to enable the internal ones
DUT misbehaving
It would be nice to add some similar detection for SDA too, currently you get back all zeros.
The text was updated successfully, but these errors were encountered:
Yes, that's pretty common. We can add a timeout for USB requests, which is already supported by the streaming code we have, and raise an exception in I2CInitiatorInterface. The state machine in the applet gateware will remain stuck, and that's OK because recovering from this state ~always requires a full reset, often even a power on reset.
I2C doesn't require a timeout (unfortunately, IMO) so it'll have to be optional, but having it something like 1 second by default seems generally OK.
(Aside: gateware and software tags are for base Glasgow code, applets get a per-applet label. I think you should be able to create them.)
how to reproduce:
I suggest to add a generous, but still reasonable timeout (like 1 second) for this case. Also return an explicit error message like "timeout, SCL stuck low" or similar.
I think this kind of error is not uncommon when testing or developing. Cases that come to mind are:
It would be nice to add some similar detection for SDA too, currently you get back all zeros.
The text was updated successfully, but these errors were encountered: