Is there any possible conflict between VPORTS and MCASP on DM648?

Guillermo,

Can you tell me which device/processor you are using?

Thanks,

Brad

Sorry, it is an important thing to take into account.

I am using DM648 DSP (silicon revision 1.1) and DVDSK V1.11.00.00.

Thanks.

Try to use TC2 for captures, TC3 for display, TC1 for QDMA and TC0 for both McASP receive/transmit.

Regards, Srirami.

Thanks for your answers.

We have already tested this configuration. In fact, we have already tested a lot of different configurations. Our current configuration is: TC0 for MCASP receive/transmit, TC1 for captures, TC2 for displays and TC3 for QDMA.

Looking into the problem we have found out that DMAN3_grantDmaChannels is changing the configuration of EDMA3_QUEPRI register to 0x00000073. In our initialization process this register is set to 0x00003210. We know how to change DMAN3_PARAMS.qdmaQueueMap (Array contaning the mapping from QDMA Channels to Event Queues) and  DMAN3_PARAMS.queuePri (Array contaning priorities of the event queues) in other versions of DVDSK/Frameworks_Components because in that versions you can find these fields in  DMAN3_PARAMS structure but we do not know how to change these parameters (or a way to prevent that DMAN3 changes that registers) in "dvsdk_1_11_00_00_DM648".

Any suggestion about it?

Thanks in advance.

Hi experts,

We have noticed important improvements changing QUE_PRI, DMA_QNUMx and QDMA_QNUM registers but our system doesn't work fine yet. We suposse the problem in related to priority management: Dequeue Priority (DMA_QNUMx and QDMA_QNUM), System Priority (QUE_PRI), and DDR2 Burst Priority register (BPRIO). We have a lot of doubts about how to modify BPRIO and MDMAARBE (Master DMA Arbitration Control Register). 

Could you recomend any configuration? How can we find out the right combination of priority?

We are using VP1 (BT656 Mode) for video capture and VP0 (Raw Mode) for TS capture, VP2 for display, MCASP receive/transmit, QDMA for Video Encoding and EMIFA for FPGA control.

Thanks in advance.

I am not clear on “some pixels are not captured (VPORT1). Because of  "auto synchronization" process is enabled some fields are missed when this problem occurs” .

But – McASP underrun happens because the EDMA did not get its time to service Mcasp Transmit in real time. That lock up/delay could be due to combination of TC usages/ problem of MDMA/SDMA lock issue.

Please note that the customer has used only TC3 for both Capture and Display, which should be avoided as it might lead to MDMA/SDMA lock up issue.

Hence I suggest to use the TC usage a below.

• use a TC (say TC2) for all DDR – write use cases (capture + algorithms that require write to DDR)
• use another TC (say TC3) for all DDR – read use cases (display + algorithms that required read from DDR)
• Audio receive – TC0
• Audio transmit – TC1

Thanks for your answer.

We have already solved the MCASP issue using the following priority configuration:

MCASP Tx/Rx => TC0, VP0/VP1 => TC1,  VP2 => TC2, QDMA = TC3;
QUE_PRI = 0x00003210; BPrio = 0x00000020; mdmaarbe = 0x00040000;

In addition we set PCI bus master priority to 7. We change the value of QUE_PRI after DMAN3_grantDmaChannels execution because this routine changes the value of this register and we do not know how to avoid it (we would like change this register only during the initialization process).

At this moment we are suffering problems only on the VP0/VP1 side. As we told you previously, we are using VP0 for Transport Stream capture and VP1 for BT656 capture. Our system is working fine, but sometimes the execution of FVID_exchange routine (VP1) takes more than usually (60ms instead of 40ms). We have figured out that VP1 driver begins an autosynchronization process (because of syncEnable = 1) when that happens. Looking into the problem we have observed how inside the driver (_autosync routine) a wrong value of FID input is detected. When it works fine FID has a value of 1 and YPOS = 313 and when it fails, FID = 0 and YPOS = 313. If Audio Encoder and Decoder are disabled (but not MCASP) our system works fine that´s why we suppose there is not any problem related to input signals (FID, VBLK and HBLK). We suppose we still have problems with Master Priorities. With your configuration the behaviour of the system is the same.

Best Regards.

Thanks in advance.

TC0 and TC1 are meant for high priority low bandwidth transfers like audio.

TC2 and TC3 are meant for low priority high bandwdith tranfers like video.

Since you are using TC1 for VP0/VP1, it may not be possible to sustain the high data rate of video.

Could you try the following,

MCASP Tx/Rx => TC0, VP0/VP1 => TC3,  VP2 => TC2, QDMA = TC1;

We obtain the best behavioural using the following configuration:

TC0 for MCASP Rx and VP0 (capture TS from a coprocessor)
TC1 for MCASP Tx
TC2 for VP1 (capture BT656 frames)
TC3 for VP2 (display BT656 frames) and QDMA (since QDMA only reads from DDR2 like VP2).

QUE_PRI = 3210
MDMA = Priority level 4.
PCI (for TS transmission) = Priority level 7
BPRIO = 0x00000020

But we have the same problem:

Our system is working fine, but sometimes the execution of FVID_exchange routine (VP1) takes more than usually (60ms instead of 40ms). We have figured out that VP1 driver begins an autosynchronization process (because of syncEnable = 1) when that happens. Looking into the problem we have observed how inside the driver (_autosync routine) a wrong value of FID input is detected. When it works fine FID has a value of 1 and YPOS = 313 and when it fails, FID = 0 and YPOS = 313.

We are using an scope for monitoring input signals and they are working fine. Also, we are using several GPIOs in order to visualize when an error ocurrs and the VP1 interrupt periodicity.
When an error ocurrs the VP1 interrupt is attended very closer to a falling edge of HBLK (first HBlanking after VBlanking starts). ISR is attended after that falling edge. When all is ok the ISR is attended after or before the falling edge of HBLK but it is never very closer to the falling edge of HBLK. I don't know if it could be related to our problem. I would like to test VP1 behavioural using VPORTCAP_HRST_START_HBLK instead of VPORTCAP_HRST_END_HBLK but it doesn't work fine. For that purpose, we are using the following configuration for BT656 (PAL mode):

vCapParamsChan.vCtRst = VPORTCAP_VRST_START_VBLK;
vCapParamsChan.fldInv = VPORTCAP_FINV_ENABLE;
vCapParamsChan.fldYStrt1 = 25;
vCapParamsChan.fldYStrt2 = 26;
vCapParamsChan.fldYStop1 = 288 + 24;
vCapParamsChan.fldYStop2 = 288 + 25;

vCapParamsChan.hCtRst = VPORTCAP_HRST_START_HBLK;
vCapParamsChan.fldXStrt1 = 144;
vCapParamsChan.fldXStrt2 = 144;
vCapParamsChan.fldXStop1 = 863;
vCapParamsChan.fldXStop2 = 863;

What dou you think about my problem?

Best Regards.

Thank you in advance.

Sorry for the delayed response.

I still couldn't figure out what could casue this issue.

Since you have mentioned that autosync routine is getting called, it could be VPORT configuration issue.

Have you tried the following configuration for PAL capture?

    cmode = VPORT_MODE_BT656_8BIT,
    fldOp = VPORT_FLDOP_FRAME,
    scale = VPORT_SCALING_DISABLE,
    resmpl = VPORT_RESMPL_DISABLE,
    bpk10Bit = VPORTCAP_BPK_10BIT_ZERO_EXTENDED,
    hCtRst = VPORTCAP_HRST_SAV,
    vCtRst = VPORTCAP_VRST_EAV_V0,
    fldDect = VPORTCAP_FLDD_DISABLE,
    fldInv = VPORTCAP_EXC_DISABLE,
    fldInv = VPORTCAP_FINV_DISABLE,
    fldXStrt1     = 0,
    fldYStrt1     = 3,
    fldXStrt2     = 0,
    fldYStrt2     = 3,
    fldXStop1     = 720 - 1,
    fldYStop1     = 288 + 2,
    fldXStop2     = 720 - 1,
    fldYStop2     = 288 + 2,
    thrld         = (720 >> 3),
    autoSyncEnable  = TRUE,