• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 102 subscribers
  • Views 939 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM3517 SPI Pin Configuration

Yves McDonald
Intellectual 320 points
Other Parts Discussed in Thread: AM3517

Hello,

I have compiled Linux kernel (2.6.37) for AM3517 EVM board with SPI support, wrote an application-specific, SPI protocol driver. The latter just sends a few bytes to SPI1.1 bus. I probed SIMO, CLK with a scope and I did not get any signal at all.

Kernel .config options:

CONFIG_SPI=y

CONFIG_SPI_MASTER=y

CONFIG_SPI_OMAP24XX=y

 

Kernel configuration looks ok: when Linux boots, here's what I find about McSPI:

Arago 2010.12 am3517-evm ttyO2

am3517-evm login: root

root@am3517-evm:~# dmesg | grep mcspi

[    0.110321] omap2_mcspi omap2_mcspi.1: registered master spi1

[    0.112274] omap2_mcspi omap2_mcspi.2: registered master spi2

[    0.113983] omap2_mcspi omap2_mcspi.3: registered master spi3

[    0.115570] omap2_mcspi omap2_mcspi.4: registered master spi4

root@am3517-evm:~#

 

Did I miss some steps? Do I have to configure pin muxing and pin i/o direction by myself (ex. additional coding in omap2_mcspi.c)?

Thanks.

 

Yves 

  • 0
    Expert 1600 points

    Normally you would need to configure your pin muxing and i/o directions with u-boot. I believe you could also configure this with in the kernel but I would suggest first trying uboot.

  • 0 in reply to orbarron
    Intellectual 320 points

    I tried using Pin Mux. It's easier to do than hacking the kernel but it looks like it overrides u-boot settings. I tried some GPIO bit toggling (gpio_152, gpio_153 actually). and they always remain low, even if gpio function calls are successful.

    Pin Mux instructions ask for changing the definition of CONTROL_PADCONF_SDRC_CKE0 from 0x0262 to 0x0266 in u-boot/.../mux.h when the target is the AM3517 EVM board:  is that correct?

    Someone did configure Linux pin muxing for AM35xx ZCN package as well (follow the link below). I tried his patch... no luck, but I didn't configure i/o with u-boot. That will be my next step:

    http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/416/p/115403/429915.aspx#429915

    In addition, I lose NFS access.That thread also mentions problems losing emac clocks: I might have the same problem.

     

    To be continued...

     

     

     

     

  • 0 in reply to Yves McDonald
    Intellectual 320 points

    ... Success!

    I have SPI clock and SIMO and GPIO bit output signals coming out of my eXperimenter board. I built everything by using the AM3517 Linux PSP 5.0.2 and Pin Mux utility. I patched also the kernel code with the pad definition patches I mentioned earlier. The last thing I was doing wrong was to probe at the wrong pins.

    So, from my experience, here's a word of caution for those who are using the following target configuration:

    1. LogicPD AM35x SOM-M2 processor module;
    2. LogicPD eXperimenter main board;
    3. 'breakout board' from www.createNewStuff.com.

    Watch for pin numbering 'mirror' effect: the pin numbers specified in SOM-M2 Hardware Specification document refer to SOM module connector pinout and they don't map directly to the breakout board pin numbers. For example, SPI pin numbers for bus # 1 are J2-81, J2-83, J2-85, J2-87 and J2-89 on the SOM module. On the breakout board, that translates to  J2-82, J2-84, J2-86, J2-88 and J2-90 respectively. 

    The signals were there but I was just probing at the wrong pins.

    Thanks to all!