Actions
Forum Thread Details
  • State Suggested Answer
  • Replies 8 replies
  • Answers 5 answers
  • Subscribers 500 subscribers
  • Views 1765 views
  • Users 0 members are here
Related

Problems with sample Zmod SDK project for USB104 A7

Fred27

Whilst road testing the USB104 A7, I decided to see how it worked with the ADC and DAC Zmods that were supplied with the Eclypse Z7. Unfortunately I seem to be having some strange issues with the sample code. I've already asked about this on the Digilent forums, but have so far received no reply so I thought I'd ask here. I was about to describe these problems in my road test, but decided that I should check first in case it's user error! I'll paste what I wrote there:

I'm trying to use the ZmodADC and ZmodDAC with the Digilent USB104 A7. I'm hitting the same problem with both SDK projects, after very carefully following the supplied instructions. I'm using Windows 10 and Vivado / SDK 2019.1.

 

When I run the project the main entry point does not get hit. Setting "Stop at program entry" shows that ZMODADC1410:setCalibValues or ZMODDAC1411::getSignedRawFromVolt is hit on entry rather than main. I don't believe either are called from their respective constructors.

 

I had no problems with the DSPI demo (obviously using Vitis 2020.1). I had no problems with the Zmods on an Eclypse Z7.

I had recorded a video of what's happening, but I seem to have deleted it. If nobody has any suggestions I'll re-record it.

 

Update: Rerecorded video

  • 0

    First burn the bitstream with no app attached to it. Set it to bootloop. Then burn the .elf separately.  See if there is any change.

  • 0 in reply to dimiterk

    I'm not sure exactly what you mean. Am I not doing that already?

     

    I believe the "Xilinx / Program FPGA" burns the bitstream - with empty program memory and the MicroBlaze set to bootloop. Debugging the MicroBlaze app should then burn the elf for the program and run it.

  • 0

    Still no solution, sorry, but for completeness: As you end up in a function I assumed there would be someway of seeing the call/stack history like on most other IDEs. To test that hypothesis I loaded up a SDK example that I knew worked and paused within a function, but it doesn't see to show anything in the new window image. I used the search box and entered 'stack' to find and launch the Call Stack (tracing) pane.

  • 0 in reply to 14rhb

    You'd think so, wouldn't you? The problem is that the call stack seems to start at this point.

  • 0

    Hi

     

    Following my comment in your roadtest page discussion I have investigated and also installed Vivado 2019.1 - although currently I am unsure if it is registered under my old license or indeed fully up-to-date. But at least its a start.

     

    That let me (1) learn how to choose which version to run depending on the task or example available on internet (2) from that I can hopefully also install other versions (3) try out the ZMOD DAC example.

     

    Firstly, once I'd setup the workspace to point at my extracted ZMOD DAC folder I was able to import the three project components - HW, BSP and SW. I re-built the BSP and that worked this time (as opposed to when I was using Vivado 2018.3 and it failed to generate the BSP). Initial build failed due to DPTI and I always end up stumbling my way through includes, the double quotes failed even with the path added...angle brackets to search the include path I manually added did work!

    #include <stdio.h>
#include "platform.h"
#include "xil_printf.h"
#include <dpti.h>
#include "ZmodDAC1411/zmoddac1411.h"

     

    That built and I downloaded the ELF and bit stream as you did....all good.

     

    I added a breakpoint and started the debug session, SDK changed to the debug perspective and stopped at the DemoInitialise call, I was then able to step into that function.

    image

    image

    image

     

    The only thing along the way that I ignored was this message:

    image

     

    Whilst the above may not help directly it shows the code and project can be built. Unfortunately I don't have the ZMOD DAC so I cannot actually see if it works.

     

    Let me know if you need any other screenshots of settings or try bits out.

  • 0 in reply to 14rhb

    Well, with your help I've finally found the answer. I think the bitstream under /FPGA/sdk_workspace is the problem. I thought I'd rebuilt it from Vivado, but it seems I hadn't. (I'm sure I'd seen the "do you want to reload the changed hardware platform" popup in SDK, but maybe I hadn't. Maybe it was the "An exported file for this module was found at this location. Do you want to overwrite it?" warning in Vivado I'd seen.

     

    Anyway, if you rebuild the bitstream and use Launch SDK from Vivado - ignoring the instruction in the readme that specifically tell you to not to do this - then you can get it to work!

     

    OK - back to my road test...

  • 0 in reply to Fred27

    Great news ...onwards we both go  image. As far as I recall I didn't even rebuild the bitstream but I did also launch SDK straight from Vivado this time.

     

    "do you want to reload the changed hardware platform"

    Sometimes I find this pops up at the front position and sometimes it remains hidden under other windows....sometimes I'm sure it doesn't display anywhere.

     

    By the way I've also added in Vivado 2020.2 to my laptop and apart from trouble with the boards initially it went well; a dusting of chmod and chown remedied my issues.

  • 0 in reply to 14rhb

      wrote:

    By the way I've also added in Vivado 2020.2 to my laptop and apart from trouble with the boards initially it went well; a dusting of chmod and chown remedied my issues.

    I suspect with multiple Vivado installations, the trouble you'll soon be having is lack of disk space! image