about ACPY3_start() API

This error is at the linker level, so although you have the proper header file you are missing the library that contains the object code for ACPY_start. I suspect it is contained within one of the .A64p files in C:\dvsdk_1_01_00_15\framework_components_1_20_03\packages\ti\sdo\fc\acpy3. Note that ACPY3 is meant to be used in a XDC (RTSC) build environment, so getting everything you need into it tends to be more complex than just including a .lib file, you may want to examine how the examples are being built with C:\dvsdk_1_01_00_15\framework_components_1_20_03\examples\build_instructions.html.

Are you building on Windows or Linux?  Based on your path, it appears like windows; since we do not offer a windows based DVSDK, you may be better of just switching to Linux, where you could find examples on how to use ACPY3 APIs.

[edit] please disregard comment above if you are working with one of our DSP only DaVinci devices (DM643X or DM648 families) 

Thanks for your response, I'm building the project on Windows. If I can't use ACPY3 APIs on Windows environment, then how can I use DMA on Windows ?

can I use the DAT_copy() APIs?

Thanks a lot!

What platform are you working with (e.g. DM6446, DM6467,...)?

I'm work with DM6446 platform, and use the platform to develop h.264 arithmetic on Windows environment!

I want to use DMA to optimize h.264 encoder!

Thanks a lot!

You do not want to use DAT_Copy API. 

If you are developing your own codecs, there are a few good examples under DVSDK codec engine directory (such as viden_copy).  These examples demonstrate how to use ACPY3 as well as DMAN3 to do DMA transfers on our DaVinci platforms.  However, these examples are Linux based.

We do not currently support a Windows build environment on our DaVinci platforms.  Although some customers have copied necessary files over (e.g. framework components) to windows and are developing in Windows.  Again, we do not support this, but it is possible.  ACPY3 and DMAN3 are part of framework components, therefore, you probably need to copy the entire directory over to windows.  This should have the header files as well as libraries you need.

A good alternative might be to work with the DM6437 DVEVM for codec development. It uses the same DSP CPU ('C64x+) that is used in the DM6446 device. So, if you clock them at the same rate, the DM6437 can be a great development vehicle for codec (i.e. algorithm) development.

1. Not only does this provide a Windows development environment, but you get full CCS support, too. (Well, one in the same, I guess.)
2. Cost of entry is quite a bit less, due to the lower cost of the DM6437 DVEVM vs that of the DM6446 DVEVM.

I've often recommended this to development teams who are cost sensitive. Those team members doing ARM-side development can use the DM6446 DVEVM (along with dummy/placeholder codecs); those doing codec development can make use of the less-expensive DM6437 board. Once the codec is built and tested (say, with test data) on the DM6437, then it can be packaged and integrated onto the full DM6446 platform.