-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Initializing with board.I2C() multiple times causing crash into safe mode #1603
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I forgot to add that this was on a Feather M4 Express. |
The setup I had for reproduction purposes is I was using the test code Jerry had at: I was just doing a quick test in CP4 before merging when I discovered this. |
when I try that test code with your feathewrwing library on a particle argon, I get
It works if I use my version of the alphanunum_featherewing.py
|
updated to current master CP -- same result
still works with my version |
Is someone calling |
sorry - no @makermelissa has
|
and the failure is on the sht31d device, not on the featherwing |
if I change the test code to this -- it works with the new featherwing code While this works, I think it makes more sense to just eliminate shared.py.
Both this is a discussion fo rthe library |
Ran both version on a feather_m4_ express -- the original version reproduces the safe mode crash While this works, I think it makes more sense to just eliminate shared.py. |
FYI -- the safe mode crash on the SAMD51 is
|
No, it shouldn't crash. |
I'm trying to reproduce this in the simplest way possible, and not succeeding. Are you saying that your
And then you get a crash when referencing
which is what I'd expect. And if I try this, I get an expected error:
|
I couldn't get it to happen in the REPL either and I wondered if it might have something to do with calling it in different files or through an import or something. Also, the entire contents of shared.py is basically what @jerryneedell posted above. |
I also tried commenting out everything except this in shared and it still crashed.
|
This might have to do with class and global dictionaries or something like that. I'm not sure it's related to I2C at all, really. If you can give me the simplest test case you can muster that would be really helpful. Thanks. |
Ok, I'll keep playing with it and see what I can come up with. |
I kept trying to boil this down and even just removing a little of the SHT31D module made it behave as expected. It seems to be some kind of bad combination of things. I can go ahead and close this is you want or leave it open for later. |
Nevermind, I got it to crash again, so I'll keep working on it. |
No, please leave it open. A crash is a crash, and needs to be fixed. |
Ok, thanks Danh. I'll leave it be. |
What is the smallest repro case we have for this? I can take a look tomorrow. |
Other than the scenario I originally described, I haven't been able to get it to reproduce with anything smaller. |
I've reproduced this on a Feather M4. Will now try on Metro M4 where I can run a debugger. |
I've reproduced this on Metro M4 and confirmed it's long-lived related. (The bug disappears if I turn long-living off.) Still digging into why. |
Without long living them you may clone them when long living a module that uses them. Fixes #1603
I was experimenting with changing from busio.I2C over to board.I2C() for another issue due to conflicts. It worked great in CP 3.1.2, but in both CP4 Beta 2 and the latest build off master, it causes the board to go into safe mode.
The text was updated successfully, but these errors were encountered: