[问答] 请问现在6670上BCP模块的CRC问题解决了吗,还是只能用跟软件替代?

kingnet_52003 ( 楼主 ) 2018-7-11 08:49:32  显示全部楼层
请问一下现在CRC还是只能用软件解决么,还是不能硬件得到正确答案。  我目前的情况是有软件代码,做了一下时间消耗比较大。用硬件跑时间比较少,还没工夫去对数,所以不知道能不能用?

希望有官方答案提前有个底,不然也得多花一两天去看资料和对数。谢谢!

10个回复

zbb9612 发表于 2018-7-11 08:58:12
该问题只在PG1.0上出现,在PG2.0中该问题已经修复,具体请看http://www.ti.com/lit/er/sprz332d/sprz332d.pdf advisory17
                                                                          

回复 支持 反对

举报 使用道具

kingnet_52003 发表于 2018-7-11 09:11:26
zbb9612 发表于 2018-7-11 08:58
该问题只在PG1.0上出现,在PG2.0中该问题已经修复,具体请看http://www.ti.com/lit/er/sprz332d/sprz332d.pdf advisory17
                                                                          

The page you are looking for might have been removed, had its name changed, or is temporarily unavailable.
此网页打不开!
然后请教一下我怎么知道我弄的板子是什么版本。我们用的是别人做好的成品,需要什么序号来查询这个版本问题。
谢谢!亟待回复  多有麻烦
回复 支持 反对

举报 使用道具

kingnet_52003 发表于 2018-7-11 09:22:25
kingnet_52003 发表于 2018-7-11 09:11
The page you are looking for might have been removed, had its name changed, or is temporarily unavailable.
此网页打不开!
然后请教一下我怎么知道我弄的板子是什么版本。我们用的是别人做好的成品,需要什么序号来查询这个版本问题。

再补充一下 crc输入的bit数是不是目前有限制  我这边做出来最大只支持2808*4bit的数量
回复 支持 反对

举报 使用道具

zbb9612 发表于 2018-7-11 09:37:56
kingnet_52003 发表于 2018-7-11 09:11
The page you are looking for might have been removed, had its name changed, or is temporarily unavailable.
此网页打不开!
然后请教一下我怎么知道我弄的板子是什么版本。我们用的是别人做好的成品,需要什么序号来查询这个版本问题。

版本号根据数据手册如下图示:

CRC输入长度在packet header中可配,没有你说的这个长度限制。
                                                                          

回复 支持 反对

举报 使用道具

kingnet_52003 发表于 2018-7-11 09:45:14
zbb9612 发表于 2018-7-11 09:37
版本号根据数据手册如下图示:

CRC输入长度在packet header中可配,没有你说的这个长度限制。

由于我们无法看见TI芯片表面,所以您的方法可能无法使用。
查询手册时,我们发现
Table 5-2 CorePac Revision ID Register (MM_REVID) Field Descriptions
Bit Name Value Description
31-16 VERSION xxxxh Version of the C66x CorePac implemented  on the device will depend on the silicon being used.
15-0 REVISION 0000h Revision of the C66x CorePac version implemented on this device.
End of Table 5-2
目前MM_REVID寄存器上写的是00080001h,通过这个是否能看出是1.0还是2.0版本么?..
 
谢谢Andy!
然后就是我目前输入284608bit时,header中的长度寄存器也写了的,但是输出的bit数就是2811byte,排除3byte的CRC校验位,和1byte的0,剩下就只有2808byte。您估计这问题会出现在哪里呢?
Alan
回复 支持 反对

举报 使用道具

kingnet_52003 发表于 2018-7-11 09:50:32
zbb9612 发表于 2018-7-11 09:37
版本号根据数据手册如下图示:

CRC输入长度在packet header中可配,没有你说的这个长度限制。

刚才我按照我们前辈写的报告测试了一下,果然CRC还是有限制的(而且我还测试CRC值和我们软件做出来的不一样,当然我相信硬件出来的东西错不了,这一点我再确认一下)。目前按照LTE协议,给出的数据块长度超过254328bit后,CRC模块就无法输出正确结果了!
这只是我们的测试结果,希望得到TI的证实,毕竟我觉得按照协议做LTE 4层我们测极限速率肯定最高是要达到299856bit的TB快的,很多人会遇见同样的问题。
回复 支持 反对

举报 使用道具

zbb9612 发表于 2018-7-11 10:08:31
kingnet_52003 发表于 2018-7-11 09:45
由于我们无法看见TI芯片表面,所以您的方法可能无法使用。
查询手册时,我们发现
Table 5-2 CorePac Revision ID Register (MM_REVID) Field Descriptions

查看地址0x02620018对应的寄存器JTAGID的高4bit,1-对应Rev2.0,0-Rev1.0。在C6670勘误表及数据手册中有描述。
至于你说的CRC输入长度的限制,我需要确认后答复。
                                                                          

回复 支持 反对

举报 使用道具

kingnet_52003 发表于 2018-7-11 10:24:28
zbb9612 发表于 2018-7-11 10:08
查看地址0x02620018对应的寄存器JTAGID的高4bit,1-对应Rev2.0,0-Rev1.0。在C6670勘误表及数据手册中有描述。
至于你说的CRC输入长度的限制,我需要确认后答复。
                                                                          

再次谢谢您!
回复 支持 反对

举报 使用道具

zbb9612 发表于 2018-7-11 10:35:15
kingnet_52003 发表于 2018-7-11 09:50
刚才我按照我们前辈写的报告测试了一下,果然CRC还是有限制的(而且我还测试CRC值和我们软件做出来的不一样,当然我相信硬件出来的东西错不了,这一点我再确认一下)。目前按照LTE协议,给出的数据块长度超过254328bit后,CRC模块就无法输出正确结果了!
这只是我们的测试结果,希望得到TI的证实,毕竟我觉得按照协议做LTE  ...

关于CRC输入长度,请问你是单独测试CRC,还是同时测试了多个如CRC+ENC+...,我们想确认到底是否CRC引起的问题,所以请单独测试CRC一个模块,如有问题请把相应的描述符及CRC配置发上来看看,谢谢。
                                                                          

回复 支持 反对

举报 使用道具

kingnet_52003 发表于 2018-7-11 10:50:27
zbb9612 发表于 2018-7-11 10:35
关于CRC输入长度,请问你是单独测试CRC,还是同时测试了多个如CRC+ENC+...,我们想确认到底是否CRC引起的问题,所以请单独测试CRC一个模块,如有问题请把相应的描述符及CRC配置发上来看看,谢谢。
                                                                          

目前测试这个长度问题就是单独测试CRC这一个子模块,其他模块都不测试。这样出现的结果就是超出一定长度后,就不能返回正确的数据(我指的是原数据+3byte CRC数值)。
目前我的测试前提是仅有CRC和必要的global和TM,输入超出长度的bit数;
结果是在返回数据的长度和应该输出的长度相,比变小了。原数据少了很多,但是还是有CRC的3byte(我就没有去检测这3Byte对不对了,这个不好意思)。
另外我在继续测试的过程中又遇见了两个小问题:
1.  在帖子http://www.deyisupport.com/question_answer/dsp_arm/c6000_multicore/f/53/p/14291/49888.aspx#49888中,您说到
   rxCfg.tmFlowCfg.endian_in           =   Bcp_EndianFormat_32;
   rxCfg.tmFlowCfg.endian_out          =   Bcp_EndianFormat_32;
输入数据在128bit内以32bit为单位进行了交换,如w3w2w1w0输入到BCP后为w0w1w2w3,所以在软件在进行CRC之前需要做相应的转换,CRC之后还需要交换过来,然后送入BCP。
但是为什么软件做的时候,CRC的结果还要交换顺序?
(9.29修改)您说的交换方式和代码里说的也不一样 代码是:
   /* Re-order bits as expected by CRC function */
    for (i=0;i<tbSize/8;i++)
     tempBuf = _extu(_bitr(pDataBufferPayload), 0, 24);
您说的在datasheet里叫做bit swap ,但是代码里写的叫做 bit reverse,两种方式在data format中也是不一样的。
   /* Re-order bits as expected by BCP and then append */
    for (i=0;i<3;i++)
     pDataBufferPayload[tbSize/8 + i] = _extu(_bitr(((crcBits >> ((3-1-i)*8)) & 0xFF)), 0, 24);
在CRC输出的时候,bit swap (向右移位那里)和  bit reverse((_bitr)都有,这又是为什么呢?
我们在matlab上用xor的方式(xor模拟编码器的方式,这样从低地址输入数据就该没问题了)做的结果就和不进行128bit交换的结果是一样的。
所以这一点还是请Andy 指导一下。
2. 在帖子http://www.deyisupport.com/question_answer/dsp_arm/c6000_multicore/f/53/p/14166/48718.aspx#48718中,
我按照您所说的问题一,修正了
eventId     =   49 + CSL_chipReadReg (CSL_CHIP_DNUM);为
eventId     =   49; 即不需要加上coreID,这个事件对每个核是一样的;
  但是仍然有问题。
我的测试方法是修改后只跑core#1,不跑core#0.
( 9.28修改 当然什么初始化我在core 1 也是做了的,但是现在感觉可能就是初始化没做对,可是fftc的初始化我改到core1就是没问题的啊   why?MN搞不太懂了)
(9.28 第二次修改  刚才又使用例程跑了一遍,在core0 做初始化,core1直接rxchannel_open就是可以的。意思就是core 0做了Bcp_rxOpen后,core 1做Bcp_rxOpen才能成功,否则就不行!!!!!!现在证明:在core 0还是core 1做初始化没影响,但是core0 必须先做Bcp_rxOpen!!!!估计原因就是CPPI初始化的问题了。我下一步该怎么修改才行了! 继续求助!)
(9.29第二次修改  为什么我按照帖子里的方法修改后,能跑过Bcp_rxOpen语句后,第二个核居然出现了和帖子里一样的问题,core1收不到中断,按照帖子里的房屋无法解决!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!)
(9.29修改  应用中 每个核都会用上MN的情况,请问还需要每个核都做qmss和cppi的初始化么,还是在core0做一次就好了?我觉得是在core0 做一次就好,但是需要注意点什么么,我这边还没有成功的经验,谢谢)
遇见的问题是:
跑到Bcp_rxOpen函数后         if ((hCppiRxChan = Cppi_rxChannelOpen (gBcp_instanceInfo[instNum].hCppi,
                                               &rxChInitCfg,
                                               &isAllocated)) == NULL)
        [
            Bcp_osalLog ("Error opening Rx channel: %d \n", rxChInitCfg.channelNum);
            goto return_error;
        ]
显示错误。
-------------- LTE DL Test Start --------------
Rx FDQ 736 successfully setup with 1 descriptors
Error opening Rx channel: 1
BCP Rx Open failed
希望能得到您的解答!
明天我会继续调试,如果进展及时汇报到论坛
多有麻烦! 谢谢Andy!
回复 支持 反对

举报 使用道具

您需要登录后才可以回帖 登录 | 注册

本版积分规则


关闭

站长推荐上一条 /9 下一条

小黑屋|手机版|Archiver|电子发烧友 ( 粤ICP备14022951号-2 )

GMT+8, 2018-9-25 20:37 , Processed in 0.852120 second(s), 22 queries , Memcache On.

Powered by 电子发烧友网

© 2015 bbs.elecfans.com

微信扫描
快速回复 返回顶部 返回列表