vartarg=Build.targets[i];
Pkg.addLibrary（"lib/imgenc1",targ,{
}）.addObjects（SRCS）;
Pkg.addLibrary（"lib/imgenc1_debug",targ,{
profile:
"debug"
}）.addObjects（SRCS）;
}
发现错误
最后，我发现，原来错误来自于：
if（（sizeof（VISA_MsgHeader）+sizeof（*inBufs）+sizeof（*outBufs）+
inArgs->size+outArgs->size）>sizeof（_IMGENC1_Msg））{
return（IIMGENC1_EUNSUPPORTED）;
}
原来，我忘记在GPP端为outArgs指定size的值了：
outArgs.size=sizeof（outArgs）;
加上后，错误解决。
莫名奇妙死机
问题描述
这下程序应该能完美运行了吧，我兴冲冲地传入测试参数，泡杯茶（第一次运行，不知道需要多久），开始等待……
五分钟过去了……怎么还没有结果？
应该是计算量大的问题，因为我的程序里用了大量的递归，先去打会儿网球吧
不是吧，都过去了两小时，怎么还是停留在这里？
VISA_call（visa=0x3d9c8,msg=0x4115ec80）:
……
Comm_put>Enter（queue=0x6,msg=0x4115ec80）
Comm_put>return（0）
Comm_get>Enter（queue=0x10005,msg=0x42a88f14,timeout=-1）
Comm_get>return（0）
Comm_put>Enter（queue=0x0,msg=0x41159c80）
强制退出后，DSP居然死机了……
问题分析
我们知道，DM6446是双核的，GPP和DSP。
一个算法接口，在GPP和DSP端分别对应Stub和Skelton。
GPP端在Stub中通过调用VISA_call方法来执行DSP端的代码。
DSP端完成操作后，在返回。
整个过程，是基于一种“消息”传递机制的。
从上面的Trace信息中可以看出：
代码已经执行到VISA_call，但是，却没有等到DSP端返回结果，因此处于一种“死机”状态。
只是这种状态，也太令人困混了：
由于DSP端没有返回任何信息，因此，我们根本看不到DSP端的Trace信息，无法判断到底是哪里出了问题。
我编写代码有个习惯，现在VC上将代码调试通过，然后移植到DSP上。
既然代码在VC上能调试成功，说明不是程序的问题。
最大的可能是：
内存分配错误导致DSP端代码崩溃！
基于这点，我检查了代码，发现最有可能的问题是：
递归太多。
接下来，我减少了递归的数量，重新编译后，程序通过。
修改栈大小
在C、C++编程中，堆（Heap）和栈（Stack）是分配内存空间，存放数据的两个重要地点。
一般的，使用malloc或new关键字分配的内存空间保存在堆中，而局部变量、或者函数的参数，都是保存在栈中。
因此，当一个程序中递归的数量很多时，栈空间往往不够，最终造成内存溢出。
打开项目中的xs文件，修改getStackSize方法，增大栈空间（我这里将原来的1024增加为4096）：
functiongetStackSize（prog）
{
if（verbose）{
print（"gettingstacksizefor"+this.$name
+"builtforthetarget"+prog.build.target.$name
+",runningonplatform"+prog.platformName）;
}
return（4096）;
}
或者也可以修改server端的cfg文件：
Server.algs=[
{name:
"enctriangle",
mod:
ENCTRIANGLE,
groupId:
0,
threadAttrs:
{
stackSize:
4096,
stackMemId:
0,
priority:
Server.MINPRI+1
}
},
];
无法分配内存
又出问题了
解决完上述问题，似乎可以松口气，运行程序，编码，一切正常！
怀着期盼的心情，我点击了解码按钮，结果……怎么我的图片少了一大块？
经过检查，确定不是解码的问题，看来编码这块儿还是不能让人放心啊！
继续分析问题
这次比较简单，在编码的关键点加入Trace后，清楚地发现，当系统运行到某个阶段时，
pPersonperson=（pTFlat）malloc（sizeof（Person））;
返回NULL指针！
想必是堆空间不够了！
堆不够？
那就弄大点吧！
打开server工程的.cfg文件，睁大眼睛，仔细检查空间分配问题：
varmem_ext=[
{
comment:
"DDRALGHEAP:
off-chipmemoryfordynamicalgmemallocation",
name:
"DDRALGHEAP",
base:
0x82E00000,//46MB
len:
0x00a00000,//10MB
space:
"code/data"
},
{
comment:
"DDR2:
off-chipmemoryforapplicationcodeanddata",
name:
"DDR2",
base:
0x83800000,//56MB
len:
0x00600000,//6MB
space:
"code/data"
},
{
comment:
"DSPLINK:
off-chipmemoryreservedforDSPLINKcodeanddata",
name:
"DSPLINKMEM",
base:
0x83E00000,//62MB
len:
0x00100000,//1MB
space:
"code/data"
},
{
comment:
"RESET_VECTOR:
off-chipmemoryfortheresetvectortable",
name:
"RESET_VECTOR",
base:
0x83F00000,//63MB
len:
0x00000080,
space:
"code/data"
},
];
怎么可能，我们明明分配了10MB的空间给DDRALGHEAP。
继续往下看吧：
bios.DDR2.createHeap=true;
bios.DDR2.heapSize=0x20000;//128K
bios.DDRALGHEAP.createHeap=true;
bios.DDRALGHEAP.heapSize=bios.DDRALGHEAP.len;
试着修改bios.DDR2.heapSize的值，改成0×40000。
运行程序，错误解决了。
为什么是DDR2
根据上面的内存分配表，DDR2区域应该是存放算法代码、数据的，不应该具备“堆”的功能，为什么这里修改了bios.DDR2.heapSize却可以回避异常呢？
按理来说，应该是DDRALGHEAP才对。
再说，当前程序中将bios.DDR2.heapSize设置成0×40000可以，如果将来运算量多，区区256K的堆空间，不一定能用。
继续查看代码，发现cfg中设置如下：
bios.setMemCodeSections（prog,bios.DDR2）;
bios.setMemDataNoHeapSections（prog,bios.DDR2）;
bios.setMemDataHeapSections（prog,bios.DDR2）;
修改如下：
bios.setMemCodeSections（prog,bios.DDR2）;
bios.setMemDataNoHeapSections（prog,bios.DDR2）;
bios.setMemDataHeapSections（prog,bios.DDRALGHEAP）;
OK了！
无法更新outbuf
问题描述
这个问题出现在当对第二幅图像编码完成后，从DSP端传出的数值仍然是第一幅图像的编码结果。
分析
DM6446是双核处理器，GPP端和DSP端通过CMEM共享内存来传递数据。
GPP端是相对地址，DSP端是绝对地址。
二者实际上是对应不同的内存块，通过CodecEngineAPI中的Memory_cacheInv、Memory_cacheWb等函数来转换数据（相当于memcpy）。
因此，如果出现上述问题，肯定是由于在skel层没有执行相应的操作。
打开imgenc1_skel.c。
找到以下代码：
if（（pStatus->data.buf!
=NULL）&&
XDM_ISACCESSMODE_WRITE（pStatus->data.accessMask））{
Memory_cacheWb（pStatus->data.buf,pStatus->data.bufSize）;
/*
*Sincewe'vecacheWbthisbuffer,wearguablyshould
*reflectthiscachestateandcleartheWRITEbitin
*the.accessMaskfield.However,weknowthestub
*doesn'tpropogatethisfieldtothecallingapp,so
*thisextrabuffermanagementdetailisn'tnecessary:
*
*XDM_CLEARACCESSMODE_WRITE（pStatus->data.accessMask）;
*/
}
不难判断，问题出现在XDM_ISACCESSMODE_WRITE（data.accessMask）这里。
解决问题
原来，在DSP端的Skel中，MemoryAPI通过查看data.accessMask来判断该段内存是否被写过，如果写过，才将它转化成GPP端的内存，否则，跳过。
打开Codec实现文件，在更新完outBufs数据后，修改outBufs的accessMask：
/*report_how_weaccessedthe2databuffers*/
XDM_CLEARACCESSMODE_WRITE（inBufs->descs[0].accessMask）;
XDM_SETACCESSMODE_READ（inBufs->descs[0].accessMask）;
XDM_CLEARACCESSMODE_READ（outBufs->descs[0].accessMask）;
XDM_SETACCESSMODE_WRITE（outBufs->descs[0].accessMask）;
升级会员 