Enrico, can you check that clock signal, and maybe use a higher resolution?

The capture below (for another ic) has a pattern that I'd expect, with a train of clock ticks generated by the master. It has a rhythm in it. I don't find that back on your captures.

You have used J1-09 and J1-11 for SDA  and SCL?

(and how do you tell that the i2ctools use i2c #1, not i2c #0 ?  - what does this linux command return: ls /dev/*i2c* ?)

Would it be an idea to test such things on an "easier" piece of hardware, just a normal raspberry pi 3?

(I was already half-typing: but it needs to be P1-3 and P1-5, but that's on a normal raspberry...)

Hi Jan, as I wrote in the original post,

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.

Your consideration is correct but there was no mistake. I have used the I2C 1 while 0 - in the Compute Module it is not reserved for the HAT but is anyway for internal usage - is not manage by default. The pins on the GPIO board connector for CM are 2 & 3 instead of 9 & 11 on the Pi3 boards...

Now: All your efforts and suggestions were correct. You addressed me avoiding a lot of extra tests and confirmed that most of my settings was anyway correct. So, what is the point?

Eliminated the impossible, what remains, unlikely to be, must be the truth.

So, as UPS shipped me a second board I replaced it and just connected. And it worked like a charm!

So the road test Compute Module I/O board has some issue like a bad soldering or something incredibly small and invisible generating this problem.

Instead, despite what the documentation says the Raspberry Pi Compute Module 3 has not the I2C 1.8K pull up resistors enabled by default.

Enrico

Hi Roger, I have anyway understood what you was mentioning.

I forget to mention that obviously the same is working with the Pi3 board counter parts. But... Read the last post The problem was solved replacing the CM3 I/O board.

Enrico

I agree with Jan, the pictures arent representative of an I2C clock.

The video however does show an expected clock pattern whenever you run i2cdetect. The problem here is that in the video there is already some activity on that bus even when theres not any expected activity so the clock pattern in the video is just overlaying onto an existing signal. The activity that seems always present isn't expected for an i2c bus and this is interfering with the I2C clock and data that you are sending out.

I notice that you have another peripheral either a camera or display connected to the board (im guessing because you have the link wires from one of the jumper headers to the other). Do you have drivers installed for a peripheral like another camera or display but just dont have that connected. In that case, those drivers will be utilizing that I2C bus already with their own signals.

---------------

edit

Ive just noticed that you solved this problem by buying a new board. Did you also start with a fresh re-install?

Looking once more at the original video you posted, something else is definitely using that bus. I would say a driver for a peripheral that isnt connected.

Hi Lucie,

the problem has been solved at least for the side I can interact. Confirmed that there is no internal pull-up enabled on the bus adding the external resistors it worked.

I agree with you that the bus has something that should not exist, But there is. That is weird and not easy to explain.

Then the I/O board was the real issue - at least one of the real issues. There is a second that I have discovered just now; to make tests with the several versions of the Jessie and strech debian desktop I have prepared three different microSD cards and booted the Compute Module 3 Lite (without the eMMC) that worked fine. Now I have replaced again the origina CM3 (on the new board) and I get always the same issue, nothing is recognised at all. So it seems that the problem is on both the I/O board and the processor. As now I have two CM3 I will install again a fresh install on the other CM3 boards and see what happens.

At the actual date the only configuration working is with the CM3 lite that boots from the microSD. Not the one booting from them eMMC. I have also re-estalblished the peripherals connected as in the original configuration (camera, lcd and serial, USB with keyboard, mouse and SSD) an all works fine anyway.

Now I will check with another fresh CM3 installation with the headless raspbian distro dated july 2017 (the last released before the strech).

Enrico

Update (to be definitely verified). I have set the Raspbian (same distro, full version) jessie on the SD card and CM3 Lite. Setup the board with the following peripherals (not all but almost the base)

• USB: SSD + Keyboard + Mouse + WiFi
• Pi Camera V2
• 7" display
• Serial PTHat controller
• HDMI (connected but not shown when the display is on)
• Digilent I2C capsense buttons

All work perfectly! And the i2cdetect find the capacitive device immediately. Only with the CM3 Lite boot from 8Gb microSD. Not when boot on the other CM3 + eMMC

Next step is trying a different CM3 + eMMC

Enrico

have you loaded the drivers on for the lcd?

Yes Luvie, as you can see in the picture it is up and running (showing i2c detected address)

Enrico