SOLVED-ish : getting i2c_1 working Tried compiling with the 1.0 beta image on sd card ... compiled first time with a working and tested i2c bus , WOW !!!!!!!!! now I`ll try compiling with the 1.1 image on sd card and see how that go. boy is it slow compiling using a sd card instead of a sata ssd . END RESULT Compiled with default 1.0 beta image works , Compiled with default 1.1 image , kernel panic ... enough said !!!!!!!! EXTRA INFO & FIX on my debian 1.1 image running on sata I uninstalled gcc-4.8 ( apt-get remove gcc-4.8 ) which also removed gcc and build-essential etc, so had to put them back . gcc -v now shows , Debian 4.6.3-14 and compiles without a kernel panic . wow a working i2c_0 , which is what I`ve tried and falled to do for a month .. So thank fetcher and TomFreudenberg you got me there in the end !!!
Thanks for the follow-up, Peter. It's good to know for sure that gcc-4.8 is the culprit. I wonder where the best place would be to file a bug report about this, and if Freescale-distributed kernels (without UDOO patches) are also affected.
Hi Peter, I am happy for you that at the end of this pain there was a solution. Thanks for sharing your knowledge.
As a sort of follow on , I`ve found if you want to use python on connect to your arduino in slave mode and control it like a normal i2c chip you are going to be out of luck. if you try a command like "data = bus.read_i2c_block_data(ADDRESS , the_reg)" which sends then requests data you will just get a io error , because only requestEvent() is tripped. My workaround is don`t use a arduino as a i2c slave if you are working in python , use the MBED platform which does !!!!
Hmm ... I cannot confirm this. As on my tests with python on Ubuntu 14.04 core everything worked. I am not sure per 100% but I wil send a short note if I was able to do a test again.
Normal i2c chips like the mcp23008/16/17 work in python smbus as they should , but after checking it looks like there is a fault with the wire library. http://forum.arduino.cc/index.php/topic,187282.0.html
1 shared between SAM and iMX6 (if enabled in kernel) How can I enabled in kernel? Can you help me? I want to send integer from SAM to iMX6. iMX6 will take that integer and process. Than I want to send answer from iMX6 to SAM. Can you help me?
I had been noticing a ridiculous number of interrupts accumulating on IRQ 59 whenever there was traffic on I2C bus #1: Code: # cat /proc/interrupts |grep -v ' 0 0 0 0 ' CPU0 CPU1 CPU2 CPU3 34: 65695 0 0 0 GIC sdma 38: 39 0 0 0 GIC imx-ipuv3 42: 93 0 0 0 GIC 43: 1 0 0 0 GIC galcore interrupt service for 2D 51: 36 0 0 0 GIC snvs_rtc 54: 43898 0 0 0 GIC mmc1 56: 110697 0 0 0 GIC mmc0 59: 143262926 0 0 0 GIC IMX-uart # <--- !!! 60: 18494820 0 0 0 GIC IMX-uart 61: 57551 0 0 0 GIC IMX-uart 62: 8171990 0 0 0 GIC IMX-uart 68: 39704461 0 0 0 GIC imx-i2c # <-- correlates to 70: 1 0 0 0 GIC imx-i2c 71: 16043 0 0 0 GIC ahci 72: 164199 0 0 0 GIC usb_wakeup, fsl ehci pre interrupt, ehci_hcd:usb2 75: 223591 0 0 0 GIC usb_wakeup, fsl ehci pre interrupt, ehci_hcd:usb1 87: 37366252 0 0 0 GIC i.MX Timer Tick 150: 4974907 0 0 0 GIC enet 419: 1 0 0 0 GPIO UDOO IPI0: 0 8165325 5973217 8486058 Timer broadcast interrupts IPI1: 726826 2193286 1855430 1846337 Rescheduling interrupts IPI2: 3064 3058 3102 3106 Function call interrupts IPI3: 9661 44698 39948 41870 Single function call interrupts LOC: 1504976 382382 328891 362718 Local timer interrupts IRQ 59 serves UART 2 (/dev/ttymxc1), the usbserial-console on CN6. At first I thought maybe some kind of debug information was appearing there (despite nothing in dmesg), but monitoring the console revealed no output. It turns out the i.MX6 UARTs trigger an interrupt when their CTS/RTS handshaking inputs change state, and with Udoo's default kernel, UART2_RTS_B is sharing a pin with I2C data! See the description of daisy-chain mux register IOMUXC_UART2_UART_RTS_B_SELECT_INPUT on page 2682 of the Freescale reference manual (IMX6DQRM.pdf). This defaults to 000 = EIM_DATA28_ALT4, which is the I2C data pin. I used the "devregs" register-poke tool to change this to 001 = EIM_DATA29_ALT4, which on the Udoo board is a no-connect, and the stray IRQs immediately stopped. Note that devregs_imx6.dat has a slightly different name for this register: Code: devregs IOMUXC_UART2_IPP_UART_RTS_B_SELECT_INPUT 1 The UART3 and UART4 RTS selections seemed questionable too, so I changed them as well: Code: devregs IOMUXC_UART3_IPP_UART_RTS_B_SELECT_INPUT 2 # uart4 RTS (SAM3X) -> RTS_ARD (RTS pin on usbserial CP2104), not random GPIO devregs IOMUXC_UART4_IPP_UART_RTS_B_SELECT_INPUT 1 # (uart5 RTS already defaults to N/C pin) I guess it'd cleaner to change this in the kernel source, via board-mx6qd_seco_UDOO.h or board-mx6_seco_UDOO.c, but this was happening on a production system that I didn't want to reboot, so after running the devregs pokes I added them to rc.local also for automatic execution on startup. See this thread for a link to the handy (if dangerous) devregs, original source and a Debian binary: http://www.udoo.org/forum/pwm-pins-mx6-udoo-quad-udoobuntu-t1585.html
Word of warning! -- if you do invoke 'devregs' from rc.local, be sure to remove the '-e' flag from #!/bin/sh at the top of that script, or add something like "&& echo" (no quotes) to the end of each devregs line. Otherwise, your rc.local will stop executing after the first such command, since devregs has the annoying habit of setting a non-zero exit status even when there are no errors. (invoking a shell with '-e' causes scripts to abort after the first apparent error). This bit me over the weekend after an unexpected reboot, leaving the Udoo in a nonfunctional state (its network initialization came further down in rc.local) until I could get physical access to it again.
