完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
请问一下现在CRC还是只能用软件解决么,还是不能硬件得到正确答案。 我目前的情况是有软件代码,做了一下时间消耗比较大。用硬件跑时间比较少,还没工夫去对数,所以不知道能不能用?
希望有官方答案提前有个底,不然也得多花一两天去看资料和对数。谢谢! |
|
相关推荐
10 个讨论
|
|
zbb9612 发表于 2018-7-11 08:58 The page you are looking for might have been removed, had its name changed, or is temporarily unavailable. 此网页打不开! 然后请教一下我怎么知道我弄的板子是什么版本。我们用的是别人做好的成品,需要什么序号来查询这个版本问题。 谢谢!亟待回复 多有麻烦 |
|
|
|
|
|
由于我们无法看见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 |
|
|
|
|
|
刚才我按照我们前辈写的报告测试了一下,果然CRC还是有限制的(而且我还测试CRC值和我们软件做出来的不一样,当然我相信硬件出来的东西错不了,这一点我再确认一下)。目前按照LTE协议,给出的数据块长度超过254328bit后,CRC模块就无法输出正确结果了! 这只是我们的测试结果,希望得到TI的证实,毕竟我觉得按照协议做LTE 4层我们测极限速率肯定最高是要达到299856bit的TB快的,很多人会遇见同样的问题。 |
|
|
|
|
|
kingnet_52003 发表于 2018-7-11 09:50 关于CRC输入长度,请问你是单独测试CRC,还是同时测试了多个如CRC+ENC+...,我们想确认到底是否CRC引起的问题,所以请单独测试CRC一个模块,如有问题请把相应的描述符及CRC配置发上来看看,谢谢。 |
|
|
|
|
|
zbb9612 发表于 2018-7-11 10:35 目前测试这个长度问题就是单独测试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 您说的在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! |
|
|
|
|
|
只有小组成员才能发言,加入小组>>
TMS320F28377D:新做了以377d为芯片的板子,上电后芯片复位引脚出现方波请问如何解决?
1888 浏览 0 评论
TPS55340通电后输入端保险丝烧断,芯片输入和GND之间短路
3641 浏览 4 评论
5027 浏览 0 评论
请问如何用DM368对RGB格式的图片数据进行编码生成JPEG格式图片?
1732 浏览 1 评论
9353 浏览 8 评论
CC3100BOOST使用CC3200lunchXL进行烧录
664浏览 2评论
707浏览 1评论
TMS320F28034: 利用C2prog通过SCI给TMS320F28034烧录程序,出现错误提示:Bootloading... failed (invalid echo)!
668浏览 1评论
1186浏览 1评论
求DLPC350 Programmer’s Guide User's Guide 中文版说明书
1189浏览 1评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-4-18 16:38 , Processed in 0.786199 second(s), Total 72, Slave 57 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号