Using dm648 EDMA3 to read internal register - video port status

Hi Dave,

I dont know if I understand you correctly... but why do you want to access the DM648 registers through EDMA?

You want to know how far the chained transfer that reads data from videoport is with copying data ("how many image-lines it has copied already")?
Wouldnt a EDMA_getConfig() call do the job? The destination adress of the EDMA transfer is updated during the chained transfer after every completed EDMA event triggered by the videoport. - so you can see how far the copy process has reached...

you can get the ready-status of the complete transfer for example with an EDMA complete interrupt. What status do you need?

best regards,

Thomas

Thomas,

 I have a situation where I lose frame sync between the video port and edma, and once it occurs it does not correct. The video port’s Short Frame detection (and recovery) works most of the time, but Short Frame misses some cases. When it does, I get a very visible “frame shift”. So, to better detect frame-shifts that the Short Frame indication misses, I added code to the edma ISR to look at the video port’s Y position being out of range. However, I can occasionally still reproduce an undetected frame-shift. (Btw, I reproduce it by applying a weak/marginal signal to the video device – then switch to a strong signal – frame-shift persists).

 To improve frame-shift detect, my idea is to use edma to read the video port X/Y positioning. I need DMA because the ISR has too much lag and will get an X/Y position considerably later in time. The edma can tell me exactly where the video port positions are at the time of the last edma transfer.

 I also have a related question... I believe I can also detect the shift if I knew what video port fifo status was at the end of the frame. ie, If fifo not completely empty upon edma frmae completion, then the edma and video port must be out of sync. However, I could not find anywhere in the datasheets if/where I have access to the video port fifo full/empty indications. Are they not memory mapped somewhere?

 I hope I was clear without being too wordy.

Regards,

 -Dave

The "System Interconnect" chapter of the data sheet shows which masters are connected to which slaves.  EDMA TC3 is the only TC that is not connected to the configuration SCR, which is where the video port registers would reside.  The channel that's reading from the video port registers needs to be mapped to one of the other queues.

Hi Dave,

Up to now we use a FPGA that contains the FIFOs together with a C6414 - so we have implemented the FIFO reset stuff on our own. But since we realize a new project with DM648 I'll have a similar problem...

Just to be sure to understand you correctly: you want an EDMA event to trigger a transfer that copies the register values to internal memory and evaluate the values afterwards in the EDMA complete ISR? What event did you want to use to trigger the transfer? (up to now I didnt work with EDMA events, everything in 'my world' is 'interrrupt driven' - so I am curious about the possibilities...)

I think that knowing the FIFO status would only help if you could be sure to check it within the Vblank time after the end of the frame. Can you be sure about that? Where do you plan to place that code? It cannot be in the FrameEnd ISR since if you lose some pixels this will not be called unless new data runs into the FIFO. I also didnt find a memory mapped location where the FIFO state could be read by the DSP.

Do you know the reason for losing pixels? Maybe theres another bug somewhere else in front of the videoport (camera sensor timing... - on some image sensors you can change quite a lot on the output data timing that maybe affects the stability of videoports fifo input...)

In my current project there are several cameras connected to one 'Videoport' (currently inside the FPGA) after a 'multiplexer' (also inside the FPGA). One of the cameras is 'actively' connected to the 'Videoport'. The cameras are freely running also if they are not 'actively connected'. When switching between 2 cameras, first the FIFO is reset, then the multiplexer switches and then another logic "holds the HSync active" until the end of the real HSync. With that we can be sure to get only 'full lines' into the Fifo. The FPGA also counts the 'line numbers' and triggers an Interrupt after every Hsync - so the C6414 reads the linenumber and can copy the data of one line to the correct location. Not very efficient but it works free of 'pixel shifts'. I wonder how I will implement this on the DM648...

best regards,

Thomas

Thomas

The event trigger will simply be the last pixel (Y) transfer from the edma frame - Upon last Y transfer, instead of sending event, it will chain to a dma channel that will read the VCxSTAT (to get xpos and ypos) and place it in the video buffer (external memory). That new chained-in dma channel will then send the event that generates the interrupt.

About the FIFO status, yes, I would theoretically read the FIFO status during ISR time which should guarantee it is within the blanking period.

I lose pixels because I am flipping channels (on VCR) or by weakening the video signal to the point where the video device sends bad frames to the DSP. In normal operation, pixels are never lost - only under these certain test scenarios.

We do not have an FPGA to insure clean frames going to DSP. In our previous product this was not a problem - it seems the 7114 (video device) was better at handling chnl flipping or weak video signals than the 5154 we chose for the new product.

Thanks for trying to find where I might get access to the FIFO status. Too bad its not accessible.

If you think you need better understanding, feel free to call my office 203 303 0140.

Brad,

Thanks for the pointer. I now see the table in the datasheet that shows TC3 not connected to SCR. However, I believe we are using TC0 for the video dma.

Any reason why TC0 would not have access to the video port status registers?

Meanwhile, I will look closer at how we select the TC for the various dma channels.

Thanks!

-Dave

The DMAQNUMn registers control the mapping of the channels to queues/TCs.  After your failed read has occurred please open a memory window to 0x02A00240.  That is the start of the DMAQNUMn registers.  There are 8, 32-bit registers.  Please post those values as well as which channel is doing the video transfer and which channel is doing the register read.

Brad

Brad,

I found the problem (by code inspection). We set dma Q0 for our 1st video port dma, BUT forgot to also set Q0 for the 2nd video port dma.

Of course for my testing - I was using that 2nd port - its dma Q was set to 3. Now set to Q0, I can read VCxSTAT using DMA.

You were right.

Thanks!

-Dave