现在安卓大行其道，不是高通，就是MTK，甚至于很多人不知道还有德州仪器这个平台了，关于如何在德州仪器Omap37xx平台上调试SE4500，网络上除了针对SE4500的几个pdf文档介绍之外，没有任何资料可供参考，相信本文对你很有帮助，不必感谢。本文出自C.S.D.N原创(转载标明来源)。
一、SE4500因为工作在3.3V，德州仪器的Omap37xx工作在1.8V，所以之间必须要进行电平转换，建议使用德州仪器的TXB0104/08进行转换(看好了是TXB0104/08不是TXS0104/08，两者都是QFN封装，价钱应该是一样的，但是支持的最高转换频率是不一样的)，因为SE4500属于图像采集，所以要求频率超过24Mbps，所以必须使用TXB系列的电平转换芯片。
二、SE4500在不上电时，会将I2C总线的电平拉低，严格意义上讲，摩托罗拉的SE4500应该是兼容I2C协议，不是标准I2C协议，标准I2C协议要求总线上不工作的器件应该是高阻状态，而不是把I2C总线电平拉低，导致总线上的其他设备无法正常工作。
三、PCB layout的时候，camera信号线最好走等长线，这样图像采集的信号干扰少，会好很多。
四、CAM_Open,CAM_Close莫名其妙被调用多次，导致CAM domain在系统休眠时无法进入休眠
一、SE4500因为工作在3.3V，德州仪器的Omap37xx工作在1.8V，所以之间必须要进行电平转换，建议使用德州仪器的TXB0104/08进行转换(看好了是TXB0104/08不是TXS0104/08，两者都是QFN封装，价钱应该是一样的，但是支持的最高转换频率是不一样的)，因为SE4500属于图像采集，所以要求频率超过24Mbps，所以必须使用TXB系列的电平转换芯片。
二、SE4500在不上电时，会将I2C总线的电平拉低，严格意义上讲，摩托罗拉的SE4500应该是兼容I2C协议，不是标准I2C协议，标准I2C协议要求总线上不工作的器件应该是高阻状态，而不是把I2C总线电平拉低，导致总线上的其他设备无法正常工作。
三、PCB layout的时候，camera信号线最好走等长线，这样图像采集的信号干扰少，会好很多。
四、CAM_Open,CAM_Close莫名其妙被调用多次，导致CAM domain在系统休眠时无法进入休眠
以下部分注册表取自TI平台SE4500驱动的注册表部分：
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\CAM]
"Dll"="cam_SE4500.dll"
"Prefix"="CAM"
"Index"=dword:1
"Order"=dword:200
"BufferSize"=dword:80000
"BufferCount"=dword:4
"IClass"="{A32942B7-920C-486b-B0E6-92A702A99B35}" ; CE_DRIVER_POWER_MANAGEABLE_GENERIC_GUID
"PowerFlags"=dword:00000103 ; send pre/post device state changes
"Dll"="cam_SE4500.dll"
"Prefix"="CAM"
"Index"=dword:1
"Order"=dword:200
"BufferSize"=dword:80000
"BufferCount"=dword:4
"IClass"="{A32942B7-920C-486b-B0E6-92A702A99B35}" ; CE_DRIVER_POWER_MANAGEABLE_GENERIC_GUID
"PowerFlags"=dword:00000103 ; send pre/post device state changes
摩托罗拉给的注册表配置基本上是这个样子，通过在CAM_Init、CAM_Open、CAM_Close函数开头部分添加打印信息。
我们发现，在驱动加载时候，按理说，应该只有CAM_Init被device.exe调用，后面的CAM_Open和CAM_Close只有程序调用了 CreateFile("CAM1:",**)和CloseHandle以后才会分别调用CAM_Open和CAM_Close。
Log信息显示，驱动加载的时候，CAM_Init被调用一次，CAM_Open被连续调用了两次，CAM_Close被调用了一次，导致 refCount在调用CAM_Close的时候不为零，所以导致Camera的clock无法关闭，因为只有refCount等于零时才会关掉FCLK 和ICLK。
为什么会出现上面这种情况呢，我们经过分析，发现是注册表中IClass后面的值有问题，原来摩托罗拉(现在是斑马,Zebra Technologies)在配置这个参数的时候，是没有考虑整个EVM3530平台是否进入休眠的，只关心SDL软解功能是否能够正常工作。
我们修改了Iclass的值如下：
"IClass"=multi_sz:"{0AE2066F-89A2-4D70-8FC2-29AEFA68413C}=%b","{CB998A05-122C-4166-846A-933E4D7E3C86}=%b"
经过测试，此时在驱动加载时，只有CAM_Init被调用了。通过修改Drvr_intf.cpp和hw_intf.cpp源代码，我们在摩托罗拉提供的 驱动代码基础上解决了驱动在加载时就给SE4500上电的问题，此时如果应用程序不使用4500的话，它有20多mA的电流消耗，除非在应用程序中配置为AudoIdle，所以我们这样做，在驱动加载时不上电，只有在SDL调用CAM_Open的时候再给SE4500上电，调用CAM_Close时再给断电。
但这时有个问题，就是系统进入休眠时会切断控制SE4500上电的三极管的控制脚的电压，除非你的系统没有真正进入休眠(CORE或者PER domain没有关闭，这样当然不会切断1.8V电压，你的LDO肯定不会关掉)， 所以SE4500的3.3V在休眠时就会断电，之前启动应用程序后给里面通过I2C发送的配置参数都会丢失，一唤醒系统，再进休眠，此时SE4500又有20多mA的电流消耗，所以，我们在驱动中动态调用pin Mux，就是如果应用程序打开了SE4500，再进入休眠的话，我们动态设置pin Mux为OFF_INPUT_PULL_UP，也就是OFF MODE使能，INPUT使能，上拉使能(Omap3平台的内部上拉下拉只在引脚作为输入功能时有效，故我们设置为输入，而非输出)。
注意：SE4500使用了"Index"=dword:1，所以SDL中一定是使用CreateFile("CAM1:",***)这样的方式打开的，为了不至于冲突，系统的Camera的Index不能使用1，可以使用除1以外的其他可用值。
五、SE4500驱动和系统自带Camera驱动同时加载时(两个都使用Camera总线，但是分时复用，理论上不会冲突)。系统Camera能使用，能预览能拍照，但是SE4500能出光，不能解码了，这是怎么回事？
经过测试，我们发现是在camera驱动加载时，注册了IRQ_CAM0中断，导致SE4500的SDL软解库中无法注册该中断，所以后面就只能出光不能解码，发现该问题，我们修改了camera驱动的实现，让其只有camera打开时，才注册该中断，通过一个互斥机制，camera打开时会检测SE4500是否在工作，如果在工作，就提示ISP被占用，打开失败，反之亦然。该问题迎刃而解。
经过测试，我们发现是在camera驱动加载时，注册了IRQ_CAM0中断，导致SE4500的SDL软解库中无法注册该中断，所以后面就只能出光不能解码，发现该问题，我们修改了camera驱动的实现，让其只有camera打开时，才注册该中断，通过一个互斥机制，camera打开时会检测SE4500是否在工作，如果在工作，就提示ISP被占用，打开失败，反之亦然。该问题迎刃而解。
版权声明：本文为博主原创文章，未经博主允许不得转载。