SOLVED-ish - getting i2c_1 working

Discussion in 'Kernels' started by peter247, May 8, 2014.

  1. peter247

    peter247 New Member

    Joined:
    Mar 10, 2014
    Messages:
    263
    Likes Received:
    2
    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 !!!
     
  2. fetcher

    fetcher Member

    Joined:
    Mar 9, 2014
    Messages:
    166
    Likes Received:
    20
    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.
     
  3. TomFreudenberg

    TomFreudenberg Member

    Joined:
    May 12, 2014
    Messages:
    56
    Likes Received:
    2
    Hi Peter, I am happy for you that at the end of this pain there was a solution. Thanks for sharing your knowledge.
     
  4. peter247

    peter247 New Member

    Joined:
    Mar 10, 2014
    Messages:
    263
    Likes Received:
    2
    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 !!!!
     
  5. TomFreudenberg

    TomFreudenberg Member

    Joined:
    May 12, 2014
    Messages:
    56
    Likes Received:
    2
    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.
     
  6. peter247

    peter247 New Member

    Joined:
    Mar 10, 2014
    Messages:
    263
    Likes Received:
    2
  7. msener

    msener New Member

    Joined:
    Dec 1, 2014
    Messages:
    6
    Likes Received:
    0
    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?
     
  8. fetcher

    fetcher Member

    Joined:
    Mar 9, 2014
    Messages:
    166
    Likes Received:
    20
    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
     
  9. fetcher

    fetcher Member

    Joined:
    Mar 9, 2014
    Messages:
    166
    Likes Received:
    20
    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.
     

Share This Page