This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

求救:omapl138的dsp核进行UPP数据发送的时候,出现数据错位的情况,请帮忙分析下

详细情况: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信号。

请教:这可能是出现什么问题了。

  • 经过一段时间的测试,发现不是数据错位,而是0-63的数据是上次发送的值,二64-127的数据是本次的值。

    但是问题的原因还是没有找到,也没找到解决办法。

  • DSP没有做Cache一致性维护吧,在使能UPP发送前加一个Cache write back操作。

  • 有写回的。

    读写的代码如下:

    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的函数。

  • 这么说跟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) Event
    This event occurs when the DMA channel fails to keep up with incoming or outgoing data on its
    associated interface channel. Typically, this error indicates that background system activity has interfered
    with normal operation of the peripheral. It does not occur simply when a channel is allowed to idle. After
    encountering 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. To
    avoid this error, run the uPP at slower speeds or reduce background activity, such as non-uPP peripheral
    or DMA transactions. Additional tuning tips are given in Section 33.2.6.3.

    #3.3 提高uPP在系统中的优先级,并降低其它不是那么重要的master的优先级,见寄存器MSTPRI0/1/2。uPP默认优先级是4, 不妨改为最高优先级0,其它看你系统中用了哪些master外设,适当降低其优先级。

  • 出现问题时,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;但是发送到数据线上的数据是错的,会有上次发送过的部分数据。

  • 可是这个配置不是512byte,因为BCNT是指字节数。即使上面的upp_line_size对应的是BCNTH,那也只有256byte,软件中其它地方是否有对这个定义误解的地方呢,填充buffer时搞错了?

    还有在什么条件/情况下出现你说的错位?

    另外UORI是否有置1呢?

    在发送过程中ENABLE始终有效,那么说明发送也是一直有效的,不应该出现数据错位啊。

  • #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小时左右的通讯还没出现错位的情况。

  • DDR的BPPBR也要调一下(如果用的是默认值0xFF)。

    还有UPP的DMA burst size,UPTCR寄存器:

  • 经过今天的测试,upp的优先级提升到0之后没有出现过错位的情况;

    对于之前的错位数据,我的猜测是因为某个原因导致某次upp传输失败,部分数据没有传完,以至于后面每次upp传输都会将上次没传完的数据和本次的数据组合成新的一次upp数据进行传输;

    今天测试没有发现uroq和uroi为1的情况,应该是别的原因导致的upp传输错位;

    我的疑惑:为什么upp传输错误之后,后续的upp通讯数据会包含之前的部分数据;按我的理解,错了这一次就错了吧,下次还是从内存直接取数据再传就是了;

    现在这种错了一次后续再也纠正不过来了,具体upp通讯是怎么处理的,如果按照我碰到的这种情况,upp传输太不可靠了吧?

  • Anyway也算是好消息。

    这种情况应该是uPP在某个时间点由于系统loading高,DMA来不及从buffer把数据取到uPP的FIFO,而FIFO还是继续往外发数,这样FIFO的计算器还是计数,而等系统空闲过来按原来的顺序往FIFO填充数时,就对应不上了。

    在别的案例上出现过类似的问题,但是确实会检测到uroq或uroi为1的情况,而你说没有检测到,这点我就有点搞不清状况了~~~。

    如果能检测到溢出状态,那么在软件里对uPP做一个复位应该能恢复的。

  • 借这个帖子说下我遇到过的问题,看看有人遇到过没

    upp配置使能了一个通道,做测试工程使用规律数据来验证的时候,发现长时间测试时,会出现丢一个数据的问题

    不是数据错位,不是建立和保持时间的问题,而是数据凭空丢失了,例如11、12、14、15、16

    丢失的位置不在一次line传输的起始或者结束位置,而是中间位置,不会是因为控制时序导致的丢失问题

    每次丢失数据的位置不是确定的

    当时怀疑是fpga逻辑问题,仔细排查后确定逻辑没有问题,数据肯定发送出来了

    后来将两个upp都配置为接收模式,但是仍然用之前的upp通道接收数据,之后测试就没再发现问题

    现在这个产品已经量产了,没再出现过问题

    不知道是配置问题还是upp有某种条件下的bug

    ps:我们的产品是在线连续采集模式,平均带宽10MB以下,但正常情况是不会复位和重启upp的,数据流也是连续不间断的

  • luo qi 说:

    upp配置使能了一个通道,做测试工程使用规律数据来验证的时候,发现长时间测试时,会出现丢一个数据的问题

    不是数据错位,不是建立和保持时间的问题,而是数据凭空丢失了,例如11、12、14、15、16

    丢失的位置不在一次line传输的起始或者结束位置,而是中间位置,不会是因为控制时序导致的丢失问题

    每次丢失数据的位置不是确定的

    当时怀疑是fpga逻辑问题,仔细排查后确定逻辑没有问题,数据肯定发送出来了

    后来将两个upp都配置为接收模式,但是仍然用之前的upp通道接收数据,之后测试就没再发现问题

    现在这个产品已经量产了,没再出现过问题

    不知道是配置问题还是upp有某种条件下的bug

    你说两个通道都配置为输入,原来另一个通道是输出而且也是一直在发送数据码?另一个通道的也走线出来了吗?

    数据丢了后,那么uPP的数据总体上也应该乱了,比如说EOL, EOW中断肯定也不对了是吧。

    我能想到的可能性是不是uPP的时钟信号受到了干扰,比如说在某个clock受干扰,导致UPP没有识别到这个clock,从而没有采样,那么这个clock的数据肯定丢了。

    如果你愿意,看用示波器长时间监测uPP clock信号,触发条件可能需要想想,因为不知道那个受干扰的clock表现会是什么样子,是周期变长,还是辐度不够,这个你也想想吧。

  • 抱歉很久没看这个帖子了

    1.两路upp一直处于接收模式,没有配置过发送模式。刚开始测试时只打开了一路接收,另一路未配置。pcb上是有走线的。

    2.数据总体没有乱,只是数据凭空缺失了一个。因为是不间断数据流形式,因此EOL和EOW都正常。

    3.时钟信号收到干扰而导致这种现象,从理论上是存在可能性的。但是硬件条件没有改变,只是改变138的upp配置就能解决的问题,我倾向于不是干扰问题导致。

    4.使用目前的方式接收数据运行一切正常,两路upp数据很稳定,手头项目很多暂时没有时间去查,不过可以找到有问题的upp配置代码版本