Debugging experience-davinci features

Debugging experience-davinci features

Each hardware platform has features that other platforms do not have.
Here, I will summarize the platform features problems I encountered during dm6446 debugging:

1. Use of hardware resize; 2. Address Analysis of davinci; 3. Use of shared memory CMEM.

1. resize debugging of 6446:

There are two routines in the 6446 dvsdk, one is the video loop and the other is the codec encodedecode, and I need a video loop program called by the dsp, so the two routines are integrated.

After integration, the DSP algorithm program cannot run.

First, the dsp algorithm is simplified to empty and can be executed. Then add the function module step by step. After multiple tests, it turns out to be a hardware resize problem!

Track and view the application, and find that smooth and resize on the ARM end are actually the same hardware as the hardware resize on the DSP end.

The hardware resize has been used on the arm end, and then the hardware resize has been used on the dsp end. The configurations on both sides are inconsistent. the root problem may be two cores (arm and dsp) simultaneously accessing the same hardware

(Hardware resize.

On the dsp side, use the for loop to implement resize, and the program can run normally.

In turn, the arm resize configuration is removed, while the dsp enables the hardware resize, the program can also run, but it is found that the image jitter increases, the effect is not good, not used.

Final Solution: instead, resize on the arm side, and the scaled image is directly used on the dsp side. In this way, only one core is allowed to access the hardware resize, while the operation efficiency is also taken into account.

Because smooth does not change the image size, try to use memcpy instead of resize.
During ARM operations: note the differences between physical and virtual addresses.
The buf address parameter of resize. The physical address is used;
The buf address parameter of memcpy, which uses a virtual address.
It can also run normally after replacement. However, considering that smooth has a smooth effect on the image, it is not replaced.

Currently, arm uses three times of resize, 1, capture, 2, reduce, 3, and display in video.
To avoid configuration conflicts: In capture, display, and video, you must first configure and then execute.

Try to standardize the configuration function Rszcopy_config_reduce () of resize ():
After unified to a function, the Operation finds that the image color is abnormal (all use the reduced filter parameters ).
Conclusion: different proportions of resize use different filter parameters, which cannot be simply unified into a function.

6446 execute the hardware resize operation on the SD image. Each time it takes about 6-7 ms, the call thread of the resize operation is blocked. At this time, the resize operation is performed by the hardware, while ARM is transferred to other threads. Compared to the software resize implemented by the for loop, we can see that the ARM occupation rate is significantly reduced.
 

Ii. Address Analysis of davinci:
Arm applications use virtual addresses;
The dsp algorithm uses a physical address.
When arm sends a parameter to the dsp, if it is a pointer, it must use a physical address.
When codec engine is used for buffer transfer, dsplink will have an address conversion, so you do not need to consider the differences during programming.
In arm applications, If you directly use a physical address and assign a value to the pointer, the system will be abnormal.
 

Iii. Use of shared memory CMEM

Pay attention to the usage of shared memory CMEM. First, the total size is limited, generally allocated as 8 M. For video processing algorithms, you always need to transmit the entire frame of images for processing. If you need more buffering for parallel processing, it is likely that the shared memory is not enough. Second, shared memory usage is prone to errors and must be protected accordingly. Our experience is:
(1) extract useful information from the image as early as possible to reduce memory usage in subsequent transmission;
(2) A large number of use control signs to achieve a memory area to achieve a variety of use functions.
(3) strictly separate the input and output variables, and unify the variable values of the same meaning on the ARM end.
(4) It is important to note that public variables must be protected and only one of the ARM or DSP can be accessed at a certain time.

Example of the shared memory allocation function:
Buf = (char *) Memory_contigAlloc (bufSize, 128 );
Example of obtaining a physical address:
Physaddr = Memory_getBufferPhysicalAddress (char *) buf, 4, NULL );

Associated header file:
# Include "/root/dvsdk_3_10_00_19/codec_engine_2_25_05_16/packages/ti/sdo/ce/osal/Memory. h"

The continuous memory needs to be opened to obtain the physical address, all of which are related to cmem and must be supported by the tool chain. You cannot use arm-gcc for separate compilation. You need to use xdc in dvsdk.