I have several i2c devices (MCP23017s) connected to i2c1 over a bus that can be up to 25 feet long. I've used the TI P82B715 extender to accomplish this, so the local side bus is only an inch or so on each PCB. The whole system is powered by a single 12v bus, with a local 5 and 3.3v supply on each PCB. The RPi is powered by a 3.5A buck mode DC-DC converter. The remotes are very low current and powered by a linear regulator (5v) and a zener (3.3v). We've been building these systems for nearly a year without issue, until we changed to the new 3.5A DC-DC. The old one was 1.5A and would occasionally drop out on the RPi3 (worked fine on the RPi2).
The whole thing usually works, but on some PCB builds it fails.
The problem is, it takes a few hundred ms for the all the chips on the i2c bus to power up and allow SDA and SCL to pull high. I'm not familiar enough with the recording functions on my oscilloscope to know for sure, but probably in the 200-500ms range. By that point the RPi has decided not to boot. Problem first occurred with old-ish firmware from mid-August 2016. I updated it to today's git to see if it would fix the problem, with no luck.
If I plug in the I2C bus as quickly as possible after applying power (< 2 seconds) it all boots up fine. The app and the i2c bus works perfectly. In another test, I removed the board from the top of the RPi (resembles a HAT, and powers the RPi). I powered the system up, then carefully pushed the powered interface board on to the GPIO header, powering up the RPi after everything else has come up. On this particular test setup, we're only dealing with about 8 feet of i2c bus. I also tried shorting GPIO3 to ground with no i2c connected, and get the same failed boot.
In my search I've seen a lot of mentions to GPIO3 being used as a reset (after halt), and to enter the now-defunct safe mode. I've added avoid_safe_mode anyway. I also changed the original boot_delay from 0 to 2 to try to make things work. I've confirmed it takes 2 seconds extra to boot (without i2c connected). My understanding is that start.elf does the delay so when it stops it's before reaching the Linux kernel. Nothing shows on the HDMI display when i2c is connected at power-up. Not even the rainbow pattern if I remove disable_splash.
I'm running a custom configured kernel from the RPi foundation github. Currently version 4.4.17+. I really don't think that matters because I'm pretty sure it's not getting that far.
Code: Select all
avoid_safe_mode=1 boot_delay=2 disable_splash=1 max_usb_current=1 dtparam=i2c1_baudrate=400000 dtparam=i2c1=on dtparam-i2c_arm=on force_eeprom_read=0 dtoverlay=pi3-disable-wifi dtoverlay=pi3-disable-bt init_uart_clock=39062500 dtparam=uart0_clkrate=48000000 init_uart_baud=38400 gpu_mem=16 hdmi_force_hotplug=1 #disable_overscan=1
Anyone know of a way to keep GPIO3 from stopping bootup?