This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[OMAP3530] VLIB causing SIO functions to freeze?

Other Parts Discussed in Thread: OMAP3530

What might cause the SIO_issue and SIO_reclaim functions to not return?  In my application (which resembles the DSPLink "loop" example) I'm issuing and reclaiming an input buffer, computing a result, then issuing and reclaiming an output buffer.  The computation includes a pyramidal optical flow scheme using VLIB functions for Gaussian pyramids and optical flow and IMGLIB functions for convolution.  Including it causes subsequent SIO API calls to hang the DSP, leading to a timeout on the GPP side.  (For example, I put NOTIFY calls on either side of SIO_issue and only the first one shows up.) The problem goes away when I exclude the VLIB calls to VLIB_trackFeaturesLucasKanade_7x7, but continue to execute all of the other image processing code.  I'm using the "error checking" version of VLIB and the return code from VLIB_trackFeaturesLucasKanade_7x7 is always 0.

I don't have JTAG or CCS for debugging, so I'm trying to understand what is going on.  Are there any ways to diagnose what's happening in VLIB?

Thanks

Michael

 

  • Michael,

    Can you give us some more information?  Which device are you using?  Are you using an EVM or custom board?  How are you building the DSP application?

    -Tommy

  • Tommy,

    Thanks a lot for responding; I apologize for not following up as I was working on some completely different projects.  I got back to this issue today and discovered that it was caused by a stack overrun.  One of the functions (specifically, the function that called VLIB) that I ran before SIO_issue had some local arrays defined that were being placed on the stack. If the arrays were just the right size, adding the VLIB call would appear to cause the problem.

    I had not realized that the stack size is defined separately for the OS and for each task.  After increasing the task-specific stack size appropriately, the problem went away.  Now I'm trying to improve the accuracy of the optical flow estimates from Lucas-Kanade.  I'll post  here if I run into any difficult issues there.

    Michael

     

  • By the way, I'm using the OMAP3530 on the Gumstix Overo with DSPLink 1.64 and DSP/BIOS 5.41.02.14 compiled against OpenEmbeddded.

    Michael