Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
Raspberry Pi Wishlist
Actions
Forum Thread Details
  • Replies 39 replies
  • Subscribers 651 subscribers
  • Views 7296 views
  • Users 0 members are here
Related

Weird I2C Issue with Pi CM3 [SOLVED]

balearicdynamics

This is a strange issue I have no idea how to solve; it seems I am unable to debug correctly the problem to find at least what class of issue it is.

 

I have tried several I2C devices set as slave including Infineon XMC1100 Boot KitXMC1100 Boot Kit and Arduino UNOArduino UNO. Then I moved to the simple two cap sense buttons PmodCDC1PmodCDC1 by Digilent; as the device is powered and connected to the I2C bus it starts in continue sending data. I should expect to see at least its address will be detected by the CM3 I/O board but nothing happens.

image

I2C has been set and enable correctly in /boot/config.txt and the raspbian version running on the eMMC of the CM3CM3 is the latest Jessie (July, 5 , 2017). Signals are connected to the GPIO2 and GPIO3 (SDA1, SCL1) accordingly with the eLinux table specifications (see in attach) to the GPIO Pins 2 and 3. Digilent device is powered with the 3V3 and voltage is correct and stable.

I have not used external pull-up resistors on SDA/SCL signals as the CM3 already includes 1.8K pull-up resistors on these two lines, following the CM3 peripheral recommendations.

imageimage

Initially I though that it was possible that wrong resistor values was blocking the signals to go up but as shown in the video below, hardware seems working fine. Note that when I send a i2cdetect -y 1 command from the terminal data are sent by the CM3 side. But nothing is shown.

Any suggestion is welcome.

 

 

Update

Supposing that despite what the documentation says the internal pull-up resistor is not enabled I have added a 1.5K resistor pulled up to the 3V3 (the nearest I have at home respect the declared in the documentation (1K8). What I get with the protocol analyser is a series of packets as shown in the images below but always nothing is detected by the master (Pi side).

image

image

image

image

 

Last update

After trying and discussing with all the helpful members that spent time with me I have received in the meantime a second Pi Compute Module IO board and as all the suggested tests and possible mistakes was converging to the right setup for the I2C protocol, as expected, the problem was for  some unknown reason the board itself. As I replaced the board with a new one things started working perfectly.

 

Thanks to and... for the useless suggestion of the thread image LoL

 

Update

After the last testing and following some suggestions of the starting supposition is that - together with the I/O board - also the Compute Module 3 booting from the eMMC maybe with some hardware failure as all the tests with the Compute Module 3 Lite booting from the eMMC is working fine with the same Raspbian distribution, desktop version (instead of headless like on the eMMC side).

 

First test: a new microSD with the Raspbian Jessie Lite has been set and after booting the Compute Module 3 Lite I have done the same setup of the Compute Module eMMC. At this point bot boards runs the same version. And after sudo update / upgrade the command i2cdetect -y 1 works perfectly! So we can think 90% sure that the issue is in the Compute Module 3 with eMMC memory. Remain a last test to see if this issue is systematic or not: flashing another Compute Module 3 eMMC and see if it work.

 

Update - Conclusion

After doing the test mentioned in the update above a new Compute Module 3 eMMC board has been setup with a fresh installation and with the same connections of the previous settings, same Jessie Lite July 2017 and I2C protocol worked immediately without problems. So, the main issue was the CM3 eMMC board and the I/O board kit.

image

 

XMC1100 Boot Kit + TLE94112LE I2C communication

The setup of the two boards (XMC1100 + TLE94112LE) connected to the CM3 via the I2C bus was creating a trouble on the bus signals so that the i2cdetect -y 1 command was no longer able to recognise any connected peripheral.

The board has been configured as slave on the address 0x04. A check with the same software and the same hardware setup using and Arduino UNO instead was working fine. Investigating on this issue I have found the problem was already known involving Wire library version for the XMC1100 board updated by on the Infineon XMC1100 GitHub repository, the Pull Request #13.

On Aug, 31, 2017 Manuel (thanks) completed the update of the pull request, merged in the main and released a new XMC1100 Arduino board core  library version 1.0.4 (the module downloadable / upgradable in the Board Manager of the Arduino IDE) and all worked fine with the Infineon board alone connected to the I2C bus.

 

As I have integrated the XMC1100 Boot Kit board with the TLE94112LE DC Motor controller I have included the the TLE94112 Arduino library in the sketch detecting another non-blocking issue in the I2C Wire library (XMC1100 version) and opened the issue #14

The behaviour details are explained in the issue note; the problem can be easily avoided initialising the Wire library as the last call in the Setup() method of the sketch ;twe can consider this the workaround to the problem until it is not definitely solved.

Attachments:
imageRPi BCM2835 GPIOs - eLinux.pdf
imageRPI-CMIO-V3_0-SCHEMATIC.pdf
  • in reply to Robert Peter Oakes

    Hi Peter, thank you for the suggestions. Making the state of the problem at the moment, I know

     

    • Pi CM3 has not the internal pull-up (1K8) resistor set by default as instead mentioned everywhere in the documentation.
    • I have tried to be 100% sure with high resistors value and - as you say - 1K - 10K, best is 1.5K - pull up resistors are ok. With this last value the signals are always in synch as far as I know
    • Using this small device the entire bus operates at 3V3 so there is no problem (if it was possible to be) of different values with the Arduino connection (operating at 5V). It's true that it is the master voltage that makes the roles but this behaviour is unexpected so it is better that there are no extra potential influencing parameters.
    • Distance is about 20 cm between the two peripherals and if it was just a problem of distance changing the reange of resistors I had to see synched signals with a different value, nothing else, I suppose.

     

    (BTW, you mean trigger levels of the scope?)

     

    The system running the software now it is the last Jessie, July 2017. Do you think that it is the worth to try with the previous - last stable - jessie version?

    Few days ago they released the stretch raspbian, August 2017. Is it the case I test it too?

    How much do you think maybe influencing the software with the correct managing and decoding of the protocol communication respect some wrong hardware setting?

    Maybe the I/O board (hosting the compute module) the problem?

     

    Enrico

  • in reply to Robert Peter Oakes

    Peter Oakes wrote:

     

    ....  open collector type bus (Open Source in the case of a FET ),

    No it's the DRAIN that is open. It's called Open Drain. So sorry the pun doesn't work.... :-)

  • in reply to rew

    Correct, Roger. But in this moment the correct terminology is something I don't care too much image

     

    Enrico

  • Isn't it strange that the digilent component starts sending data as soon as it's connected? It should be the RPi as master that gives the clock and send the first contact. And then keeps sending the clock as long as it wants to read?

     

    is the digilent kit an i2c master?

  • in reply to Jan Cumps

    I've just read the datasheet of the pmod.

    It will constantly sample, but only send data when you send the right commands over i2c

    It should never decide to use the I2C bus on it's own will, without being asked by the master.

     

    It's i2c address (7-bit) is 0x48.

    depending on your i2c driver, You'll have to use either 0x48 and tell it you either want to send or receive data,

    or use 0x90 for reading and 0x91 for writing.

     

    If your i2c detection tool doesn't return anything, there's something is off. Does that same RPi board detect other i2c ICs when you attach them?

  • in reply to Jan Cumps

    Hi Jan,

     

    It will constantly sample, but only send data when you send the right commands over i2c

    It should never decide to use the I2C bus on it's own will, without being asked by the master.

     

    Yes, I wrote not so correct yesterday night. I meant that after testing with other I2C devices (set all as slave) I have decided to use this as it is simple and it is by default in send mode as it starts. Then sure until the master does not send a request, nothing is expected to happen. But when I send i2cdetect something should.

     

    What I am doing now: three things. First I flashing another Compute Module 3 board with the previous version of Jessie (not the last from June, 2017) and another with the last raspbian scratch one. Both with SD card and Compute Module 3 Lite. Then I will see; if the behaviour is always the same the software problems including the linux distro can be excluded. Then I will see what happens.

     

    If your i2c detection tool doesn't return anything, there's something is off

     

    I have the same suspect but what I can't imagine is what can be.

     

    Enrico

  • in reply to balearicdynamics

    Jan is correct that there are two ways of writing the I2C address. The "i2ctools" of which i2c-detect is a part, will use the first method: 0x48. So you should expect to see somethign on address 0x48.

  • in reply to rew

    I know Roger, and it is the minimal basic expectation I have, to discover the slaves connected to the bus when I launch the command.

  • in reply to balearicdynamics

    I haven't had the time to go through the "too many" steps to look at your traces. But from the fact that there ARE traces, you're well equipped to find the problem. (click on image: still too small to see, then enlarge, and still to small (scaled down) then open image in new tab, then click to enlarge. THEN I can read what is going on.)

     

    When you just connect things, I expect the bus to be idle. Doublecheck that.


    When you run a scan, you should see a single byte being transferred, and when i2c-decoding is on you should see something like READ FROM 0x08 NAK  This is the host sending 0x11 (read + address =0x08) and nobody acknowledging the request.

     

    So, start the logic analyser, run the i2cdetect, and look for the 0x91, the probe at 0x48. Check to see if you can find the ack/nak. And/or enlarge that portion and post the screenshot.

  • in reply to rew

    it also seems that the clock signal looks more like a data signal. That's not how I expect an i2c clock to look like. It may be because of sample rate, or because it's not the i2c clock ?