Hello there,

I'm developing a device acting as an interface between two industrial parts which usually only were connected by a ribbon cable. Communication between is done by using I2C protocol. So I'm using mbed's two i2c-ports, one in slave-mode, one in master mode. They are working independent, my software is taking input from the slave side and handles it over to the other one, this time on the 'master' port. I encountered lockups on my program, leaving interrupts working, but the main loop hangs. Investigation lead to the fact that the receiving part is working fine, at least this night 'til I came from work home again, after I commented out one line of code which only sends one command to the 'master' side. Having read that there could be an issue with i2c-lockups I tried to add a timeout-handler to wake up the blocking part, but without any effort. I then made a test-version with only i2c-master access (a simple counting loop 0-9999, output given to the addressed SAA1064, which is beeing used here). This is working fine over a long time, too. Finally I added the test-loop-code into my project - now the system locks up again - about 10 mins after start.... To eliminate errors in my code I changed the written data to static values - 6 bytes which never change... But it locked up again....

Is there a dependency between I2C master & slave which I have to keep in mind?

Michael

Ok,

just to write down what I found out...

I guess thes lockups were caused by updating the display too often - I assumed (master-)write-operations would only happen when former operations had finished. Seems not to be so, therefore the bus locked up. That's at least what I think.

I'm using a ticker now to write every 0.1s to the display, with no more problems.

Wouldn't it be better to have a similar function like on the 'slave-side' (i2c.receive()) which gives a feedback if the last write-action has been finished or not? Perhaps such a function exists already?

Michael