What I've done to deal with the problem

I reset the MSP430, clearing the hung state. I've slowed down the I2C clock's frequency, beefed up the Power Supply, changed pull-up resistors - no change.

Running additional processes increase the number of errors

However, the "errors" increase significantly by busying the ARM with two 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 Interrupt Service Routines to manage interrupts in the MSP430.

My Question

I know both devices have hardware state machines that manage the I2C. Given that the bugs hangs when the RPi is overworked, I suspect 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?

response to someone's clock question - I'm using a RPi-zero W, and yes, the i2c frequency changes if I modify the /boot/config.txt file (I confirmed with a scope that I can make it 10Khz, 400Khz, or whatever.... however, the default is 62.5Khz, not 100Khz). This is the entry in that file when set to 10Khz (the default is to comment out that 2nd line):


Further issue However, more strangeness with the OS or whatever is causing my problem: 1) if I run my program using daemontools via a "run" program pointed to in /etc/service, the errors are as I described: ~1 per 1000 accesses 2) however, if I run the program from a bash window, leaving the window open (i.e. not killing the program), errors come in at the rate of ~10 per 1000 accesses, i.e. 10x faster !!! (that is, at the prompt, I run python3 my_program.py ... I've also tried sudo python3 my_program.py and it doesn't change - still tons of errors. )

What is the difference? ... has to be something to do with the OS !
here is the result of ps aux | grep python3 .... 1) when I use daemontools (resulting in few errors):

*~/code $ ps aux | grep python3*
pi       2498  0.0  1.7  11296  7896 pts/0    T   06:50   0:06 python3 my_program.py
root     18682  3.7  1.7  10144  7732 ?       S   13:07   0:03 python3 my_program.py
pi       18687  0.0  0.4   4368  1972 pts/1   S+  13:09   0:00 grep python3

2) when I do it manually in a bash window using sudo (many errors):

*~/code $ ps aux | grep python3*
root    26325  0.0  0.8   7600  3556 pts/0 S+22:16   0:00 sudo python3 my_program.py
root    26329  0.6  1.7  11296  7832 pts/0 S+ 22:16  0:05 python3 my_program.py
pi      31327  1.0  0.4   4368  1800 pts/1 S+ 22:29  0:00 grep python3

Any idea what's going on ??

Problem solved (but not why) I increased the i2c bus frequency to 400KHz, and my worse case scenario (i.e. 2 busy-the-OS programs running, and an SSH bash shell manual start) has not yielded a single error in 3 hours (that's 2000+ accesses). I am surprised that speeding up the bus makes things better. Since the default is really 62.5Khz, when I dropped it to 50Khz, the change wasn't statistically significant, and thus I concluded it didn't change anything. I still think it's something to do with the ARM's BSC, and the canned code used to service it - maybe a timer that times out and hangs the bus when clk freq is low (it runs with huge number of errors at 10Khz!). Time to move on. thanks for any help provided and/or contemplated :)

  • The Pi doesn't handle clock stretching properly. Apart from that I am not aware of any I2C protocol errors. Some code which exhibits the problem would be useful.
    – joan
    Apr 21, 2019 at 8:17
  • not sure if this helps - it assumes there's a MSP430G2553 on the bus. 'for _ in range(3): try: myData = bus.read_i2c_block_data(G2553_adr, read_cmd, numToRead) successReadG2553 = True break except Exception as e: fileErrorPrint("\nError reading flow from G2553 at " + str(time.strftime("%c")) + " ... resetting G2553 chip") # reset the TI chip GPIO.output(nReset_2553, False)' ...sorry, don't know how to present code properly
    – JoeM
    Apr 22, 2019 at 22:50

1 Answer 1



... 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 (see Note below). 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)

Update 2019apr21hkt1156

I did try smbus2 but sadly encountered other compatibility problems. :(


Python quick block write problem

I tried python 3.5.3 block write and found no problem. However, when I tried block read, I need to use a special parameter, ie, only 3 parameters of the usual 4. But pyton won't entertain. I googled and found that it is a common error or limitation. :(


Rpi3 I2C Baud Rate Setting - samtal 2018aug04

/ to continue, ...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.