• State Verified Answer
  • Replies 2 replies
  • Subscribers 48 subscribers
  • Views 633 views
  • Users 0 members are here
Options
Related

ad1939 eval board - providing SPI from another board

YANNCARDAILLAC
on Jul 5, 2019

Hi,

I wish to program eval board AD1939's register from another board SPI.

I've try different connection of MOSI, MISO, CS but it doesn't seem to work. Can you tell me how that should be done?

Today I'm using the following configuration:

MOSI -> CDATA

MISO -> COUT

SCLK -> CCLK

CS -> CLATCH

I've tried different configuration (for instance inverting MOSI and MISO), but it does not seem to work better.. Do you have any advice to give me?

Best regards,

Yann

Parents
  • +1 on Jul 18, 2019 8:11 AM

    Hi,

    Problem was fixed while debugging closely the SPI link. Actually there seems to be an ambiguity regarding the CS policy (or SS policy depending on who you're asking), it seems that you can either poll down and up the CS each byte or actually let it down until full word is passed. For AD193x that means that the CS has to stay down for the 24 bits.

    If you think that's your problem here's how to debug:

    - add/use kernel's spidev and a spidev device in order to have a dummy spi link to the codec, then build spidev_test for your target:

    https://github.com/rm-hull/spidev-test/blob/master/spidev_test.c

    - Export a GPIO (output, value = 1) that you'd be using as CS, then pull low gpio send your read command and pull up the GPIO

    as an example to read "PLL and Clock Control 1" address 0x01 with gpio 79 as CS, using spidev device /dev/spidev32766.0  :

    echo 0 > /sys/class/gpio/gpio79/value
    ./spidev_test -s 400000 -D /dev/spidev32766.0 -b 8 -v -p "\x09\x01\xff"
    echo 1 > /sys/class/gpio/gpio79/value

    If you're able to read with this command, then that means that you should switch your CS to use with a GPIO. For instance it seems that nxp's ecspi doesn't offer the CS as expected by AD193x.

    Regards,

    Yann

Reply
  • +1 on Jul 18, 2019 8:11 AM

    Hi,

    Problem was fixed while debugging closely the SPI link. Actually there seems to be an ambiguity regarding the CS policy (or SS policy depending on who you're asking), it seems that you can either poll down and up the CS each byte or actually let it down until full word is passed. For AD193x that means that the CS has to stay down for the 24 bits.

    If you think that's your problem here's how to debug:

    - add/use kernel's spidev and a spidev device in order to have a dummy spi link to the codec, then build spidev_test for your target:

    https://github.com/rm-hull/spidev-test/blob/master/spidev_test.c

    - Export a GPIO (output, value = 1) that you'd be using as CS, then pull low gpio send your read command and pull up the GPIO

    as an example to read "PLL and Clock Control 1" address 0x01 with gpio 79 as CS, using spidev device /dev/spidev32766.0  :

    echo 0 > /sys/class/gpio/gpio79/value
    ./spidev_test -s 400000 -D /dev/spidev32766.0 -b 8 -v -p "\x09\x01\xff"
    echo 1 > /sys/class/gpio/gpio79/value

    If you're able to read with this command, then that means that you should switch your CS to use with a GPIO. For instance it seems that nxp's ecspi doesn't offer the CS as expected by AD193x.

    Regards,

    Yann

Children
No Data