DM648 FVID_DEQUEUE frame buffer with wrong address?

David Bonifacio

Hi,

in our application we need to change video resolution at run time, passing from raw 1024 x 219 image to 1024 x 1000. So when we need, we stop the driver with FVID_CONTROL, deallocate all frame buffers, reload the video port parameter and reopen the video channel, allocating new frame buffers with the desired dimension.

All seems to work fine, sometimes when we pass from 1024 x 219 image to 1024 x 1000 and viceversa, the address of buffer are correct when we allocate them, but FVID_DEQUEUE gives to us some buffer with frameBuffPtr->frame.frameBufferPtr with wrong address (like 0xf0f0f0f0)! At this point the video port crash or don't work correctly!

what we do wrong! This problem is not sistematic, and I don't understand what I can change!

Regards,

David

over 14 years ago

0 James Gort over 14 years ago

Intellectual 590 points

Hi David-

I recently got through similar problem, so maybe I can help. When you stop and restart the VPORT drivers, you need to dequeue and then free all of the capture buffers. However, on the display buffers, one of them is owned by the application, so you do not dequeue it--just free it. The other display buffers are then dequeued and then freed. See below. This fixed the problem for me--when I was dequeing and then freeing ALL of the display buffers, the final dequeue would return error (-3) and then the free would fail (created Bios exception--Memory Free error--if you are not trapping the Bios exceptions, you should!). See below--the MEM_stat calls are debug to track heap...

//also free the buffers allocated for video ports
    for (capchan=0; capchan<MAX_NUM_INPUTS; capchan++)
    {
        for (buf_count = 0; buf_count < NUM_CAP_FRAME_BUFFERS; buf_count++)
        {
   status |= FVID_dequeue(capChInfo[capchan].chanHandle, &(capChInfo[capchan].frame));

            if (FVID_freeBuffer(capChInfo[capchan].chanHandle, &(capChInfo[capchan].frame)) != IOM_COMPLETED)
            {
                CLOG_printf_0(&trace, LOG_ERRORS, "Failed to free cap buffer");
                break;
            }
MEM_stat(EXTERNALHEAP, &Status);
        }
        if (buf_count != NUM_CAP_FRAME_BUFFERS)
            CLOG_printf_0(&trace, LOG_ERRORS, "Failed to free all capture buffers");
    }

// Free buffer owned by application
    if (FVID_freeBuffer(disChInfo.chanHandle, &(disChInfo.frame)) != IOM_COMPLETED)
    {
         CLOG_printf_0(&trace, LOG_ERRORS, "Failed to free dis buffers");
    }
MEM_stat(EXTERNALHEAP, &Status);
// Dequeue and free buffers owned by driver
    for (buf_count = 0; buf_count < (NUM_DIS_FRAME_BUFFERS-1); buf_count++)
    {
        status |= FVID_dequeue(disChInfo.chanHandle, &(disChInfo.frame));

        if (FVID_freeBuffer(disChInfo.chanHandle, &(disChInfo.frame)) != IOM_COMPLETED)
        {
            CLOG_printf_0(&trace, LOG_ERRORS, "Failed to free dis buffers");
            break;
        }
MEM_stat(EXTERNALHEAP, &Status);
}

Jim

0 David Bonifacio over 14 years ago in reply to James Gort

Prodigy 160 points

Hi James,

Thanks for you reply!

in our application, we don't use display port. We send image through ethernet, but we make your same operation when changing video port settings:

1- we stop driver

2- dequeue and deallocate all frame buffer owned by driver

3- deallocate all frame buffer owned by our application

4-reconfigure video port with new number of lines, dimension of lines etc

5- allocate and queue buffers

6- restart video port driver

These operations go well, but sometimes we notice that frame buffer returned by dequeue after restarting driver has addr: 0xf0f0f0f0! And it can be that the application run correctly until we rechange video port settings. It seems something related with driver?!

0 David Bonifacio over 14 years ago in reply to David Bonifacio

Prodigy 160 points

Hi,

we are continuing our test debugging the application. Now we simply reconfigure videoport using always the same frame dimension (in order to exclude memory problems): 1024x219.

What we notice is that:

video port allocates correctly 4 frame:

1: vport2.frame 0xF0000000 vport2.frame->frame.rpFrm.buf 0xF0000080

2: vport2.frame 0xF0000040 vport2.frame->frame.rpFm.buf 0xF0036C80

3: vport2.frame 0xF006D880 vport2.frame->frame.rpFm.buf 0xF006D900

4: vport2.frame 0xF006D8C0 vport2.frame->frame.rpFm.buf 0xF00A4500

When we have the problem we notice that FVID_dequeue give us correct vport2.frame address, but vport2.frame->queElement, vport2.frame->frame, vport2.frame->pitch and so on have 0xF0F0F0F0. As I have described in the other post we alway stop driver, deallocate buffer in the queue and buffer used by application, and finally delete channel, then we reallocate the channel, reallocate buffer, queueing them and finally start the driver. All go well, but sometimes we dequeue a frame, which have correct address, but wrong vport2.frame->frame.rpFm.buf =0xF0F0F0F0. Any suggestion?! We notice that when the problems happens we are using edma to copy a portion of image for our image analisys, can this related with edma3? Now we are also reinit edma when we reconfigure the videoport, at the moments the problem seems disappeared, but we are testing it, because the problem is random and we are not yet confident.

Regards,

David Bonifacio

Processors

Processors forum

DM648 FVID_DEQUEUE frame buffer with wrong address?