• Content Count

  • Joined

  • Last visited

About s4fq7

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hey Digilent, I was watching the following youtube video and saw your comment I've pasted below about porting examples over to Vitis. Do you guys have any ETA for this porting project? Just curious to try some of the features in Vitis. Thanks! Digilent, Inc. 5 months ago Great work! Just a note - Eclypse & Zmods will be ported over to Vitis soon and available in our Reference Center <3
  2. Thanks Ciprian, I got my environment working. Afew interesting things I noticed were that the BRAM being allocated for the dac demo appears to use a kBufferSize of 14 which equates to 16384 samples. Each of 32 bits. This roughly corresponds to the BRAM usage one sees when one builds the project. The SW also has a limit of 3FFF for the maximum waveform length. However in my cause sending any waveform longer than FFF resulting in any samples after FFF being set to 0. In my case I was able to track down the issue to the axi_dma_1 controller it has a "Width of Buffer Length Register" of 14 bi
  3. Hey Ciprian, Thanks so much for looking into this. I have some good news. I had been fiddling with my sdcard to try and get things working so I decided to re-flash it. After reflashing with the V0.2 release image again and checking the uEnv.txt file I was able to get things working. I tested both the zmod_adc_dac mode and zmod_dac mode and both appeared to work fine. I'm really not sure what went wrong during my original testing. I can only thing that somehow I may have done something to damage the initial state of the sd card OR damage the state of the SW Xilinx SDK projec
  4. Now that I know to run the baremetal demo's without an sdcard in the board I was able to get the zmod_dac demo to work as well in baremetal mode. However I couldn't use the hardware file that was in the SW repo for some reason I needed to rebuild the hardware from the HW repo. I'm guessing maybe that hardware image in the SW repo only works for the zmod_adc_dac demo for some reason. So the only thing left for me is figuring out how to get petalinux to work either using your release image or a custom built petalinux image.
  5. Update: I was able to get the baremetal version of the code to work, if I removed the sd card from the EclypseZ7, repowered it and then repeated the manual fpga programming before launching the code. I'm not sure why I needed to remove the sd card in addition to reprogramming the fpga as I had already tried reprogramming the fpga and making sure that if it did use the bit file on the sdcard boot it would use the adc_dac file. I'm guessing some how petalinux was overriding the fpga image I was flashing from xilinx sdk before I could start the code. (seems unlikely though). Also I was able to co
  6. I filed an issue on github for this post https://github.com/Digilent/Eclypse-Z7-SW/issues/1
  7. Next update: I've gotten further with the petalinux version by using the version of the hardware and SW supplied by https://github.com/Digilent/Eclypse-Z7-SW/tree/zmod_adc_dac/master It seems the latest version under zmod_dac has incompatible HW and SW (https://github.com/Digilent/Eclypse-Z7-SW/tree/zmod_dac/master) Using the code under zmod_adc_dac I still can't get the petalinux or baremetal versions to work I'll detail the errors below. petalinux: Recieves what appears to be a valid non 0/NULL DMA address but for whatever reason the set waevform never triggers the
  8. One last datapoint I wanted to include from the top of the main.cpp shows that the DAC_DMA_BASE_ADDR is defined as 0x40400000, looking at the image of the directory from my last comment and given the fact this is supposed to be the Zmod B connector this seems odd to me. I would have expected it to be the second DMA address of 40410000... Just mentioning it incase this is the cause. #define TRANSFER_LEN 0x400 #define IIC_BASE_ADDR 0xE0005000 #define ZMOD_IRQ 61 #define DAC_BASE_ADDR 0x43C00000 #define DAC_DMA_BASE_ADDR 0x40400000 #define DAC_FLASH_ADDR 0x31 #define DAC_DMA
  9. Hey Digilent, I'm pretty sure this DAC sample is broken for the Eclypse Z7. I spent afew more hours today looking into it and it seems like the DMA device for the DAC is returning that it only has RX channels meanwhile the code is saying it needs a TX channel. Is there some chance you guys have the wrong FPGA hardware image in the repo as that is the one I'm using to program? https://github.com/Digilent/Eclypse-Z7-SW/blob/00ad914cdf8d7691d352803334ede168103963e9/design_1_wrapper_hw_platform_0/design_1_wrapper.bit Either that or perhaps your petalinux release distribution has the
  10. Hey Digilent, I've successfully run the low_level_zmod_adc_dac demo on my board with a ADC and DAC ZMOD. https://reference.digilentinc.com/reference/programmable-logic/eclypse-z7/low_level_zmod_adc_dac I next decided to run the zmod_dac demo using both petalinux and baremetal. https://github.com/Digilent/Eclypse-Z7/tree/zmod_dac/master I was able to program the FPGA and also run the code, however every time it attempts to allocate a buffer to transfer the waveform via AXI DMA malloc is returning a 0/NULL value for the buffer address. If I am correct this means that mal
  11. Hello, I was hoping to use your uC32 board to control 4 stepper motor drivers and to provide debug information over serial back to a PC. Unfortunately though the UART routine implemented in HardwareSerial only has a buffered RX implementation and not a buffered TX implementation. This means that at lower baud rates or with larger debug payloads the time to send the data into the serial line can take a rather long time. I looked around online and I can't find any pre-built libraries that implement an IRQ based UART TX Buffer on the PIC32 that would be compatible with the framewor
  12. Hey Attila, Sorry to ask a slightly unrelated question (I can create a new forum post for it if you want) but is it possible to increase the Scope record view to more than 10 million samples when operating at 1-2 Mhz? I was considering geting an analog discovery and using it to record 1-2 minutes of 1-2 Mhz sample data. (this is currently what I'm doing with my arduino). The demo AD2 in Waveforms appears to have a limit of 10 million samples in record mode in Scope view though. Base on my understanding record mode is just buffering data through the 2x8K scope buffer directl
  13. Hey Attila, Thanks so much for the detailed and comprehensive reply! It hadn't even occurred to me that the -IN was connected to the -OUT (which I was tying to ground through the USB) I'm going to give it some more thought, but you've provided me with a number of options. I think either an analog discovery or usb2 isolator will be in order. Also I didn't realize the digital discovery measured the vio current that is really cool. Unfortunately 0.6mA is not enough resolution in this case as I'm measuring around 4-20 uA.
  14. After searching the forums a little more about ground loops I came upon the following post. I'm wondering if something like the following would solve my issue and if it would be compatible. Perhaps it would even allow one to use a digital discovery and analogy discovery on the same pc connected to the same circuit? Any thoughts? https://hifimediy.com/high-speed-usb-isolator-480Mbps
  15. Hey clf, I just had another try and I think I found the issue. The arduino I was using to monitor the uCurrent gold outputs was wired to the same PC via USB. This appears to have caused some kind of ground loop where current would flow through one us device and out the other (I suspect it's related to the battery in the uCurrent gold but if you have a better explanation I would love to know the exact reason this happened). The uCurrentGold Current input was wired in series with the VIO from the diligent to the sensor a MPU9250. The arduino was wired up with A0 going to