TI中文支持网在核0的代码中，有一个函数定义了下面这个比较大的局部数组，原本核1正常工作的UPP会总是卡在UPQS2的PEND位，该位一直为1。（UPP工作在双工方式，Q路是接收）。核0与核1是两套完全分开的代码。
int8_t path_record[64][464];
可以确认堆栈申请的足够大，不是堆栈溢出的问题，系统也没有提示堆栈溢出。
把CORE0的堆栈分配从DDR移到L2SRAM，系统可以正常工作。或者在变量申明前增加static，系统也可以正常工作。
核1UPP卡住后，从UPP的寄存器看，都是系统初化时设置的值，并没有被越界改写过。为什么核1的UPP，会被核0的内存分配影响，是什么原因？要从哪里入手，请指点一二，多谢。
Shine：
请尝试把UPP的System Priority调高，请参考2.6.3 System Tuning Tips
www.ti.com/…/spruhg9.pdf
,
user6488365：
UPP的优先级已经是最高了：EMAC_UPP_PRI_ALLOC = 0x6070000;
,
Tony Tang：
Pend位为1表示UPP DMA的配置没有active，也就是说uPP没有开始工作。这是这个接口层级的事，跟代码没有关系。如果是接收，那么对方是否有开始发送，只有收到对方发出的start，clock才会开始接收。
我觉得跟heap以及软件没什么关系。
或者停止core0，core1的uPP能工作吗？
,
user6488365：
单独运行CORE1，UPP工作正常。此时再运行CORE0，核1 UPP又卡在同一个地方。
测试过好多次都是这样。
,
user6488365：
又做了一些新的测试，请帮忙分析一下：
我创建了一个新的工程，运行在核0上，新的工程只做一件简单的事情：把500K的DDR内存按字节设置为0。先把核1程序运行起来，UPP工作正常，再运行核0，UPP立即卡死，UPQS2（接收）一直等于0X83。我的疑问：CORE0长时间占用总线，导致UPP无法访问内存，但UPP为什么不给出WAIT信号？我们从来没有监测到UPP给出的WAIT信号。
