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
Addendum 2022-02-11:
There seem to be more situations that cause i2cdriver to lock up unrelated to the scan command. Whenever I reprogram my Teensy (which includes the device resetting, causing some amount of noise on the i2c bus) I have to power cycle the I2Cdriver because it locks up hard (the I2Cdriver display shows some amount of red circles with "!" inside) and will not respond to any commands. This is very annoying because obviously I'm doing a lot of reprogramming of my Teensy and there's really no good reason for the i2cdriver to lock up just because there's a little bit of noise on the i2c line for a few moments.
I noticed that when I do a device scan (d command) while the I2Cdriver is connected to my breadboard (which at present has a Teensy 3.2 and a 24AA256 EEPROM connected to the I2Cbus with 4.7kOhm pullups) but the breadboard is not connected to power the I2CDriver locks up and I need to unplug and replug it to get it to anything again. Or alternatively if I plug in the breadboard, then the I2Cdriver's scan finishes, too.
I noticed this because the Python GUI wouldn't start and I dug deeper into what it does and then I saw that it does a "d" command and analysed it a bit more. It's not a big deal once you know about it, but since I figure it's not that uncommon for people to plug in and start stuff in a different order at times it would be good to catch this condition at some point because otherwise it looks like sometimes the GUI works and sometimes it doesn't.
The text was updated successfully, but these errors were encountered:
mbenkmann
changed the title
I2CDdriver locks up on device scan on unpowered breadboard.
I2CDdriver locks up sometimes
Feb 11, 2022
Addendum 2022-02-11:
There seem to be more situations that cause i2cdriver to lock up unrelated to the scan command. Whenever I reprogram my Teensy (which includes the device resetting, causing some amount of noise on the i2c bus) I have to power cycle the I2Cdriver because it locks up hard (the I2Cdriver display shows some amount of red circles with "!" inside) and will not respond to any commands. This is very annoying because obviously I'm doing a lot of reprogramming of my Teensy and there's really no good reason for the i2cdriver to lock up just because there's a little bit of noise on the i2c line for a few moments.
I noticed that when I do a device scan (d command) while the I2Cdriver is connected to my breadboard (which at present has a Teensy 3.2 and a 24AA256 EEPROM connected to the I2Cbus with 4.7kOhm pullups) but the breadboard is not connected to power the I2CDriver locks up and I need to unplug and replug it to get it to anything again. Or alternatively if I plug in the breadboard, then the I2Cdriver's scan finishes, too.
I noticed this because the Python GUI wouldn't start and I dug deeper into what it does and then I saw that it does a "d" command and analysed it a bit more. It's not a big deal once you know about it, but since I figure it's not that uncommon for people to plug in and start stuff in a different order at times it would be good to catch this condition at some point because otherwise it looks like sometimes the GUI works and sometimes it doesn't.
The text was updated successfully, but these errors were encountered: