MPL3115A and the I2C protocol

[davepfaltzgraff]

I have used the MPL3115A on previous projects without any problems and with good success. Now I am trying to use it in a new project and am having problems.

The new project has several (7 or I2C devices and I want to probe the bus to verify address allocation. To do this, I send a START followed by the address and look for ACK/NAK. This is followed by a STOP. This works for all devices except the MPL3115A. When the STOP is issued, the MPL3115A does not release the bus. It's as though it must receive something more, but the I2C spec (as I recall) requires that devices release the bus on detecting a STOP sequence. At this point it is necessary to perform a full power cycle before further I2C operations. (Note: None of the other devices on the bus exhibit this behavior.)

Is this expected behavior for the MPPL3115A? If it is, what do I need to prevent it from going into this state?

Thanks

[davepfaltzgraff]

For the time being, your answer of the expected behavior is sufficient and the investigation continues. But, to answer your questions:

 - Could you please share your schematic? No, due to the proprietary nature of the project. The pull-up resistors on the bus have a parallel resistance of 1.62K

 - What is the communication speed?100Kbps

 - Is it possible to find out a capacitance load of the each device on the bus?The devices on the bus are  TI BQ34Z100-G1, 2 of NXP PCA9515A, AD ADXL343BCCZ, SiLabs Si7020, NXP MPL3115A, 3 of Atmel AT24CM01-SSHM, NXP PCF8574A and all are driven by Microchip PIC18LF46K22.

 - Could you please roughly measure the PCB traces lengths or cable lengths? Total trace length of both SDA and SCL line is 10.6" with a trace width pf 16 mils.

 - Could you please measure the SDA and SCL lines on the MPL3115A with an oscilloscope?The signals are very clean and fall well within the specified timing limits. Scope capture is difficult.

 - To see if the logic high reaches the VIH value and if the address, data, NACK bits are actually recognized by the MPL3115A. As stated above the signals are very clean through to the end of the ACK pulse. At that time something on the bus is pulling both lines low. That is the focus of the current investigation and I am waiting for some test equipment to be delivered. Remember that the issue is not the NAK bit but a failure to respond to the STOP sequence issued by the master device.

 - Also, what is the VDDIO value? All circuitry is operated at 3.3V

Will post more once the investigation yields something useful. Thanks.

[JozefKozon]

Dear David,

according to the datasheet Figure 5. before the stop bit the MPL3115A requires an NACK bit. 

But if you are using the same code as before and it was working, the possibility is that the bus load is too high for the MPL3115A. Could you please test to remove all the devices except the MCU and the MPL3115A and test it, if the MPL3115A releases the bus after the stop bit. We have an AN4481 Sensor I2C Setup and FAQ, with some example codes. Please find it attached.

With Best Regards,

Jozef

[davepfaltzgraff]

OK. I've made some progress. I found that I was enabling the PCA9515A at the wrong time causing a lockup on the I2C bus.

However, changing that time has not completely solved the issue. Now, after enabling the PCA9515A, the next I2C transaction causes a hang regardless of the I2C address.

At the present time, the "other" side of the PCA9515A has nothing more than a 4.75K pull-up and about an inch of track.

Is there a minimum loading requirement for the PCA9515A? (Like there is for the PCA9512.)

[JozefKozon]

Dear David,

I would recommend you to increase the parallel resistance of the I2C on the MPL3115A2 to at least 3kOhm each. For the communication speed of 100kbps and for the worse case of 400pF bus capacitance, I have calculated the pull-ups Rp(max)=tr/(0.8473*Cb=1000ns/(0.8473*400pF)=2.95kOhm, but the estimated bus capacitance should be much lower. The MPL3115A2 Cb=20pF + PCB trace Cb and the PCA9515A Cb=6pF typically + PCB trace Cb. I presume you have not enabled the other devices when communicating with the MPL3115A2 (I2C lines of the other devices should be in high-impedance state?). 

So for an estimated bus capacitance Cb=100pF, I have calculated  Rp(max)=tr/(0.8473*Cb=1000ns/(0.8473*100pF)=11.8kOhm.

Please also check the other parallel pull-up resistances and please check how many devices are connected to the I2C lines when communicating with the MPL3115A2

The schematic would be helpful, but I understand its confidential. 

Is there a minimum loading requirement for the PCA9515A?

[A] No, there isn't. Lower the load, the better. There is higher pull-up resistors reserve. The Rp(min) is not depended on the bus capacitance and with lower bus capacitance Rp(max) can be higher.

With Best Regards,

Jozef

[davepfaltzgraff · Accepted solution]

Thank you Jozef for your patient and detailed reply. It encouraged me to go back and examine what was happening after I made the previous changes.

I discovered that I had laid out the board for the wrong part! I had used the bus pin-out from the PCA9511/13/14 series and then installed the PCA9515A.

I will be correcting this with the correct parts and don't anticipate any further problems.

As a note on the probing of the I2C bus, I changed the program to perform a full read of one byte instead of just issuing a STOP on the address. The MPL3115A appears to be responding correctly. I have opened an issue with Microchip as to how their program can report a NAK to an address and thus get a cleaner program.

Thanks again for all your help.

[JozefKozon]

Dear David,

you are very welcome. I hope it will help you to solve the communication issue.

With Best Regards,

Jozef

[davepfaltzgraff]

You misunderstood the situation. This is not for a normal transfer of data. The use of the ACK/NAK in that situation is well understood.

In this case, the I2C master is issuing an address to test for the ACK saying that the device is there. At that time, the STOP is issued to free up the bus.

I am trying to mimic the function of https://linux.die.net/man/8/i2cdetect but within a PIC18F processor.

When there are 9 I2C devices on the board it is easier to remove the MPL3115A and see if the problem disappears!

So, back to the original question: What is the expected behavior of the MPL3115A when a STOP condition is seen at the end of the address?

[JozefKozon]

Dear David,

What is the expected behavior of the MPL3115A when a STOP condition is seen at the end of the address?

The expected behavior of the MPL3115A after the stop bit on the SDA and SCL is to release the bus. SDA and SCL should be high.

I would like to check the pull-up resistors on the SDA and SCL lines. Could you please share your schematic? What is the communication speed? Is it possible to find out a capacitance load of the each device on the bus? It should be in each datasheet. Could you please roughly measure the PCB traces lengths or cable lengths? I would like to estimate the bus capacity. Possibly you will need to use an I2C repeater. 

Could you please measure the SDA and SCL lines on the MPL3115A with an oscilloscope? To see if the logic high reaches the VIH value and if the address, data, NACK bits are actually recognized by the MPL3115A. Also, what is the VDDIO value? 

With Best Regards,

Jozef