TI中文支持网详细情况：linux系统下由arm控制dsp通过upp往fpga发送数据，程序运行过程中，upp数据发送正常，由arm控制dsp不停的启动，停止upp数据发送；在某一次发送时出现数据错位（通过fpga从数据总线抓取数据），然后fpga接受的数据都是错位的，重新加载dsp程序也无法恢复fpga接受正常数据，重启上电L138后再运行dsp程序upp的数据恢复正常。通过dlb寄存器进行BA回环发现错误的数据情况如下：发送缓冲的数据顺序是1~128，但是回环到A通道，收到的数据是64~128,0~63。在测试过程中仿真器查看到UPQD0-2的值跟正常时一样，发送区数据顺序正确 。
upp发送数据是开了个中断，以40us的间隔往fpga送1行512字节的数据，中断是由fpga通过gpio脚提供的但dsp可以控制fpga是否启动中断，arm通过dsp来不停的启动和停止中断送数据；
发送时钟设置为37.5M，传输为b通道16bit传输，实际测量upp发送的enable信号持续大概7us；中间fpga没送wait信号。
请教：这可能是出现什么问题了。
david leo：
经过一段时间的测试，发现不是数据错位，而是0-63的数据是上次发送的值，二64-127的数据是本次的值。
但是问题的原因还是没有找到，也没找到解决办法。
Tony Tang：
回复 david leo:
DSP没有做Cache一致性维护吧，在使能UPP发送前加一个Cache write back操作。
david leo：
回复 Tony Tang:
有写回的。
读写的代码如下：
CacheWB ((unsigned int)upp_buffer_s, sizeof(upp_buffer_s));CacheWB ((unsigned int)upp_buffer_r, sizeof(upp_buffer_r));
upp_dma_receivestart();upp_dma_sendstart();CacheInv ((unsigned int)upp_buffer_r, sizeof(upp_buffer_r));
upp通讯的：
#define upp_dma_receivestart() \ upp_reg_hdl->UPID0 = (Uint32)upp_buffer_r; \ upp_reg_hdl->UPID1 = ((Uint32)upp_line_count_r << 16) | (Uint32)upp_line_size*sizeof(Int32); \ upp_reg_hdl->UPID2 = (Uint32)0 * sizeof(Int32);#define upp_dma_sendstart() \ upp_reg_hdl->UPQD0 = (Uint32)upp_buffer_s; \ upp_reg_hdl->UPQD1 = ((Uint32)upp_line_count_s << 16) | (Uint32)upp_line_size*sizeof(Int32); \ upp_reg_hdl->UPQD2 = (Uint32)upp_line_offset_s * sizeof(Int32);
CacheWB 是用的startware里dspcache.h的函数。
Tony Tang：
回复 david leo:
这么说跟Cache无关了，不过上面的CacheInv操作看上去没什么必要。
从第一贴说的loopback也有问题来看，那么应该是系统loading导致的overflow/underrun的问题了。
#1. 出现问题时，检查UPISR[UORQ]看是否置位，以确定是否产生overflow/underrun了。
#2. 如果是：
#2.1 调整一下DDR的寄存器PBBPR的值，根据TRM手册的章节说明：15.4.8 Peripheral Bus Burst Priority Register (PBBPR)
#2.2 根据uPP章节，适当调整一下uPP的时钟频率（降低），如果一个窗口是多行，那么将行数减少，line size增大。
33.2.8.4 Underrun or Overflow (UOR) EventThis event occurs when the DMA channel fails to keep up with incoming or outgoing data on itsassociated interface channel. Typically, this error indicates that background system activity has interferedwith normal operation of the peripheral. It does not occur simply when a channel is allowed to idle. Afterencountering this error, the uPP peripheral should be reset when this event occurs.This error should primarily occur when operating the uPP at high speed with significant system loading. Toavoid this error, run the uPP at slower speeds or reduce background activity, such as non-uPP peripheralor DMA transactions. Additional tuning tips are given in Section 33.2.6.3.
#3.3 提高uPP在系统中的优先级，并降低其它不是那么重要的master的优先级，见寄存器MSTPRI0/1/2。uPP默认优先级是4, 不妨改为最高优先级0，其它看你系统中用了哪些master外设，适当降低其优先级。
david leo：
回复 Tony Tang:
出现问题时，UPISR[UORQ]的值为0；
数据定义如下（总共128*4Byte，定义为1行）：
#define upp_line_size (128)#define upp_line_count_s (1)#define upp_line_count_r (1)#define upp_frame_size_s (upp_line_size * upp_line_count_s)#define upp_frame_size_r (upp_line_size * upp_line_count_r)#define upp_line_offset_s (upp_line_size)#define upp_line_offset_r (upp_line_size)
通过示波器实际测量到upp传输时间为7us左右（enable信号），发送过程中enable信号始终有效没有变低，与从data数据线上收到数据的时间一致，data数据线上的数据与回环A通道收到的数据一致；发送前都有判断pend位，pend位为0时才发送。
目前的问题就在于，发送区的数据顺序正确，UPQD0-2里相关的地址，长度值也对，UPISR[EOWQ]每次发送完也会正常产生，UPISR[UORQ]的值每次发送前后为0；但是发送到数据线上的数据是错的，会有上次发送过的部分数据。
Tony Tang：
回复 david leo:
可是这个配置不是512byte，因为BCNT是指字节数。即使上面的upp_line_size对应的是BCNTH，那也只有256byte，软件中其它地方是否有对这个定义误解的地方呢，填充buffer时搞错了？
还有在什么条件/情况下出现你说的错位？
另外UORI是否有置1呢？
在发送过程中ENABLE始终有效，那么说明发送也是一直有效的，不应该出现数据错位啊。
david leo：
回复 Tony Tang:
#pragma DATA_ALIGN(upp_buffer_s, 8)#pragma DATA_ALIGN(upp_buffer_r, 8)volatile Uint32 upp_buffer_s[upp_frame_size_s];volatile Uint32 upp_buffer_r[upp_frame_size_s];
因为定义的是32位的数据，128个数据算起来应该是512byte。
在原来测试的时候，还出现过一种用slaveload dsp程序的时候会导致upp数据传输错位的情况；
UORI的值在传输过程前后一直为0；
之前测试的情况，UPTCR中的TXSIZE的值改为256字节，upp正确通讯的时间会长一些，但是长时间还是会导致错位的情况；
现在按照你之前的建议更改了MSTPRI0的upp优先级（改为0），在今天的测试情况来看，连续1小时左右的通讯还没出现错位的情况。
Tony Tang：
回复 david leo:
DDR的BPPBR也要调一下（如果用的是默认值0xFF)。
还有UPP的DMA burst size，UPTCR寄存器：
david leo：
回复 Tony Tang:
经过今天的测试，upp的优先级提升到0之后没有出现过错位的情况；
对于之前的错位数据，我的猜测是因为某个原因导致某次upp传输失败，部分数据没有传完，以至于后面每次upp传输都会将上次没传完的数据和本次的数据组合成新的一次upp数据进行传输；
今天测试没有发现uroq和uroi为1的情况，应该是别的原因导致的upp传输错位；
我的疑惑：为什么upp传输错误之后，后续的upp通讯数据会包含之前的部分数据；按我的理解，错了这一次就错了吧，下次还是从内存直接取数据再传就是了；
现在这种错了一次后续再也纠正不过来了，具体upp通讯是怎么处理的，如果按照我碰到的这种情况，upp传输太不可靠了吧？
Tony Tang：
回复 david leo:
Anyway也算是好消息。
这种情况应该是uPP在某个时间点由于系统loading高，DMA来不及从buffer把数据取到uPP的FIFO，而FIFO还是继续往外发数，这样FIFO的计算器还是计数，而等系统空闲过来按原来的顺序往FIFO填充数时，就对应不上了。
在别的案例上出现过类似的问题，但是确实会检测到uroq或uroi为1的情况，而你说没有检测到，这点我就有点搞不清状况了~~~。
如果能检测到溢出状态，那么在软件里对uPP做一个复位应该能恢复的。
