楼主: longdelu

[已解决] LPC 824 I2C问题

[复制链接]

该用户从未签到

712

主题

6371

帖子

0

超级版主

Rank: 8Rank: 8

积分
24891
最后登录
2025-7-21
发表于 2016-11-11 13:59:32 | 显示全部楼层
longdelu 发表于 2016-11-11 13:44
想说,产生这种的现像的原因多是由硬件方面引起的对吗?或者说使用较小的电阻可以避免这个问题产生? ...

外部硬件肯定是有影响的,尤其这种极限情况下。
你先用1.2Kdebug测试,如果有问题,你再告诉我。
我这边debug跑到现在,上拉2.2K没有问题。前提,外部不挂其他的测试设备。
回复 支持 反对

使用道具 举报

该用户从未签到

712

主题

6371

帖子

0

超级版主

Rank: 8Rank: 8

积分
24891
最后登录
2025-7-21
发表于 2016-11-11 14:17:22 | 显示全部楼层
本帖最后由 小恩GG 于 2016-11-11 15:54 编辑

楼主你好!
我看到你在community里面说,遇到问题的时候: I2C Status register MSTPENDING BIT is 0 always or  MSTSTATE is  NACK Address/NACK Data  
所以,建议你代码里面加上如果主机接收到NACK之后,退出,并且发送start重新开始。用if去判断,而不是用while在那死等。
具体可以参考user manual。
30.jpg
楼主,如果你要使用查询方式,你的代码请按照user manual34章去写,尤其在查询I2C_STAT_MSTSTATE状态的时候,用if去判断,如果不正确,那么放弃该次I2C通信,重新开始,不要死等,我看了你代码中很多死等的,甚至有一个如果状态不是你期望的状态,你在里面加了while(1),这种情况是很不利于软件恢复的。

通信不可能期望所有情况下都能够正确通信成功,如果一旦通信不成功,比如你发地址或数据,期望从机给你ACK,但是实际从机给你NACK了,不是你想要的情况,也就是实际数据通信失败,你软件就会死等,造成死机。
综上,两点建议:
1. 硬件方面,上拉修改为1.2K
2.代码大修整,采用中断,或者官方user manual推荐的查询代码,尤其针对I2C_STAT_MSTSTATE状态的查询,不要用while死等,用if判断,如果不是想要的,退出,发送stop,再发送start重新开始建立通信。
最好加上出错机制计数,比如出错一旦太多次数,可以选择放弃,或者继续尝试连接。


回复 支持 反对

使用道具 举报

该用户从未签到

2

主题

39

帖子

0

注册会员

Rank: 2

积分
103
最后登录
2021-1-27
 楼主| 发表于 2016-11-11 14:43:48 | 显示全部楼层
小恩GG 发表于 2016-11-11 14:17
楼主你好!
我看到你在community里面说,遇到问题的时候: I2C Status register MSTPENDING BIT is 0 alway ...

好的,我会考虑你的意见,谢谢你的回复
回复 支持 反对

使用道具 举报

该用户从未签到

2

主题

39

帖子

0

注册会员

Rank: 2

积分
103
最后登录
2021-1-27
 楼主| 发表于 2016-11-11 14:51:41 | 显示全部楼层
小恩GG 发表于 2016-11-11 13:59
外部硬件肯定是有影响的,尤其这种极限情况下。
你先用1.2Kdebug测试,如果有问题,你再告诉我。
我这边d ...

有一个好消息,当用我1.5K测试多次,到现在都没有测试到问题
回复 支持 反对

使用道具 举报

该用户从未签到

712

主题

6371

帖子

0

超级版主

Rank: 8Rank: 8

积分
24891
最后登录
2025-7-21
发表于 2016-11-11 15:44:35 | 显示全部楼层
longdelu 发表于 2016-11-11 14:51
有一个好消息,当用我1.5K测试多次,到现在都没有测试到问题

放着多测几天试试。
还有你的代码,我强烈建议你修改。
你现在这个代码太容易死锁了,编程风格有待提高。
回复 支持 反对

使用道具 举报

该用户从未签到

2

主题

39

帖子

0

注册会员

Rank: 2

积分
103
最后登录
2021-1-27
 楼主| 发表于 2016-11-11 15:59:26 | 显示全部楼层
本帖最后由 longdelu 于 2016-11-11 16:01 编辑
小恩GG 发表于 2016-11-11 15:44
放着多测几天试试。
还有你的代码,我强烈建议你修改。
你现在这个代码太容易死锁了,编程风格有待提高。 ...

有点吧,谢谢提醒,可是我想问一下,你能肯定这种现像产生的确切原因吗,软件或硬件?
回复 支持 反对

使用道具 举报

该用户从未签到

712

主题

6371

帖子

0

超级版主

Rank: 8Rank: 8

积分
24891
最后登录
2025-7-21
发表于 2016-11-11 16:41:44 | 显示全部楼层
longdelu 发表于 2016-11-11 15:59
有点吧,谢谢提醒,可是我想问一下,你能肯定这种现像产生的确切原因吗,软件或硬件? ...

从你目前的情况看,硬件占了一大半。
软件占了一小半,如果你的从机出现问题,因为已经是从机极限了,从机因为一些干扰没能正确接收到你主机数据给NACK了, 你主机就因为软件问题死了。
硬件上拉大了,动态特性差,是导致从机不能接收正确数据的原因之一,然后不能ACK,结合你的雷区代码,就死了。
回复 支持 反对

使用道具 举报

该用户从未签到

2

主题

39

帖子

0

注册会员

Rank: 2

积分
103
最后登录
2021-1-27
 楼主| 发表于 2016-11-11 17:15:44 | 显示全部楼层
小恩GG 发表于 2016-11-11 16:41
从你目前的情况看,硬件占了一大半。
软件占了一小半,如果你的从机出现问题,因为已经是从机极限了,从 ...

根据你的意思,那就是说如果通信正常的话,软件是可以按照期望正常跑的,只是软件上没有做通信出错时处理然后死机了对吗?那你觉得什么样的干扰会使SCL的时钟少了一个?是上拉电阻过大,或者总线电容过大,I2C动态特性差,的确较容易受到干扰。不知道降低电阻是否可以避免丢时钟这个问题
回复 支持 反对

使用道具 举报

该用户从未签到

712

主题

6371

帖子

0

超级版主

Rank: 8Rank: 8

积分
24891
最后登录
2025-7-21
发表于 2016-11-11 17:49:34 | 显示全部楼层
longdelu 发表于 2016-11-11 17:15
根据你的意思,那就是说如果通信正常的话,软件是可以按照期望正常跑的,只是软件上没有做通信出错时处理 ...

理论上是这样的。
不过,在运行中,你无法保证你的硬件工作在理想情况下的,外部一个抖动,工况比较差,板子布线差,等都可能引起通信处问题。所以通常,一旦出问题之后,软件能够去弥补,恢复这种情况,让通信重新运行起来。
你现在降低电阻长时间跑,不要外部加测试设备,如果是接线,I2C线也不要连太长,线的质量用好点,避免两根线之间信号相互影响。如果长时间没有问题,说明电阻是可行的。
后面就是要把软件做好防死机,真正的项目要尽量少用,不用while,防止程序阻塞。
回复 支持 反对

使用道具 举报

该用户从未签到

2

主题

39

帖子

0

注册会员

Rank: 2

积分
103
最后登录
2021-1-27
 楼主| 发表于 2016-11-13 11:34:21 | 显示全部楼层
小恩GG 发表于 2016-11-11 17:49
理论上是这样的。
不过,在运行中,你无法保证你的硬件工作在理想情况下的,外部一个抖动,工况比较差, ...

好的,谢谢
回复 支持 反对

使用道具 举报

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

本版积分规则

关闭

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

Archiver|手机版|小黑屋|恩智浦技术社区

GMT+8, 2025-7-22 02:08 , Processed in 0.110355 second(s), 30 queries , MemCache On.

Powered by Discuz! X3.4

Copyright © 2001-2024, Tencent Cloud.

快速回复 返回顶部 返回列表