2
\$\begingroup\$

Hello I am trying to communicate that is using SMBus. So when I try to send a data which was 0x0D and address of the device was 0x16. I see something like that on the data line:

SDA

And this is how my clock (SCL) pin looks like:

SCL

So my questions are :

  1. Is this data and clock signals look normal? I know data is not normal because I cannot transmit the message but what about clock signal?
  2. So Data looks like 1 1 1 1 1 1 .... 1 1, is it because I cannot ack ACK/NACK from slave, it keep sending the data over and over again? Or maybe something else behind this strange data signal.
  3. I used 20 K pull up resistors for SDA and SCL for 5 V Vdd. (For SMBus I think I should have used 15 k ohm.) Can it be the reason? Or any other ideas that causes this? Thanks beforehand

In the datasheet of the battery that I try to communicate, it says:

For pull up resistors

So I thought I could use 20 k ohm as pull up resistors.(to be honest I could not really understand what they say in the document..)

And this is how SCL/SDA signals look like together

SCL/SDA signal

This is the circuit schematic (I use RB1 and RB2 for SMBus communication.)

Schematic

This is the pin diagram for the battery. I am communicating with the first section, PINS 1-4:

PINOUT

\$\endgroup\$
  • \$\begingroup\$ That doesn't look like a normal clock signal or data signal, but I have no idea what could be causing it. \$\endgroup\$ – Hearth Apr 4 at 12:36
  • \$\begingroup\$ That does not look normal to me, what frequency are you trying to run? \$\endgroup\$ – r_ahlskog Apr 4 at 12:37
  • \$\begingroup\$ What devices are trying to communicate (part numbers)? \$\endgroup\$ – Peter Smith Apr 4 at 12:38
  • 2
    \$\begingroup\$ Use 2 inputs on your 'scope. SCL on one, SDA on the other. Zoom in to just 1 or 2 clock pulses so we can see how SDA & SCL relate to each other. \$\endgroup\$ – brhans Apr 4 at 13:06
  • 2
    \$\begingroup\$ Yes, that's what I was looking for. But it looks so strange (for an I2C bus) that it's not much help in diagnosing the problem ... I suspect that there's something wrong with the way you're configuring or controlling the I2C peripheral port in your PIC. \$\endgroup\$ – brhans Apr 4 at 13:32
1
\$\begingroup\$

The I2C bus actually requires not 2 wires, but 3: SCL, SDA, and ground. It's usually just assumed because I2C is intended for communication on the same board. If you are really only connecting SCL and SDA from your PIC to your battery, and there is no common ground connection between them, you might see something like this.

The ground from your PIC should be connected to the ground of the battery monitoring circuit. It is not necessarily the actual battery ground itself; they may provide a separate ground pin intended for communication. What is the pinout of your smart battery?

\$\endgroup\$
  • \$\begingroup\$ It is something like this, and I only connected Clock (PINS 1-4) & Data ( PINS 1-4). So I am adding the picture to the main post \$\endgroup\$ – Günkut Ağabeyoğlu Apr 5 at 13:26
2
\$\begingroup\$

Neither waveform looks at all normal for an SMBus transmission. In an ideal situation of transmitting the clock waveform during the transaction period should have an approximate 50% duty cycle.

I doubt that the pullup resistors are the issue but I would like to comment that trying to use resistors in the 15K to 20K range is very non conventional. Real world SMBus applications use pullup resistors in the range of 2.2K to 4.7K.

It will be hard to suggest further debug steps because I do not know how you are generating your traffic (SMBus IP block or bit-banged). Also unknown are factors such as MCU pin connections, pin configurations, any applied drivers or even level translators.

\$\endgroup\$
  • \$\begingroup\$ In the datasheet of the battery that I try to communicate it says something like that: ah so I cannot put an image to here, I will add it to my post. \$\endgroup\$ – Günkut Ağabeyoğlu Apr 4 at 12:48
1
\$\begingroup\$

I was trying to cross reference your picture to some captures I have saved to judge the timebase and how it should look.

I think what is happening at 100us/div is that you are seeing repeated starts that don't get ack. Also your rise time seems horrible, try smaller pullups.

Here is a capture at 50us and I would imagine 100us becoming pretty poor res but still being able to show the 50% duty on clock.

capture Also don't mind the 66.7kHz frequency measurement, it doesn't calculate things right on a capture like this, the bus was 100kHz.

\$\endgroup\$
  • \$\begingroup\$ So it was keep sending these data because I could not get ack right? But it does not look like my data that I try to send nor address value of slave \$\endgroup\$ – Günkut Ağabeyoğlu Apr 4 at 12:51
  • \$\begingroup\$ Yeah i would like to see an address in that there. How is the master implemented, could it be a bug? My capture is from when I chased a bus error that I thought was electrical but turned out to be a master that was poorly implemented and sometimes sent garbage. \$\endgroup\$ – r_ahlskog Apr 4 at 12:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.