Post Go back to editing

spi_init error using AD7134_EVAL board with zedboard running no-os

I am getting an error when the spi_init routine is run.  This routine returns FAILURE.

    ret = ad713x_init(&ad713x_dev_1, &ad713x_init_param_1);
    if (ret != SUCCESS)
        return FAILURE;

I'm using this version of no-os...https://wiki.analog.com/resources/tools-software/uc-drivers/ad713x?s%5b%5d=ad7134

How can I resolve this issue?

Parents
  • OK, I now have the adapter cable to go between the AD7134 and zedboard.  However, I'm still getting the same error upon initialization of the spi interface.

    On this command in ad713x.c

        if (!init_param->spi_common_dev) {
            ret = spi_init(&dev->spi_desc, &init_param->spi_init_prm);
            if (IS_ERR_VALUE(ret))
                goto error_dev;

    What might be the problem with this code?

  • I started over and cloned the most recent no-os software from ad713x_fmcz and ran the make again.  My output is shown below.  Please let me know if this is what you would expect.

    Please note the following lines during linking:

    (1)     The system cannot find the file specified

    (2)      make[1]: [../../tools/scripts/generic.mk:339: update_srcs] Error 2 (ignored)

    C:\cygwin64\home\Steve\adi4\no-OS\projects\ad713x_fmcz>make
    [00:00:00] Building for xilinx
    [00:00:00] Evaluating hardware: system_top.xsa
    [00:00:00] Creating and configuring the IDE project
    arm-none-eabi-ar: creating ../../../lib/libxil.a
    In file included from usleep.c:34:
    xtime_l.h:65:9: note: #pragma message: For the sleep routines, Global timer is being used
       65 | #pragma message ("For the sleep routines, Global timer is being used")
          |         ^~~~~~~
    In file included from xil_sleeptimer.c:32:
    xtime_l.h:65:9: note: #pragma message: For the sleep routines, Global timer is being used
       65 | #pragma message ("For the sleep routines, Global timer is being used")
          |         ^~~~~~~
    In file included from xtime_l.c:27:
    xtime_l.h:65:9: note: #pragma message: For the sleep routines, Global timer is being used
       65 | #pragma message ("For the sleep routines, Global timer is being used")
          |         ^~~~~~~
    In file included from sleep.c:31:
    xtime_l.h:65:9: note: #pragma message: For the sleep routines, Global timer is being used
       65 | #pragma message ("For the sleep routines, Global timer is being used")
          |         ^~~~~~~
    In file included from main.c:115:
    zynq_fsbl_bsp/ps7_cortexa9_0/include/xtime_l.h:65:9: note: #pragma message: For the sleep routines, Global timer is being used
       65 | #pragma message ("For the sleep routines, Global timer is being used")
          |         ^~~~~~~
    In file included from pcap.c:78:
    zynq_fsbl_bsp/ps7_cortexa9_0/include/xtime_l.h:65:9: note: #pragma message: For the sleep routines, Global timer is being used
       65 | #pragma message ("For the sleep routines, Global timer is being used")
          |         ^~~~~~~
    arm-none-eabi-ar: creating ../../../lib/libxil.a
    In file included from usleep.c:34:
    xtime_l.h:65:9: note: #pragma message: For the sleep routines, Global timer is being used
       65 | #pragma message ("For the sleep routines, Global timer is being used")
          |         ^~~~~~~
    In file included from xil_sleeptimer.c:32:
    xtime_l.h:65:9: note: #pragma message: For the sleep routines, Global timer is being used
       65 | #pragma message ("For the sleep routines, Global timer is being used")
          |         ^~~~~~~
    In file included from xtime_l.c:27:
    xtime_l.h:65:9: note: #pragma message: For the sleep routines, Global timer is being used
       65 | #pragma message ("For the sleep routines, Global timer is being used")
          |         ^~~~~~~
    In file included from sleep.c:31:
    xtime_l.h:65:9: note: #pragma message: For the sleep routines, Global timer is being used
       65 | #pragma message ("For the sleep routines, Global timer is being used")
          |         ^~~~~~~
    [00:00:00]  Linking srcs to created project
    The system cannot find the file specified.
    The system cannot find the file specified.
    The system cannot find the file specified.
    make[1]: [../../tools/scripts/generic.mk:339: update_srcs] Error 2 (ignored)
    [00:00:00] [CC] ad713x.c
    [00:00:00] [CC] iio_ad713x.c
    [00:00:00] [CC] iio_dual_ad713x.c
    [00:00:00] [CC] axi_dmac.c
    [00:00:00] [CC] spi_engine.c
    [00:00:00] [CC] gpio.c
    [00:00:00] [CC] axi_io.c
    [00:00:00] [CC] delay.c
    [00:00:00] [CC] xilinx_gpio.c
    [00:00:00] [CC] xilinx_spi.c
    [00:00:00] [CC] spi.c
    [00:00:00] [CC] ad713x_fmc.c
    [00:00:00] [CC] util.c
    [00:00:00] [LD] ad713x.o iio_ad713x.o iio_dual_ad713x.o axi_dmac.o spi_engine.o gpio.o axi_io.o delay.o xilinx_gpio.o xilinx_spi.o spi.o ad713x_fmc.o util.o
    make[2]: Nothing to be done for 'post_build'.
    [00:00:00] Done (build/ad713x_fmcz.elf)

  • build/ad713x_fmcz.elf seems to have been generated. Try to run it.

    Thanks,
    Dragos

  • No response on the UART port when I do a "make run"

    I get the errors shown above when I try to debug in Vitis.  Either way the code does not seem to run.

  • Hello Vick,

    We managed to get the hardware up and running on our side. Indeed there is an issue on the spi side of the project.

    Can you try the following patch:
    https://github.com/analogdevicesinc/no-OS/commit/bb2bd9be4de0c002f2805cfe532ebcf6828a8bc2

    If everything is fine, we will merge the fix on the master branch.

    In my case, it solved the issue. Here is the serial output:

    Regards,

    Antoniu

Reply Children
  • Thanks.  Now I do have the code running properly and SPI seems to be happy.  However, my output is all 0.0V. 

  • The very first time after power cycling the board:

    2nd run after power up:

    3rd run:

    4th run:

  • Hello Vick,

    Did you connect anything at the input of the ADC channels so you can actually see if the samples are corresponding to the input voltage values? (at least for the first run after power cycle)

    Also, are you re-programming the FPGA before each run of the code?

    Regards,

    Antoniu

  • I think there are still issues with this no-os code, related to SPI.  I have scope probes attached to SCLK, SDO, and SDI at the TP locations on the AD7134 boards. I'm probing TP86 (SCLK), TP64 (SDO), TP59 (SDI) right at the FMC connector.

    For these two init instructions:

        ret = ad713x_init(&ad713x_dev_1, &ad713x_init_param_1);
        if (ret != SUCCESS)
            return FAILURE;
        mdelay(1000);
        ad713x_init_param_2.spi_common_dev = ad713x_dev_1->spi_desc;
        ret = ad713x_init(&ad713x_dev_2, &ad713x_init_param_2);
        if (ret != SUCCESS)
            return FAILURE;

    I see

    For this instruction:

        ret = spi_engine_offload_transfer(spi_eng_desc, spi_engine_offload_message,
                          (AD7134_FMC_CH_NO * AD7134_FMC_SAMPLE_NO));
        if (ret != SUCCESS)

    I see nothing on the SPI signals, even though the return is SUCCESS.

    I believe this is why my data is all 0x0.

    Thanks for your help.

  • Did you connect anything at the input of the ADC channels so you can actually see if the samples are corresponding to the input voltage values? (at least for the first run after power cycle)

    Yes, I have 1V DC attached to Channel 1.

    Also, are you re-programming the FPGA before each run of the code?

    Yes, I just tried that again and the result is still the same;  all 0x0 on the returned data. 

  • After discussing with the local FAE, I discovered that the ADC data will actually be transferred over the DOUT signals (not the SPI bus).   I connected the following signals to my scope to monitor them during the code execution:  DCLK on TP66, ODR on TP67, DOUT0_1 on TP68, DOUT0_2 on TP64.

    None of these signals are changing state during the code execution.

    1) Am I probing the right signals?

    2) What might be causing this issue?

    Thanks.

  • I found my problem.  The missing piece of the puzzle is the jumpers JP14 - JP17.  The user guide is not real clear on these and the boards are delivered in a non-operational mode.  JP14-16 are all installed, meaning all GND.  The schematic shows JP14 and JP16 should be open.  Once I removed JP14 and JP16, I started getting data that looks right.

  • So, in summary these are the issues I've discovered with the AD7134_EVAL board so far:

    1)  This board will not mate properly with a zedboard because of an interference issue;  an adapter cable will be required

    2)  The no-os code originally supplied came with some coding errors;  still waiting for the merged fix on the master branch

    3)  The board is shipped with the JP14-JP17 jumpers all installed;  this mode results in a non-operational board;  JP14 and JP16 must be removed for one of the operational modes.  The users guide is not really explicit regarding these jumpers.