Hjdcti

... resetting the MSP430 clears the hung state. I've slowed down the i2c clock freq, beefed up the PSupply, changed pull-up resistors - no change. However I made the "errors" increase significantly by busying the ARM with 2 calculation-intensive programs. I use Python in RPi, using smbus, SMBUS and
i2c_LCD_driver and try/except routines in the RPi to catch the bad access and reset the MSP - after that, accesses every 5 seconds continue fine until the next hang, ~1000 accesses later. I use C for the ISRs to manage interrupts in the MSP430.

I know both devices have hardware state machines that manage the i2c. Given that I can hang the bus by overworking the RPi, my suspicion was/is the implementation of the canned i2c python code. Is anyone aware of any weird
stuff about the Broadcom Serial Controller (BSC) i2c controller in the ARM that would hang a slave's state machine based on busy-ness of the OS managing the BSC ... or other cases of very intermittent bus hangs ?

I've slowed down the i2c clock freq

I am using RPi3B+ stretch 2019apr python 3.5.3.

I surprisingly and sadly experienced, and read that Rpi3B+ stretch python 3.5x I2C is buggy.

I could never have slowed down the default I2C 100kHz. I tried to change speed up to 400kHz and down to 50kHz. But hardware did not respond - no nothing changed. :(

I read that it is a hardware bug. Are you sure you have actually successfully changed the speed? I vaguely remember that I could indeed change the speed when I was in jessie or earlier days.

I also found that python 3.5.3 block read does not fully implement to entertain all the parameter patterns. My projects were "hung" and much time wasted. :(

I am anxiously waiting for the coming soon Rpi4 to hopefully resume my couple of long stalled I2C related projects. In the meaning time I am switching to SPI (I2C MCP23017 to SPI MCP23S17, etc)

References

RASPBERRY PI3 I2C BAUD RATE SETTING Postby samtal » 2018-Aug-04 Sat 1:45 pm

/ to continue, ...