DM648 VICP Affine transform artifacts

Hello Nissim,

Can you please look at the following thread: http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/t/42277.aspx . At the end there is a patch that may solve your issue.

regards,

Victor

Victor

Thanks for your reply.

I recompiled the LIB  with the attaches file on the link you sent  and it has no effect on the artifacts.

Regards

Nissin

Hi Nissin,

Can you try to decrease the QSHIFT parameter ?

regards,

Victor

Victor

Decreasing or increasing the QSHIFT does not help.

Please note that if the scaling factor >= 1 the image is fine.

If scaling factor<1  (except  if it is 0.5)  there are artifacts.

Also the VICP hangs  frequently at all scales

Regards

Nissim

Nissim,

Regarding the artifacts, I'd advise you to verify with the natural C code GPP_CPIS_affineTransform(), whether the artifacts are still there.

For the hanging issue, it is likely due to advisory 1.1.5 documented in the errata http://www.ti.com/lit/er/sprz263g/sprz263g.pdf 

Please refer to the paragraph 1.6.2 of http://www.ti.com/lit/ug/sprugj3e/sprugj3e.pdf  to workaround the issue.

regards,

Victor

Victor

Thanks for your responce.

Enclosed please find VICP HW and GPP images. the GPP Image is fine.

Rotating the Image 90 degrees and resizing by 0.66.

Using  The same parameters for the GPP and the VICP.

I will implement the errata recomendations and report back.

Regards

Nissim

Hi Nissim,

Thanks for taking time comparing with the natural C code. To help us fix the issue, could you tell me what is the original dimension of the image before resizing and rotation ?

Also it might take at best 2 months to fix the issue.

regards,

Victor

Victor

The input is 720x480  (standard NTSC)

The output  480x640  (rotated)

Please let us know if you know the type of the fix that you think is going to be needed so we can make decision on the project.

Regarding the errata:

Eliminating the IRAM making it cache did not help.

I'm using the EDMA cng file revised last by you, including the setup for the VICP. Is there a need to do any more changes ?

Thanks very much for your support

Nissim

Hi Nissim,

Thanks for the parameters.

The fix will likely be in file  src\src_hw\_affineTransform.c in function _CPIS_setAffineTransformProcessing(). Very likely some overflow issue.

For the hanging you need to make sure that all the EDMA channels in the system that have transfer directions DDR->L1, DDR->L2, DDR->VICP operate on the same transfer controller and all the channels  that have directions L1->DDR, L2->DDR, VICP->DDR operate on a distinct transfer controller. If you have for instance DDR->L2 and VICP->DDR on the same channel controller then the lock-up issue can show up.

The way you assign a channel to a  transfer controller is through a transfer queue. You assign a transfer queue to a transfer controller and then a channel to a transfer queue.

regards,

Victor

Victor

Is there any progress with the bug ?

Regards

Nissim

Hi,

I am developing an application on DM6446 EVM board with ARM9, DSP, VICP and some peripherals
I got a problem and don't find any solution for that, would you mind help me to solve that?
Before please note my design details:

    1 - The ARM is master and control other parts of system
    2 - The boot process is executed from NAND (BTSEL == 00), So after power on, the RBL (ROM Boat Loader) copies
        second level boot loader from NAND to ARM IRAM and then my application is loaded to DDR
    3 - Based on "spraai4.pdf" and "sprue14c.pdf" documents, I used the ubl to load my own application to DDR
        (it is noted that my application does not use any linux so I dont use uboot, I developed specific application)
    4 - Binary file of my ARM application from .out was generated with tms470.exe in CCS v3.3
    5 - Settings for NAND is J4=NAND, S3[1..4] = 0000 (NAND boot, 8-bit AEMIF, ARM boots DSP)
    6 - In my application, first some peripherals of systems (PINMUX, UART, I2C, VPSS) are configured, then DSP and
        VICP codes are copied to DDR, then DSPBOOTADDR is programed and finally the ARM releases C64x+ DSP from reset,
    7 - The DSP&VICP codes are included in ARM binary file as a header
    8 - To program NAND flash I use flash_burn_utility based on following web site
        (http://wiki.davincidsp.com/index.php?title=Serial_Boot_and_Flash_Loading_Utility)
    9 - The value of PSC_MDSTAT_IMCOP register (0x01C418A0)is 0x1E03 and the value of PSC_MDCTL_IMCOP register (0x01C41AA0) is 0x0003
        (I tested them with 0x1F03 and 0x0103 respectively but there is no difference)

All parts of my design works correctly except VICP (actually IMX does not generate interrupt for completion of procedure). for example, I checked above procedure with simple DSP example ("blinding a LED") and the DSP boots and works correctly

Also I checked program with JTAG Emulator when DSP_BT == 1 (J4=NAND, S3[1..4] = 0001), and VICP works correctly in this condition,
Under this circumstances, I flashed NAND but ARM does not boot when DSP_BT == 1(J4=NAND, S3[1..4] = 0001),

I dont really know why VICP does not work when DSP_BT == 0, is it need to initialze EDMA, INTC, MCBSP, ...?
Does EDMA3LLD configuration after system power on conflicts with VICP?
(I dont initialze and configure EDMA3 in ARM application because I think the DSP program initializes it automatically before using VICP in CPIS_Init method)