Slow i2cdetect on one Pi 3 board only!

[jpers]

Hello,

I have the following problem: I found out that PiFace RTC addon did not work on one of the Raspberry Pi 3 boards we are preparing for a client. I used i2cdetect to scan I2c bus, and the scan is very slow (about one second per address, maybe slightly faster). It did not find the RTC.

However, even when I removed the RTC, the search was slow. Then I changed the Raspberry Pi 3 board, and presto, the search finished instantly (and found RTC unless the contact between pins and addon board was poor).

I went further, and tested Raspberry Pi 1, and again, search is lighting fast. I use the same SD card for all of them, so all settings are the same for all tests.

So, my questions:

• Is it normal that i2cdetect works so slowly? I found the answer elsewhere that it is indeed possible up to 500ms, if it goes through all the combinations of communication speeds...
• I am puzzled why difference between boards, even if the same SD card is used. Are there any settings that get permanently stored inside SoC registers even if the device is shut down and disconnected, so would it be possible that I2c registers on one board are set in a way that makes problems? How do I reset the SoC if this is the case?
• Is it possible that the board where search is slow is somehow damaged?

Regards,
Janez.

[DougieLawson]

i2cdetect isn't very sophisticated, it fires a I2C command to the interface for each possible address and waits for the reply. So if you have a hardware or kernel driver problem where the I2C bus isn't working then each command will wait for the timeout and that takes a long time.

[joan]

See http://raspberrypi.stackexchange.com/qu ... 15-seconds which I guess is the same problem. I don't remember seeing a viable reason for the problem.

[jpers]

i2cdetect isn't very sophisticated, it fires a I2C command to the interface for each possible address and waits for the reply. So if you have a hardware or kernel driver problem where the I2C bus isn't working then each command will wait for the timeout and that takes a long time.

Well, since the driver is exactly the same (same sdcard) then this seems to confirm my suspicions that the board itself is defect. Thanks.

I just wanted to make sure there are no hardware registers which would survive cold reboot (can anyone else confirm that?)

[DougieLawson]

There's no non-volatile RAM on your RPi. Pull the power and it instantly forgets everything. The only long term storage is the SDCard (or a USB device).

[jpers]

See http://raspberrypi.stackexchange.com/qu ... 15-seconds which I guess is the same problem. I don't remember seeing a viable reason for the problem.

Yes, I am aware of that post, but I confirmed that the same software behaves differently on two different boards (which the above thread did not address).

Given that I boot the same image on two different Rpi 3s, and that it is confirmed that there is no non-volatile memory on the board itself, the only conclusion is hardware defect.

Thank you everyone for helping out.

Janez.

[SteveA]

I had the same problem and it plagued me for many weeks. This is what I found and did to cure it:

Sometimes "sudo i2cdetect -y 1" was really slow and it took two or more seconds to test each address. This indicates that the I2C bus has got corrupted, held down or the drivers corrupted.

I tried different RPI3 boards and the effect was the same. It was therefore not a hardware fault.

The only way to clear the bus or drivers was to reboot but that wasted too much time and so I used the following sequence of commands:

sudo rmmod i2c_bcm2708
sudo rmmod i2c_dev
sudo modprobe i2c_dev
sudo modprobe i2c_bcm2708

Incidentally I created an alias called 'ireset' consisting of the above sequence as I hate typing and saved it in the ~/.bash_aliases file:
alias ireset="sudo rmmod i2c_bcm2708
sudo rmmod i2c_dev
sudo modprobe i2c_dev
sudo modprobe i2c_bcm2708"

I found that the fault was in (my) C code software whereby I accessed one or both of I2C bus lines (SDA/SCL), which are on the 40-W GPIO connector:

SDA = GPIO P3 = RPI_V2_GPIO_P1_03
SCL = GPIO P5 = RPI_V2_GPIO_P1_05

Once these ports have been 'touched' they may be changed from the ALT0 mode (I2C bus mode) to general purpose I/O mode and that will then prevent I2C routines (RTC, DAC, ADC, etc) from working.

The cure is to change those pins back to ALT0 mode. If using the bcm library, simply do a call to this function:
bcm2835_i2c_begin() // Set ALT0 mode for I2C SDA/SCL i/o, returns 1=OK

There will probably be other calls in other languages.

I hope this helps and saves someone from sleepless nights.

Steve

[DougieLawson]

You shouldn't need to muck about with removing and reloading i2c_bcm2708 as that's loaded by the kernel/device tree when you've got

Code: Select all

dtparam=i2c_arm=on

or

Code: Select all

dtparam=i2c=on

in /boot/config.txt

[SteveA]

Of course you don't need to 'muck' about with what the kernel handles in normal times. Perhaps I did not make it clear that it was a method to get going again to be able to reset and continue with pinpointing the cause of the issue - as I said it was easier than repetively rebooting whilst chasing the fault.

Once the fault was located, you would not unload and reload. I should have spelled that out better