[ARM] I2C Communication Issue

[yolco]

Hi,

after having designed some custom PCBs, a main one with an ARM MCU and other peripheral boards.But there is one issue when peripheral boards are plugged into the main one.

Please, let me introduce the issue and the tests I have done, in order to someone can help me to understand and figure out what is the root cause of the failure.

Main board is sourced by a Li-Ion battery, and it also has an USB connector to power the electronics and charge the battery; voltage from USB is converted to 3V3 with a LDO (@600mA). This LDO also supplies to peripheral boards.

- MCU's maximum current consumption is 250mA.
- Peripheral board's maximum current consumption is <100mA.

LDO can deliver enough current to main and peripheral boards if it is needed.

- Communication between boards, I2C protocol.
- Communication between main board and PC, serial port.

The issue comes when peripheral board is plugged into main board directly.

If the peripheral board pins are completely inside the main board sockets, there is no communication between boards, I2C fails. But main board continues communicating with PC through serial port without any inconvenience, or being programmed through JTAG.

Test1:

To enable communication between boards, peripheral board has to be semi-connected by its pins, at left side (please, see picture1 attached).



This left side has only power pins and interruption pins. Interruption pins are not used during the test. They are set, by the MCU, as pull-ups to avoid floating points, and disabled from the different sensors. So, these pins should not drain current.

Test2:

To check the behaviour of the peripheral boards, I have soldered wires to the pins of the peripheral boards, so I can connect them to other commercial boards, as arduino. They work fine.

But the surprise appears when peripheral board is connected through wires to the main board, it works! (picture2 attached).



There is no issue with this configuration, even with all the interruption pins connected.

Question:

Which could be the root cause of this failure? How can I figure out what is happening here?

Assumptions:

At first time, I thought about power consumption issue, but even theoretical calculations were wrong, and sensors drain such amount of current, main board's serial port should not work neither.

Maybe, floating points due to interruption pins, but this should be fixed with IO's pull-up configurations. Moreover, it must be reproduced with the wire connection.

* I would provide more info if there is something not clear enough.

Hoping someone can help me.

KR!

 

[sreepss]

Have you provide the Pull-Ups for the I2C line? it plays very good role in the I2C line. And next is Decoupling Capacitors. Pls check these points

 

[hobbyckts]

My understanding of your problem is the peripheral board is working when it is connected with the wires to the main board and it's not working when the peripheral board is connected directly with the main board with the connectors.

Is that correct?

If that is the case then could you calrify me on following thing:
Are you using the exact mating connectors on the boards? If not then please use the exact one.

 

[yolco]

Hi,

@sreepss, I2C lines have 10k pull-up resistors. 10k value is the proposal from the components datasheets. Both board have decoupling caps into their ICs, do you think I should add some caps more?

@hobbyckts, yes, you are right. That is the way that is working now. And if boards are directly connected, only if some pins are a little bit separated.

I have selected mating connectors:

• Female/Socket: Gradconn BD02 family
• Male/Header: Gradconn BB02 family

And just in case a supply chain issue or stock from manufacturers, I have shared with my manufacturing house (PCB) a list with alternative compatible components.
Maybe, it could be the pins length, but if this was the problem, it should work with a little separation between the pin's edge and the socket's ground, in every pin. But, it works when interrupt pins are separated.


KR!

 

[pic.programmer]

Add a lille delay after I2C initialization.

 

[KlausST]

Hi,

i think it is a conduction problem.
The connector seems not to be of high quality.

if there is a failure in contact you will see this with a scope.
Just push the board in like it should be start the I2C activity and measure pin by pin on both sides of the connector.

To compare the results you could do the same with partly inserted board.

Klaus

 

[hobbyckts]

I guess it should be problem with length of the pins means conductivity. If possible just change the Plug connector which is having the lengthier pins in order to make it contact perfectly.

 

[yolco]

I will comment with the 'scope tests as soon as fix some IDE issues.

 

[yolco]

======================= EDIT ==========================

Finally, I can return to my project and continue working on this issue.

I have cut a bit one peripheral board's pins to reduce their length. This does not fix the issue, but reduces the fastening between boards.

In order to make the boards work, I have to reproduce the original way of semi-connect one of the peripheral board connectors. Now, it is true that is more easy to make device work.

I can not remain on cutting the pins because the length is less than 2mm, without knowing if this is the real root cause.

Furthermore, I have analyse this behaviour with an oscilloscope. Please, find below the results.

- Right Behaviour:









- Wrong Behaviour:









At wrong messages, it can be observed how SCK is level-up all time (3V3), and SDA try to send some data.

Any hint about it, please?

 

[FvM]

Don't understand what you want to show with the I2C waveforms.

There are snippets of apparently correct communication and obviously faulty with SCK staying high. But what did
you change between both cases? If you didn't change the hardware, a code error should be expected.

 

[KlausST]

Hi,

On one picture i see 19 clock_low states in an almist equal frame.
I wonder why 19.
And i wonder why one does not recognize the ACK cycles and the start of a new byte.

Is this a software I2C implementation?

Klaus

 

[yolco]

Hi,

- @FvM, hardware is the same, the only modification is the "connection's depth".

- @KlausST, the I2C implementation is done by the MCU manufacturer, I suppose is checked and verified due to is distributed widely. My own firmware are the functions for read & write, maybe it is on my side the issue you mentioned.

I will check the resistivity of the pins, maybe the root cause is the connector's quality.

KR!

 

[FvM]

the only modification is the "connection's depth

Open or short circuit of SCL net?

 

[yolco]

Short circuit of SCL net..

I have measure its resisitivity on every pin, and:

• Entirely connected:
  • All pins except I2C ones: 0 ohm
  • SDA & SCK: 10.5 Mohm
• Partially connected:
  • All pins except I2C ones: 0 ohm
  • SDA & SCK: 20 kohm

Then I have checked all the datasheets from the connector I selected.

• Socket
  
  
• Header
  

As at datasheet is shown, the minimum length for right connection inside the socket is 2.5mm.

Then, the headers have an original length of 3mm. Now, I have cut them until ~1.8mm, and the issue is still happening.



So, working with pull-up of 10 kohm on I2C as datasheets suggest, my doubts are:

• Why has the resistance been modificated in such levels?
• Should the length of the header be modificated?