1
\$\begingroup\$

I'm trying to acquire video from an image sensor using a ZedBoard with Vivado 2014.2 and I used an existing (working) video passthrough project of mine and simply added in a debayer (color filter array interpolation) IP and reconfigured some existing blocks. Here is the block diagram:

figure1

Using a very simple SDK project, the processor refuses to initialize the VTC detector config anymore. Here is the body of main.c:

init_platform();

print("Hello World\n\r");
fflush(stdout);

XVtc vtc;
XVtc_Config *VtcCfgPtr = NULL;
int Status = 0;

VtcCfgPtr = XVtc_LookupConfig( XPAR_VTC_0_DEVICE_ID );

if(VtcCfgPtr == NULL) {
return 1;
}

Status = XVtc_CfgInitialize(&vtc, VtcCfgPtr, VtcCfgPtr->BaseAddress);

if(Status != XST_SUCCESS) {
return 1;
}

printf("success\n");

return 0;

When I first power on the board, the function XVtc_CfgInitialize is called but the processor freezes internally at the XVtc_Reset function inside (xvtc.c line 232). Trying to step through this function in the debugger is also very difficult because it is somehow skipping through random lines in the function and not executing them sequentially (and the XVtc_CfgInitialize function seems to get called twice inside the debugger also?? and only freezes the second time around).

\$\endgroup\$
  • 1
    \$\begingroup\$ Unless someone has experienced the same problem, this may be hard to figure out without more information. Can you post the source of XVtc_Reset, preferably the original but a static decompilation if nothing else? Does the process seem reliable if you do not configure the video peripheral? \$\endgroup\$ – Chris Stratton Aug 20 '14 at 16:10
  • \$\begingroup\$ The XVtc_Reset function is simply macro-fu for "* (volatile u32 * )register = value;". There are other timing controllers in the design which initialize just fine, only this one has the problem... tried re-creating it but that didn't help. \$\endgroup\$ – bparker Aug 20 '14 at 17:32
  • \$\begingroup\$ What is the value of "register"? Is it reasonable? If there is an MMU, is it properly configured to map that physical location to a logical one and allow access? \$\endgroup\$ – Chris Stratton Aug 20 '14 at 17:35
  • \$\begingroup\$ "register" is the base address of the timing controller as visible from the address editor in vivado (I confirmed the macro points to the same address), and there is no MMU. The reset function is writing the correct values in the control register to reset the timing controller so I have no idea why it is freezing on just this one controller. \$\endgroup\$ – bparker Aug 20 '14 at 19:10
  • 1
    \$\begingroup\$ You may have tried this already, but sometimes I find I have to clean the netlist and let it build from scratch. \$\endgroup\$ – mng Aug 20 '14 at 22:01
1
\$\begingroup\$

One thought - it sounds like the AXI bus may be waiting for the peripheral to respond (by acknowledging the write) and it isn't.

This can be caused by a variety of things, but having the addresses wrong would be one to check. Can you add a Chipscope and see what bus transactions are taking place?

\$\endgroup\$
  • \$\begingroup\$ I'm still having this issue on a totally different project, and the address it's using is correct. Any other ideas? \$\endgroup\$ – bparker Apr 17 '15 at 22:07
  • \$\begingroup\$ simulation or chipscope I'm afraid - check the acknowledgements \$\endgroup\$ – Martin Thompson Apr 18 '15 at 20:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.