I have a custom PCB, it has a 2560 and two 328P on it, connected via i2c for some variables to be sent between chips.
There is a single set of 4.7k pullups on the line.
The 2560 is sending and requesting data to and from the two 328p which do not use a
Wire.beginTransmission(2);
I have two voltage regulators on the PCB which are enabled from the 2560, th eplan being that I could reset the 328p in the event that they were not responding.
In short, the moment I try to begin transmission with a chip unpowered, the code on the 2560 blocks. Sometimes it resumes when power is restored, sometimes not.
Ive tried to write to a non existant device on the bus and it doesnt do it. So it seems to be the power issue causing it.
Ive added 4.7k pullups on another of the 328p to see if that helps, doesnt make any difference.
Is there a FOR or WHILE loop somewhere in the i2c library that isnt completing?
Does anyone know what is causing this and how to cure it? I have had a look in the forums and saw that someone claims success adding the pullups to each chip. In my case this wasnt successful
So you have an I2C bus with unpowered devices on it ?
If the power to the devices (328Ps) is controlled by the 2560, why are you trying to use the I2C bus when you know there are un-powered devices on it ?
The theory is not to have that happen. Yes in testing I have an unpowered device. However the plan is to only reset the device if needed, and in which case I can certainly not poll it for data until its back up...
However, if that 328 goes down, I refer to damaged in some way. Power regulator goes bad. Then I face the total hanging of the 2560. And that cannot be allowed to happen.
the ever-useful Nick Gammon is bringing up some results on how to fix it. It seems there is a circustance that can cause the wire.h library to loop until the circumstance is removed.
I2C is designed for on-board connections, where all devices share the same power supply. With detached devices you only can make sure that on power loss the bus is definitely released and the controller shut down. On power restore make the controller reset and connect to the bus again.
The timeout mentioned here, when set to 3000 has stopped the code from locking, so at least the serial debugging and heartbeating LED are functional. The bus crashes and doesnt recover though.
so if i revise the PCB in the future, a couple of transistors on a Digital IO which would by default disconnect the bus when the code isnt running on the chip would solve this issue ?
for now the timeout has meant that I only lose a few seconds of comms when removing power from one chip. This is acceptable.