一、I2C协议简述
1、特点：多主，冲突检测和仲裁
2、起止信号
SCL高电平期间，SDA低跳变，即为开始信号。
SCL高电平期间，SDA高跳变，即为结束信号。
3、数据信号
SCL低电平期间，SDA允许变化
4、响应信号（用于确认地址或者数据）
接收器在第9个时钟周期，拉低SDA电平
注意：有3种情况是不发ACK信号的：
a)从机发现地址不匹配
b)从机无法接收更多数据
c)主机接收了最后一个字节的数据
5、暂停信号
主机或从机都可以拉低SCL来迫使对方进入等待状态
6、数据格式
S信号 | 从机地址 | R/W | A | 数据 | A | P信号

2019-08-02
一、今天测试了一下二期配套源码"18th_i2c"
1、编译烧写到板子上后，ssCOMM32上不显示任何信息
2、但如果在"嵌入式linux应用开发_光盘hardwarei2c"的基础上修改（具体来说，把i2c.c，at24cxx.c，main.c从二期配套源码"18th_i2c"拷到"嵌入式linux应用开发_光盘hardwarei2c"），则 ssCOMM32上能显示:
##### AT24CXX Menu #####
[R] Read AT24CXX
[W] Write AT24CXX
Enter your selection:
而且读写AT24C02都没有问题
通过比较两者的代码，发现原因是：二期"18th_i2c"的 nand.c 里为了支持大页读写，有 #define LARGE_NAND_PAGE。但优龙的板子的nandflash是k9f1208u0m，不支持大页。

二、碰到一个非常奇怪的问题：
在ubuntu里，修改main.c，屏蔽掉printf("rn##### AT24CXX Menu #####rn");后，编译烧写运行，居然ssCOMM32还是打印了出来##### AT24CXX Menu #####？
什么鬼？
折腾了2个多小时，始终没有头绪，明天再说吧。

2019-08-03
针对昨天遗留下来的奇怪问题，今天进行排查
i)在ubuntu上，用vim -b i2c.bin打开，发现确实已经删除了“##### AT24CXX Menu #####”，说明出问题的环节不在虚拟机
ii)怀疑是否因为windows的磁盘缓存未刷新导致的？遂把i2c.bin拷到windows10上的其它目录，然后用UE打开，发现仍然有“##### AT24CXX Menu #####”，说明不是磁盘缓存未刷新的原因，那么出问题的环节也不在宿主机
iii)怀疑是文件传输环节出了问题。遂改用U盘来把i2c.bin从ubuntu拷到windows10，然后用UE打开，这次不再出现“##### AT24CXX Menu #####”
iv)那么，出问题的环节应该就是文件传输，要么是vsftpd，要么是windows的ftp客户端（注：我目前用的是windows10 的资源管理器，最终发现确实是它的问题）。
vsftp不熟悉，所以先从容易排查的一端（即windows的资源管理器）入手。如果罪魁祸首确实是它，那么换个ftp客户端应该能解决问题，遂下载安装fileZilla client。
再用UE打开，果然不再出现“##### AT24CXX Menu #####”！
结论：如果把windows10的资源管理器用作ftp客户端，可能导致传输后的文件内容有问题。
不清楚这个问题是否具有普遍性，还是仅仅存在于Windows10专业版(版本号1809)？

2019-08-04
一、尝试用eclipse+OpenJTAG+OpenOCD的套路来调试代码
注1：参考资料：百问网OpenJTAG 调试器产品手册《Eclipse,OpenOCD,OpenJTAGv3.1 开发教程v5.pdf》
注2：以下套路适用于在lds连接脚本中直接把所有代码的运行地址都安排在0x30000000的情况
这样就不用担心make 加上-g选项后产生的符号表使init节超出4K（因为如果把init节安排在0地址处，则因s3c24xx的内部ram只有4K，所以init节最大只能4K），导致make会失败
- 此套路的优点：
可以基本实现代码的可视化调试
- 此套路的不足：
a)可能需要修改代码（因为当从nandflash里运行时，head.S实际位于0地址内存处，所以现在head.S里(包括bl间接调用的)所有的代码必须保证是位置无关的）
好在涉及到要修改的代码基本上都和初始化相关，相对稳定，所以修改工作基本上属于一劳永逸的工作。
b)调试的时候需要屏蔽掉head.S里的CopyCode2SDRAM（因为调试时，gdb会直接把代码加载到运行地址(此例即0x30000000) 处，所以这个工作不需要在程序中做了），而调试完毕后，烧写到nand里运行时，还要恢复head.S里的CopyCode2SDRAM
c)不太稳定，OpenOCD有时会崩掉 :-(

具体步骤：

step0)确保开发板的跳线设置为了从NAND启动
step1)head.S屏蔽掉CopyCode2SDRAM
step2)设置eclipse的debug configuration：

图1

图2

图3

图4

step3)OpenJTAG连接开发板和电脑
电脑启动OpenOCD，点“connect”，连接开发板

图5

step4) Work Dir设置为init.bin（下载）所在的目录，然后 点“telnet”按钮，进入telnet客户端：

          输入以下命令：

          load_image init.bin 0x0

          resume 0x0

          halt

注：为了简化调试流程，可以把以上这三句话添加到s3c2410_gdb.init文件（参考上文图2）里：

        target remote localhost:3333

        monitor halt

        monitor arm920t cp15 2 0

        monitor step

        monitor load_image E:/eclipse_projects/init.bin 0x0

        monitor resume 0x0

        monitor halt

        monitor wait_halt

图6

step5) eclipse启动调试

图7

注：Console窗口里会出现：Program received signal SIGINT, Interrupt.原因暂不明，可能是因为当初安装的 tool chains

“gcc-arm-none-eabi-4_7-2013q2-20130614-win32.exe” 对于windows10的兼容性不太好。

不过好像并不影响调试。

step8) 调试完成后，恢复head.S被屏蔽掉的CopyCode2SDRAM