打印

CRC误判?RAM局部出错?

[复制链接]
6114|18
手机看帖
扫描二维码
随时随地手机跟帖
跳转到指定楼层
楼主
kbgyzp|  楼主 | 2010-3-4 15:28 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
CRC16校验的误判的概率有多大? 单片机内存出错的概率有多大?

我一组数据,连同CRC值一起存到了铁电里,当CPU上电时,我要把存在铁电的数据导入到RAM中,在导入到RAM的过程中,如果判定数据的CRC校验正确,会直接导入到RAM中,如果判定数据的CRC校验不正确,会把RAM的数据从新初始化新值,并从新把初始化的数据写到铁电里。
可偶尔发生了一次上电后RAM的值既不是初始化的新值,也不是保存的正常值,而是乱七八糟的数据。
我现在不知道是怎么造成的。
1.从铁电中读数据时,没有读正确,但通过了CRC校验。
2.RAM数据局部被干扰导致变量数据损坏了,但没影响CPU的正常运行。
出错原因只有这两种可能,但概率很小,无法模拟。希望各位高手发表高见。

相关帖子

沙发
yewuyi| | 2010-3-4 15:54 | 只看该作者
请问出现的概率大约是多少?!

CRC16出错的概率基本可忽略不计了。

还是尽量检查你的CODE有没有问题把。

使用特权

评论回复
板凳
流行音乐| | 2010-3-4 16:53 | 只看该作者
如果错误的数据也能通过CRC16校验,则应该使用CRC32。

使用特权

评论回复
地板
kbgyzp|  楼主 | 2010-3-4 17:34 | 只看该作者
本帖最后由 kbgyzp 于 2010-3-4 17:41 编辑

回叶工,出错的概率很小,5000只设备一年多的时间内也就发现了个别设备出现了一两次这种情况。

使用特权

评论回复
5
kbgyzp|  楼主 | 2010-3-4 17:40 | 只看该作者
我也认为代码的原因,也检查了代码,没发现指针指错,数组溢出等影响内存的情况。
这种情况出现在刚上电的时候。
概率太小了,无法模拟。

使用特权

评论回复
6
kbgyzp|  楼主 | 2010-3-4 17:42 | 只看该作者
现在无法验证是否是错误的数据也能通过CRC16校验

使用特权

评论回复
7
kbgyzp|  楼主 | 2010-3-4 17:55 | 只看该作者
各位认为RAM受到干扰局部数据出错而程序正常运行的可能性大吗?我认为不大可能,但公司很多人认为可能。

使用特权

评论回复
8
流行音乐| | 2010-3-4 19:39 | 只看该作者
现在无法验证是否是错误的数据也能通过CRC16校验
kbgyzp 发表于 2010-3-4 17:42


你把错误的数据读出用CRC16校验一下就可以验证了。

使用特权

评论回复
9
流行音乐| | 2010-3-4 19:43 | 只看该作者
各位认为RAM受到干扰局部数据出错而程序正常运行的可能性大吗?我认为不大可能,但公司很多人认为可能。
kbgyzp 发表于 2010-3-4 17:55

如果RAM中的数据出错后变成另外一个合法数据,则程序仍然可以正常运行。可能性大小与程序有关。

使用特权

评论回复
10
kbgyzp|  楼主 | 2010-3-4 22:18 | 只看该作者
本帖最后由 kbgyzp 于 2010-3-4 22:21 编辑

这个问题当时不是我发现的,我知道时他们已经把部分数据通过按键改过来了,所以无法把错误的数据读出用CRC16校验一下了。

使用特权

评论回复
11
kbgyzp|  楼主 | 2010-3-4 22:31 | 只看该作者
如果RAM中的数据出错后变成另外一个合法数据,则程序仍然可以正常运行。可能性大小与程序有关。
-----------------------------------------------------------------------------------------------------------
我对待这种问题的态度一直都是先从自身程序找原因。数据被改写可能是操作别的数据时可能指针等溢出改写了这个地方RAM的数据,但如果是这样的话这么多设备在这么长时间才出现一两次概率也太小了,而且是每一批都经过了严格的测试。我也仔细排查了程序的原因,没发现什么bug。

我感觉RAM 也不大容易值得怀疑,因为这是ARM芯片,全是精简指令集,不是像51那样这么多指令,还和数据分不开,程序不太容易跑飞。

使用特权

评论回复
12
李冬发| | 2010-3-4 22:31 | 只看该作者
CRC16,出错的概率就是1/65536

使用特权

评论回复
13
kbgyzp|  楼主 | 2010-3-4 23:17 | 只看该作者
CRC16,出错的概率就是1/65536
李冬发 发表于 2010-3-4 22:31


1/65536,这么说出错的概率够高的啊。不知楼上怎么得到的这个概率结果?

使用特权

评论回复
14
yewuyi| | 2010-3-5 08:35 | 只看该作者
呵呵,似乎不能按照1/65536计算,如果按照这个计算的话,那么两字节的和校验是不是也是1/65535呢?

使用特权

评论回复
15
HWM| | 2010-3-5 09:16 | 只看该作者
CRC - 16 检验最后得到一个16位的检验结果,通常为零正确而非零错误。如果由干扰而成的错误码是等概率出现的(包含正确码)话,误判率为1/65536。但通常误码(含正确码)的能谱是不一样的。无干扰码(即正确码)干扰能谱为零,而随着错位增加能谱增高。因此,在一定的干扰强度下,误码(含正确码)的出现概率是不同的。正确码出现的概率最高,而“误判码”(检验结果回归到零)出现的概率最低。因此“误判码”的出现总概率要远小于1/65536,而正确码的出现概率远大于1/65536(通常情况下几乎为1,因为干扰强度很低)。这也是符合我们的经验的。

使用特权

评论回复
16
lhj200304| | 2010-3-5 11:12 | 只看该作者
我是在运行过程中一直在做crc检测,一出错马上处理重要参数,crc初始值不要用0

使用特权

评论回复
17
BitFu| | 2010-3-5 11:16 | 只看该作者
crc出现误判的几率及小,可以认为不可能
RAM改变的可能性及大,但是一上电就发生的可能性及小
所以,检查你的CODE(如栈,变量改写)

使用特权

评论回复
18
magic1983| | 2010-3-6 15:45 | 只看该作者
能不能在铁电里不同的地方再备份一下呢?
铁电的两组数据比较一下,如果两组相同,从铁电读入,要是不同,再初始化RAM。
这样几率应该是更小了吧。

使用特权

评论回复
19
李冬发| | 2010-3-16 06:24 | 只看该作者
1/65536是极限,其实CRC16达不到这个值的,更不可能比这更高的了。
hash序列的碰撞就是这样的,要提高只有加长冗余位!
两字节的和校验,更不均匀,远达不到1/65536。

使用特权

评论回复
发新帖 我要提问
您需要登录后才可以回帖 登录 | 注册

本版积分规则

53

主题

473

帖子

1

粉丝