Just a quick follow up....
The hang-up only seems to happen if there is any kind of corruption on the SDA line - anything which gives a "NACK".
We can work around this by ensuring we don't get NACKs on the SDA line, but surely the driver should be resilient enough to recover from a NACK on a particular I2C device?
I checked the code you posted above and I think I found what's causing you problems, or at least some info that can actually be of help. If you check this link you will find a table that explains the mapping for the Gen2 MUX, according to it you should select the value for gpio60 on LOW instead of HIGH and there's no need of unexporting it. You can check the link above there's a lot of info you can find of help there.
I too checked the information at that link and find that it is in error.
Looking at the schematic, on page 24 of 28, it's clear that to extend SCA and SCL to the Arduino header, GPIO60 (AMUXIN_1) has to be high.
What is also clear from my testing is that anything which causes data corruption on the SDA line, even briefly, renders the entire I2C system unusable until a cold-reboot.
I can understand that data corruption, say from shield which is slow to start up, or which is not initialized until some command is sent to it, could cause temporary faults on I2C, but then the system should recover from that once the fault condition is removed.
Also, I know there is no need to un-export the GPIO, but it is cleaner to do so, and the errors occur before then anyway!
Sorry, my mistake - I checked the datasheet for TS5A23159 chip and found that you are correct, no need to drive the GPIO high, just LOW.
The rest still applies though!
What I have here is an experimental audio processor board. (See picture below of it sitting on top of Galileo GEN2).
It has 4 channels of Audio input (2 x Stereo Phone, 2 x Stereo 3.5mm Jack), and 1 x Stereo 20+20W Class D Amp speaker output.
It has an OLED Display, Serial TX/RX at true RS232 level, separate RS485, and a DAB Radio header for a Venice-9 Module.
It works really well (despite the wrong PCB footprint for the TDA7440D, which I had to hand-solder with enamel wire).
However it is still in development, and occasionally I send a wrong command on I2C, or I short the SDA line with my oscilloscope probe, or when attaching/removing the logic analyzer.
It's a pain that when this happens I have to cold-reboot the Galileo! That makes for a long day :-)
I also have an experimental FPGA board, which is a proof of concept, running quadrature encoders, IR Receivers, One wire temperature and humidity sensors, 1-Wire iButtons and an OLED display all in hardware, just to show what can be done with a low cost FPGA on top of Galileo.
I am a great fan of Galileo, GEN1 and GEN2 and am using them in my work towards my Masters Degree, as well as my day job.
Thanks for everything, the support here is great!
I think you're right, what's happening to you is the known issue you pointed out, and the only workaround is to cold reset the board. The only solution is to wait until it get fixed on a future software release but there's no ATA for it.
That's no big deal, it's a small price to pay!
I still like the Galileo board a great deal.
Also, thanks for your time looking at this.