您的位置: OpenADSP社区论坛 -> Blackfin专区 -> 新手上路 -> BF561 乒乓发送中断问题
本帖共有783个阅读者
发表帖子 发表投票 回复主题
BF561 乒乓发送中断问题
liuhai2200(论坛新手)
liuhai2200
头衔:社区公民
帮派:无帮无派
帖数:69
金钱:636
积分:84
注册时间:2012/8/12
楼主信息 | 留言 | Email | 主页 | 编辑 | 管理 | 离线
BF561 乒乓发送中断问题
在BF561的COREB中用SPORT1口乒乓接收数据,数据处理完后(一帧数据处理时间低于接收一帧数据的时间)再使用SPORT0把数据乒乓搬出去(乒乓发送一帧数据的时间与接收一帧数据的时间是一致的),上述数据搬移均采用DMA实现,软件中设定SPORT1的中断优先级高于SPORT0的优先级,问题是程序一开始跑还是正常的,但过一段时间,SPORT0的中断就完全进不去了,看了寄存器中的excuse也没有什么问题,SPORT1的数据接收还是正常,这可能的原因是什么?
  麻烦andy给点思路哪。

完成梦想
等级:论坛新手 参考IP地址:*.*.*.*
2014/4/28 20:36:13
liuhai2200(论坛新手)
liuhai2200
头衔:社区公民
帮派:无帮无派
帖数:69
金钱:636
积分:84
注册时间:2012/8/12
1信息 | 留言 | Email | 主页 | 编辑 | 管理 | 离线

还有一个疑问:目前用BF561的SPORT0口连接CODEC芯片,在COREA中用SPORT0的TX完成CODEC的初始化后,再在COREB中延时一段时间利用SPORT0 TX完成CODEC的数据发送,像这种情况,CORE A使用完后COREB再对SPORT0 TX进行数据发送是否有问题?

目前调试发现COREA的SPORT0 的RX (使用乒乓接收),它的运行会对COREB的SPORT0的TX造成影响,但是它们的寄存器都是独立配置的,DMA也是独立的,CORE A COREB的中断系统也是独立的,不知道原因是什么?

麻烦andy提供点思路。谢谢!




「该帖子被 liuhai2200 在 2014-04-29 22:35:26 编辑过」

完成梦想
等级:论坛新手 参考IP地址:*.*.*.*
2014/4/29 21:00:00
尊贵身份标志
andy(论坛版主)
andy
头衔:社区公民
帮派:无帮无派
帖数:2287
金钱:11132
积分:2263
注册时间:2011/6/8
2信息 | 留言 | Email | 主页 | 编辑 | 管理 | 离线
应该是两个中断干扰了,建议一次只使能一个中断,否则可能会出现其中一个中断进不去的情况。
没有问题。中断系统虽然独立,但同时开2个中断,可能会发生影响,建议在使用完一个中断后,将其关闭,然后再打开另一个中断。


这家伙很懒,什么也没有留下!
等级:论坛版主 参考IP地址:*.*.*.*
2014/4/30 9:23:45
liuhai2200(论坛新手)
liuhai2200
头衔:社区公民
帮派:无帮无派
帖数:69
金钱:636
积分:84
注册时间:2012/8/12
3信息 | 留言 | Email | 主页 | 编辑 | 管理 | 离线
andy,你好,现在问题是COREA COREB是并发运行的,如果一个核只使用一个中断那样可能会影响系统的效率和实时性,像我在COREA里也使用了其他的中断,几个中断在一起貌似是没有影响的。

完成梦想
等级:论坛新手 参考IP地址:*.*.*.*
2014/4/30 11:05:09
尊贵身份标志
andy(论坛版主)
andy
头衔:社区公民
帮派:无帮无派
帖数:2287
金钱:11132
积分:2263
注册时间:2011/6/8
4信息 | 留言 | Email | 主页 | 编辑 | 管理 | 离线
你运行代码,当出现不进入中断时,停下代码,查看相关DMA寄存器,看看状态值是否正常。单独运行这个核,看是否还能进中断。两个核交替单步,看看工作是否正常。


这家伙很懒,什么也没有留下!
等级:论坛版主 参考IP地址:*.*.*.*
2014/5/1 9:33:12
liuhai2200(论坛新手)
liuhai2200
头衔:社区公民
帮派:无帮无派
帖数:69
金钱:636
积分:84
注册时间:2012/8/12
5信息 | 留言 | Email | 主页 | 编辑 | 管理 | 离线
andy,你好!当COREB的SPORT0的TX不出现中断时,查看了DMA和SPORT0的寄存器,没发现什么异常,现在的现象是如果把COREA中SPORT0的RX屏蔽掉的话就没有问题,
更确切的说如果将SPORT0 RX接收一乒数据进行处理的函数屏蔽掉的话,只保留清楚标志位的表达式就不会有什么问题,这个问题很是诡异!
难道是我处理一乒的数据时间太长了?但是我现在一乒数据的处理时间还是远小于一乒数据的时间长度的。

完成梦想
等级:论坛新手 参考IP地址:*.*.*.*
2014/5/5 9:35:58
尊贵身份标志
andy(论坛版主)
andy
头衔:社区公民
帮派:无帮无派
帖数:2287
金钱:11132
积分:2263
注册时间:2011/6/8
6信息 | 留言 | Email | 主页 | 编辑 | 管理 | 离线
你这样试试,你用delay函数代替你屏蔽掉的处理代码。逐渐增加延时时间,看看延时增加到多少时,会不正常。然后看看cycles寄存器的值,占用了多少时间。再比较一下你的处理函数的时间。
看一个函数的处理时间,不要单步一次执行看,最好是连续执行100次以上,把这些值保存起来,再查看,因为每次执行的时间可能会有所不同。

延时函数前面加上关闭优化开关语句:#pragma optimize_off
以防止系统自动优化。

这家伙很懒,什么也没有留下!
等级:论坛版主 参考IP地址:*.*.*.*
2014/5/5 13:06:57
liuhai2200(论坛新手)
liuhai2200
头衔:社区公民
帮派:无帮无派
帖数:69
金钱:636
积分:84
注册时间:2012/8/12
7信息 | 留言 | Email | 主页 | 编辑 | 管理 | 离线
andy,你好,我把我现在的问题再仔细地阐述一下。

图是我们大概的系统框图,下面是我们的运行流程:

CORE A在上电的时候,使用SPORT0的TX对CODEC进行初始化,然后使用SPORT0的RX对CODEC的数据进行乒乓接收;

CORE B启动后,延时1s时间(为了避免与CORE A的SPORTO TX配置冲突),然后使用SPORT0的TX给CODEC发固定的数据,代码中我发的是1k的正弦信号,这样的话耳机端是能够听到这个声音的,目前在CORE B中只有用SPORT0 TX发送数据;

SPORT0 TX和RX都是使用DMA进行乒乓数据搬移的。

问题:

一开始的时候CORE A、CORE B运行都还正常,但跑了一段时间后(这个时间没有规律,有长有短),CORE
B就不能进入乒乓发送的中断,耳机那边也听不到声音了,查看CORE B中的SPORT0 TX的寄存器及DMA的寄存器也没发现异常,CORE A的SPORT0的乒乓接收还是正常的。

如果在CORE A中将SPORT0 RX完全屏蔽掉的话,CORE B那边发送数据都很正常,不会出现“跑飞”现象;



上传的图片
  2014581557787.jpg [ 16.83 KB 572×470 ] (缩略时请点击查看原图)

 



「该帖子被 liuhai2200 在 2014-05-08 15:57:10 编辑过」

完成梦想
等级:论坛新手 参考IP地址:*.*.*.*
2014/5/8 15:55:41
liuhai2200(论坛新手)
liuhai2200
头衔:社区公民
帮派:无帮无派
帖数:69
金钱:636
积分:84
注册时间:2012/8/12
8信息 | 留言 | Email | 主页 | 编辑 | 管理 | 离线
个人调试总结:总感觉是CORE A中SPORT0的RX影响了CORE B的SPORT0的TX,因为完全屏蔽掉CORE A中SPORT0的RX,CORE B的SPORT0 TX就很正常。但实际中CORE A和CORE B完全是两个内核,中断系统应该也是独立的,不应该有问题。
BF561的中断是两级的,我在SICA_ISR0中能看到SPORT0 TX的中断标志,同样在SICB_ISR0中能看到SPORT0 RX的中断标志,它们这是SIC(系统级)的,但在内核级上SICA_IMASK0中只有SPORT0 RX未被屏蔽,SICB_IMASK0中只有SPORT0 TX未被屏蔽,那个对内核中断应该没什么影响吧,不知道这样理解对不对?
另外,在CORE B SPORT0 TX不发送数据的时候,我用示波器看过,CODEC的时钟都是正常的。



完成梦想
等级:论坛新手 参考IP地址:*.*.*.*
2014/5/8 16:06:32
尊贵身份标志
andy(论坛版主)
andy
头衔:社区公民
帮派:无帮无派
帖数:2287
金钱:11132
积分:2263
注册时间:2011/6/8
9信息 | 留言 | Email | 主页 | 编辑 | 管理 | 离线
虽然是两个核,但你操作的是同一个接口,
建议换一种机制,芯片资源冲突只能想办法避开。建议把其中一个改为查询法。

这家伙很懒,什么也没有留下!
等级:论坛版主 参考IP地址:*.*.*.*
2014/5/11 21:41:59
Powered by OpenADSP Copyright © 2010 www.Openadsp.com. All rights reserved.159238 Call, 1 Queries, Processed in 0.078125 second(s),