Generates error in No-OS (2019_R2) using SDK 2019.1

So Abbas047 ,

I've discussed this internally,

1. We don't offer support anymore for 2019_R2 in no-OS.

Your tools (2019.1) are old, your desired no-OS version (2019_r2) is old.

The alternatives for you are: use master or use 2021_R1 which is compatible with Vitis 2021.1 or 2021.2.

On this branch of no-OS with a corresponding .xsa file, the build works on Windows, I've tested this.

C:\workspace\ad\no-OS\projects\ad9467>make TINYIIOD=y
[00:00:00] Building for xilinx
[00:00:00] Evaluating hardware: system_top.xsa
[00:00:00] Creating and configuring the IDE project
xtime_l.c:45:9: note: '#pragma message: For the sleep routines, Global timer is being used'
   45 | #pragma message ("For the sleep routines, Global timer is being used")
      |         ^~~~~~~
arm-none-eabi-ar: creating ps7_cortexa9_0/lib/libxil.a
xtime_l.c:45:9: note: '#pragma message: For the sleep routines, Global timer is being used'
   45 | #pragma message ("For the sleep routines, Global timer is being used")
      |         ^~~~~~~
arm-none-eabi-ar: creating ps7_cortexa9_0/lib/libxil.a
[00:00:00]  Linking srcs to created project
[00:00:00] [CC] ad9467.c
[00:00:00] [CC] no_os_irq.c
[00:00:00] [CC] no_os_spi.c
[00:00:00] [CC] axi_adc_core.c
[00:00:00] [CC] axi_dmac.c
[00:00:00] [CC] iio_axi_adc.c
C:/workspace/ad/no-OS/projects/ad9467/build/app/noos/drivers/axi_core/iio_axi_adc/iio_axi_adc.c: In function 'get_calibphase':
C:/workspace/ad/no-OS/projects/ad9467/build/app/noos/drivers/axi_core/iio_axi_adc/iio_axi_adc.c:83:36: warning: format '%li' expects argument of type 'long int', but argument 5 has type 'int' [-Wformat=]
   83 |  return i + snprintf(&buf[i], len, "%"PRIi32".%.6"PRIi32"", val, abs(val2));
      |                                    ^~~                           ~~~~~~~~~
      |                                                                  |
      |                                                                  int
C:/workspace/ad/no-OS/projects/ad9467/build/app/noos/drivers/axi_core/iio_axi_adc/iio_axi_adc.c: In function 'get_calibscale':
C:/workspace/ad/no-OS/projects/ad9467/build/app/noos/drivers/axi_core/iio_axi_adc/iio_axi_adc.c:136:35: warning: format '%li' expects argument of type 'long int', but argument 5 has type 'int' [-Wformat=]
  136 |  ret = i + snprintf(&buf[i], len, "%"PRIi32".%.6"PRIi32"", val,
      |                                   ^~~
  137 |       abs(val2));
      |       ~~~~~~~~~
      |       |
      |       int
[00:00:00] [CC] ad9517.c
[00:00:00] [CC] axi_io.c
[00:00:00] [CC] delay.c
[00:00:00] [CC] no_os_uart.c
[00:00:00] [CC] xilinx_irq.c
C:/workspace/ad/no-OS/projects/ad9467/build/app/noos/drivers/platform/xilinx/xilinx_irq.c: In function 'xil_irq_register_callbac
':
C:/workspace/ad/no-OS/projects/ad9467/build/app/noos/drivers/platform/xilinx/xilinx_irq.c:254:12: warning: cast between incompatible function types from 'void (*)(void *, uint32_t,  void *)' {aka 'void (*)(void *, long unsigned int,  void *)'} to 'void (*)(void *)' [-Wcast-function-type]
  254 |            (Xil_InterruptHandler) callback_desc->legacy_callback,
      |            ^
C:/workspace/ad/no-OS/projects/ad9467/build/app/noos/drivers/platform/xilinx/xilinx_irq.c: At top level:
C:/workspace/ad/no-OS/projects/ad9467/build/app/noos/drivers/platform/xilinx/xilinx_irq.c:337:33: warning: 'struct callback_desc' declared inside parameter list will not be visible outside of this definition or declaration
  337 |         uint32_t irq_id, struct callback_desc *cb)
      |                                 ^~~~~~~~~~~~~
C:/workspace/ad/no-OS/projects/ad9467/build/app/noos/drivers/platform/xilinx/xilinx_irq.c:381:25: warning: initialization of 'int32_t (*)(struct no_os_irq_ctrl_desc *, uint32_t,  struct no_os_callback_desc *)' {aka 'long int (*)(struct no_os_irq_ctrl_desc *, long unsigned int,  struct no_os_callback_desc *)'} from incompatible pointer type 'int32_t (*)(struct no_os_irq_ctrl_desc *, uint32_t,  struct callback_desc *)' {aka 'long int (*)(struct no_os_irq_ctrl_desc *, long unsigned int,  struct callback_desc *)'} [-Wincompatible-pointer-types]
  381 |  .unregister_callback = &xil_irq_unregister_callback,
      |                         ^
C:/workspace/ad/no-OS/projects/ad9467/build/app/noos/drivers/platform/xilinx/xilinx_irq.c:381:25: note: (near initialization for 'xil_irq_ops.unregister_callback')
[00:00:00] [CC] xilinx_spi.c
[00:00:00] [CC] iio.c
C:/workspace/ad/no-OS/projects/ad9467/build/app/noos/iio/iio.c: In function 'iio_step':
C:/workspace/ad/no-OS/projects/ad9467/build/app/noos/iio/iio.c:1379:24: warning: unused variable 'data' [-Wunused-variable]
 1379 |  struct iiod_conn_data data;
      |                        ^~~~
C:/workspace/ad/no-OS/projects/ad9467/build/app/noos/iio/iio.c: In function 'iio_init':
C:/workspace/ad/no-OS/projects/ad9467/build/app/noos/iio/iio.c:1824:1: warning: label 'free_pylink' defined but not used [-Wunused-label]
 1824 | free_pylink:
      | ^~~~~~~~~~~
[00:00:00] [CC] iio_app.c
[00:00:00] [CC] iiod.c
[00:00:00] [CC] ad9467_fmc.c
C:/workspace/ad/no-OS/projects/ad9467/build/app/ad9467/src/app/ad9467_fmc.c: In function 'main':
C:/workspace/ad/no-OS/projects/ad9467/build/app/ad9467/src/app/ad9467_fmc.c:196:33: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'uint32_t' {aka 'long unsigned int'} [-Wformat=]
  196 |  printf("  AD9517 CHIP ID: 0x%02x", ret_val_32);
      |                              ~~~^   ~~~~~~~~~~
      |                                 |   |
      |                                 |   uint32_t {aka long unsigned int}
      |                                 unsigned int
      |                              %02lx
C:/workspace/ad/no-OS/projects/ad9467/build/app/ad9467/src/app/ad9467_fmc.c: In function 'adc_test':
C:/workspace/ad/no-OS/projects/ad9467/build/app/ad9467/src/app/ad9467_fmc.c:357:10: warning: 'return' with a value, in function returning void [-Wreturn-type]
  357 |   return status;
      |          ^~~~~~
C:/workspace/ad/no-OS/projects/ad9467/build/app/ad9467/src/app/ad9467_fmc.c:325:6: note: declared here
  325 | void adc_test(struct axi_adc *adc,
      |      ^~~~~~~~
C:/workspace/ad/no-OS/projects/ad9467/build/app/ad9467/src/app/ad9467_fmc.c:381:34: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'uint32_t' {aka 'long unsigned int'} [-Wformat=]
  381 |    printf("  ERROR: PN status(%04x).\n\r", rdata);
      |                               ~~~^         ~~~~~
      |                                  |         |
      |                                  |         uint32_t {aka long unsigned int}
      |                                  unsigned int
      |                               %04lx
C:/workspace/ad/no-OS/projects/ad9467/build/app/ad9467/src/app/ad9467_fmc.c:410:22: warning: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'uint32_t' {aka 'long unsigned int'} [-Wformat=]
  410 |    printf("  ERROR[%2u]: rcv(%08x), exp(%08x)\n\r", n, rdata,
      |                    ~~^                              ~
      |                      |                              |
      |                      unsigned int                   uint32_t {aka long unsigned int}
      |                    %2lu
C:/workspace/ad/no-OS/projects/ad9467/build/app/ad9467/src/app/ad9467_fmc.c:410:33: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'uint32_t' {aka 'long unsigned int'} [-Wformat=]
  410 |    printf("  ERROR[%2u]: rcv(%08x), exp(%08x)\n\r", n, rdata,
      |                              ~~~^                      ~~~~~
      |                                 |                      |
      |                                 unsigned int           uint32_t {aka long unsigned int}
      |                              %08lx
C:/workspace/ad/no-OS/projects/ad9467/build/app/ad9467/src/app/ad9467_fmc.c:410:44: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'uint32_t' {aka 'long unsigned int'} [-Wformat=]
  410 |    printf("  ERROR[%2u]: rcv(%08x), exp(%08x)\n\r", n, rdata,
      |                                         ~~~^
      |                                            |
      |                                            unsigned int
      |                                         %08lx
  411 |           edata);
      |           ~~~~~
      |           |
      |           uint32_t {aka long unsigned int}
[00:00:00] [CC] no_os_circular_buffer.c
[00:00:00] [CC] no_os_fifo.c
[00:00:00] [CC] no_os_lf256fifo.c
[00:00:00] [CC] no_os_list.c
[00:00:00] [CC] no_os_util.c
[00:00:00] [LD] ad9467.o no_os_irq.o no_os_spi.o axi_adc_core.o axi_dmac.o iio_axi_adc.o ad9517.o axi_io.o delay.o no_os_uart.o xilinx_irq.o xilinx_spi.o iio.o iio_app.o iiod.o ad9467_fmc.o no_os_circular_buffer.o no_os_fifo.o no_os_lf256fifo.o no_os_list.o no_os_util.o
make[2]: Nothing to be done for 'post_build'.
[00:00:00] Done (build/ad9467.elf)

Here's the device visible in iio-oscilloscope following a windows build and debug:

2. Stop creating duplicate threads and stop messaging forum members privately.

Consider this a warning. Next time will be a ban.

ez.analog.com/.../analog-devices-engineerzone-code-of-conduct

Hello buha, and Microcontroller Support team, we successfully created the ad9467 project using a master branch of hdl and no-OS from the analog devices' GitHub repository. 

Thanks to the Microcontroller team who support me in each and every step to build the master branch. 

But, when we program the FPGA board and launch the hardware it shows nothing in the Vitis Serial Terminal.

Furthermore, when we want to debug the code, as a result, the debug will stop at the function name ad9517_power_mode(ad9517_device, 3, 0) 

But, when we step into this function the execution of code stop at this 
lvpecl_channel = &dev->ad9517_st.lvpecl_channels[channel];  // Stuck in this line of code

As a result, we didn't talk to the ad9467 and a9517 through SPI communication.

My Platform:

• Master Branch (HDL and no-OS) 
• Vitis/ Vivado 2021.2
• Ad9467 FMC
• Window 10 Pro, 64 bit

Thanks 

Abbas Ali
FPGA Engineer

Actually, the error which we received during execution of code in ad9517_power_mode(ad9517_device, 3, 0) while debugging.

This error shows Exception: Cannot read target memory. MMU section transaction fault

Similar, error occurs in ad9517_frequency(ad9517_device, 3, 250000000);

Kindly, have a look at these Cannot read target memory errors.

Thanks 

Abbas Ali

FPGA Engineer 

Hi again,

Glad you have a working environment.

I've just looked into your issue and I think I found the problem and the solution to it.

An engineer will double-check and make a patch today and publish it on github, I will keep you posted here.

Regards

Thanks for your guidance buha. You and your team helped me a lot to have such a working environment.

Glad to see your quick response, once your engineer double-checks this issue and makes a patch today. So, then let me know here so, we can update it later on because after that we can easily launch the hardware and debug the full code step by step as well.

Thanks
Regards 

Hi again,

We've updated the project on the master branch. Please do a `git pull` on the master branch to get the latest changes.

And then build again the whole project.

Regards

Hi again,

We've updated the project on the master branch. Please do a `git pull` on the master branch to get the latest changes.

And then build again the whole project.

Regards

Hi buha again,

After working so hard to reach that goal, I appreciate you so much for giving me such a great working environment.

We constructed hdl, no-OS, and successfully passed all of the test patterns in ADC TEST MODE using the Master Branch.

Here is the Vitis Serial Terminal's output.

In addition, we inspect the code line by line and examine each function's operation separately.

We noticed that the AD9517 setup, SPI settings, and how to initialise these devices and inspect the data pattern in test mode when debugging. But, printf("Start capturing data...\n\r"); is the key thing we're paying attention to. Here, is our main thing is to observe the ADC_DDR_BASEADDR which is defined as 

#define ADC_DDR_BASEADDR (XPAR_DDR_MEM_BASEADDR  + 0x800000)

Since we are providing analogue input to AD9467 FMC 260 ebz through J100 from the Digilent Waveform software and clock input through J201 from the same digilent software, we wish to view our data at this ddr memory address in digital format.

Here, are some pictures related to our connections

The DDR memory location 0x800000 displays random data while the code is being debugged during the first line of code before dma start transaction.
 

After that, when we execute code up to this below function 

/* Wait until transfer finishes */
status = axi_dmac_transfer_wait_completion(ad9467_dmac, 500);

Some values are updated in this DDR memory address. Here, is the snap

But, when we step over the above function, then this function 

Xil_DCacheInvalidateRange((uintptr_t)ADC_DDR_BASEADDR, 16384 * 2);

executed, due to which it invalidate the DDR_memory address and write random values in it. Here, is the snap

Here, are our issues:

We need end-to-end verification since the analogue input signal we supply through J100 must be transformed to digital form through ADC AD9467 in order to plot those samples of data from DDR memory using MATLAB or Python. Please let us know the ddr memory address where data samples are saved using dma so that we can retrieve the samples and plot them for end-to-end verification. Also, inform us about in which format the samples of data are stored in ddr memory.

Thanks once again for your great support

Regards

Abbas Ali
Fpga engineer  
 

Abbas047 ,

The way we interact with these ADC's is either we run the basic demo that you run, that populates a memory area with ADC samples, or we run (in firmware) and IIOD application that allows tools like the iio-oscilloscope to connect to it and plot the data continuously.

1. Given that you mentioned that you want to plot the samples in Matlab/Python, I recommend you try first with iio-oscilloscope.

The process is documented here:

https://wiki.analog.com/resources/no-os/tinyiiod_demo

You need to rebuild your project with the TINYIIOD=y flag as in the link above.

Observe the output on the serial terminal as described.

And lastly, connect the iio-oscilloscope with 115200 baudrate (for this project).

With this setup you will be able to see a plot of whatever you are generating with Analog Discovery 2.

2. Once you get this done and you are happy that you see what you transmit, you can switch back to reading from memory with a script that we have in our no-OS repo.

This page documents how to run the script but the page is not applicable entirely to this project, you need to make adjustments to the parameters (Address, channel count, sample count etc.)

https://wiki.analog.com/resources/no-os/dac_dma_example

Regards

Hi buha ,

Thank you for your recommendation. At this point, we are happy with the project's success because it has been made possible by your excellent suggestions that have helped us advance to new levels on a daily basis.

You suggested the iio-oscilloscope, which is described here: wiki.analog.com/.../tinyiiod demo
With the help of this link's instructions, we were able to create a project utilizing the TINYIIOD=y flag and attach it to a iio-oscilloscope. Here is the snapshot
 

Here, the connection was successfully established, and then the ADI IIO Oscilloscope window appeared.

Now, we'll go over three scenarios with you in which we use an input signal from Analog Discovery 2 and an ADI IIO Oscilloscope to view the ad9467's output voltage signal.

Scenario:1 You can examine the same sinusoidal signal on the oscilloscope during run time by providing sinusoidal input from Analog discovery 2. The image is shown below. Waveform signal (Running), IIO Oscilloscope (Running)
 

Scenario:2 You can examine the same sinusoidal signal on the oscilloscope during run time by providing triangle wave input from Analog discovery 2. Here's a picture, Waveform signal (Running), IIO Oscilloscope (Running)

In scenario 2, is it required to launch or debug the project in order to see the various waveforms in the oscilloscope? By the way, even after a relaunch and another round of code-debugging, the sinusoidal wave remains. Can you provide me some ideas on how we can view various waveform signals in the oscilloscope while it is in run-time?

Scenario:3 When we stop the Analog Discovery 2 input signal during operation, there is no signal at first and a sinusoidal wave arises at the ending. This is the picture. Waveform signal (STOP), IIO Oscilloscope (Running)

Here are the issues:

What are the methods, concerns, and things to keep in mind to obtain the same run time environment if the ADI IIO Oscilloscope plots the data continuously in run time as you instructed? Does the IIO Oscilloscope adjust appropriately if we change the input signal from Analog Discovery 2 or not? If so, what should we do?

Regards

Abbas Ali
FPGA Engineer

Hi again Abbas047 ,

Glad you overcame the build issues and that you can see waveforms captured with the ADC.

I think I can help you with these questions but given this thread is about build errors, and given that you overcame those, please do the following:

1) mark one of the replies above as an Answer to your original question

2) copy paste all your last comment, and open up a new thread in this subforum (Microcontrollers no-OS Drivers) where we can discuss your new questions (and tag me, so that I get a notification)

Let's continue the discussion there.

Regards

Hi,

We’ve followed the steps you told us.
Let’s continue discussion in this thread AD9467 FMC Start Capturing data and see the output waveform in ADI IIO Oscilloscope 

Thanks 

thanks!