According to version 4 of the \$\mathrm{I^2C}\$ spec,
"Due to the variety of different technology devices (CMOS, NMOS, bipolar) that can be
connected to the I2C-bus, the levels of the logical ‘0’ (LOW) and ‘1’ (HIGH) are not fixed
and depend on the associated level of VDD. Input reference levels are set as 30 % and
70 % of VDD; VIL is 0.3VDD and VIH is 0.7VDD. See Figure 38, timing diagram. Some
legacy device input levels were fixed at VIL = 1.5 V and VIH = 3.0 V, but all new devices
require this 30 %/70 % specification. See Section 6 for electrical specifications." (page 9)
Deeper in the spec, you'll see that this \$ 0.7 \times V_{DD}\$ is the minimum logic high voltage:
For your 5V system:
\$ 0.7 \times 5 V = 3.5 V\$
\$ 0.3 \times 5 V = 1.5 V\$
To me, the 3.3 V pull-up looks marginal, especially if any of your 5V devices use the 'new' standard of \$ 0.7 \times V_{DD}\$ for logic HIGH.
Your mileage may vary, but it's always best to be within the spec wherever possible...
Problem:
I powered on board 1 [...] As soon as I plug the I2C connector to board 2 (it's still powered off), SCL and SDA get pulled low.
This is completely expected behaviour. You cannot connect both powered and unpowered devices to the same I2C bus, without additional precautions (or unless this is explicitly stated as being supported by that I2C device). In your case, board 2
may also misbehave afterwards as you are likely to be exceeding the maximum allowed voltage connected to an unpowered MCU pin on board 2
.
That is because you are effectively trying to power the MCU on (unpowered) board 2
via its I2C bus pins, which are receiving power through the pull-up resistors on (powered) board 1
.
Solution:
Use one of the various existing methods of I2C bus isolation between board 1
and board 2
.
Since you say that your setup allows you to connect the Gnd between the two boards, I don't see a requirement for the more expensive and complex galvanic isolation methods.
Instead the simple MOSFET-based circuit, often used as an I2C bus level-shifter from the old Philips (now NXP) AppNote AN97055 can be used. Using the simple circuit in section 2.3 of the datasheet, you connect board 2
to the VDD1 side of the circuit:
[Although not shown on the above circuit diagram, Gnd (0 V) must also be connected between the VDD1 and VDD2 sides.]
Using the above circuit, when the VDD1 (board 2
) side is unpowered, it also receives no power via the I2C bus signals, even when the other VDD2 (board 1
) side of the circuit is powered. Therefore it stops the problem explained above, as described in this excerpt from the Philips AppNote:
Various vendors sell I
2C level-shifter PCBs with this simple circuit using suitable MOSFETs, if you don't have them yourself. However, note that such PCBs often have pull-up resistors fitted. Since you already have pull-ups installed, you must remove any duplicate pull-up resistors from wherever is easiest (probably by removing them from the additional PCB).
Best Answer
Apparently the radio interference is messing up the IIC bus communication such that the slave doesn't think it is being addressed and there is no ACK. As Steven pointed out, it is bad software design to have a missed ACK cause the processor to reset. This needs to be fixed, but your question is mostly about the interference issue. You got lucky that the interference aggrevated another lurking bug in your code. Fix that while it is easily reproduced.
2 kΩ pullups on the IIC lines is about as low as you can go, so nothing more can be done there. You don't say what frequency and power level this radio is that is next to the board. Some level of closeness and power output is going to cause a failure. Put another way, there are only so many volts per meter your board can take before it operates incorrectly. The first thing you need to ask yourself is if the level of radiation hitting the board is reasonable to protect against. One solution could be "well, don't do that". Put the transmitter accross the room, shield it properly, move the antenna, etc.
If you do need to make the board less sensitive to this RF (again, it would be useful to know the frequency and power level you're dealing with), then there are probably various things to fix. Most likely this problem is due to bad layout, particularly the ground, and inattention to high frequency loop currents. All the same things you do to reduce emissions work symmetrically to reduce the susceptibility to received radiation. Put another way, physics tells us that anything that works as a transmitting antenna works as a receiving antenna and the other way around.
So show the layout, particularly the grounding strategy, of your board. Also look carefully at anything going off board because these are antennas. Since you are using a 18F97J60 which has a ethernet MAC/PHY, you probably have a ethernet cable coming from the board. What RF reduction is on the network side of the transformer? Does the transformer have a built in balun on the network side? Does the problem go away when you unplug the ethernet cable?