CH374:关于中断标志寄存器和测试程序

(1)CH374EVT的device例子中为什么要连续读两次中断标志寄存器 int main( void ) // USB device { mDelaymS( 50 ); // 等待CH374复位完成 CH374_PORT_INIT( ); // CH374接口初始化 Init374Device( ); // 初始化USB设备 while ( 1 ) { // 等待USB设备中断,然后处理USB设备中断 if( Query374Interrupt() ) // -------------读出的中断标志与0x0F与 { USB_DeviceInterrupt( ); // -------------处理具体中断 } } }

查询的时候读了一次,处理之前又读了一次,如果取消前一次查询的读动作,发现PC都不能加载驱动了,仿真发现两次读取的中断标志居然是不同的,可是期间根本没有USB通信哦。 这是怎么回事呢?

(2)使用DEBUG372.EXE来调试CH374.如果按照正常的操作先“下传”再“上传”,通信没什么问题,可是如果多点几下“上传”,通信就死掉了。 ----重启DEBUG372.EXE没用; ----下位机程序中把上传和下传处理加入互锁也没用; ----仿真发现这时候无论点什么,下位机程序根本产生不了中断,难道CH374芯片死了?

请wch工程师或其他同学解惑,谢谢!

另追加一个问题:

已经设置了UED为低电平使能,而且外部都加了下拉电阻了,写入BIT_CTRL_OE_POLAR后,读回来也是对的,实测也是低电平,但是读中断标志寄存器里面的BIT_IF_USB_OE为什么是“1”呢(1-UE引脚为高电平)。


第一次读中断状态是为了查询中断,有中断则执行中断处理程序,如果如果连接了CH374的中断引脚则直接查询中断引脚。DEBUG372.EXE软件的要求的正确操作是:点一次下传仅对应的一次上传。BIT_CTRL_OE_POLAR的值可以忽略,不用管它


补充: 第二次读中断是为了查明是什么样的中断,以便对不同的中断进行处理


(1)问题是我两次读的中断值是不一样的,这就比较奇怪了。即经常还是能进到最后一个else里面去。这是SPI的通信问题呢还是芯片本身就是这个样子的啊?关于SPI这里也说两句,datasheet上说支持(0,0)模式,可是我使用TI28系列DSP发现这个模式不能通信,实际量过波形是正确的,现在使用的是(0,1)还是(1,0)模式记不清楚了,就可以通信。不过速度高于2MHz时就有问题了,我现在用的是1MHz SPI时钟。这个问题我再看看。

(2)为什么限制“点一次下传仅对应的一次上传”,如果接着再点一次上传,仿真发现这时候产生的中断标志是0xFF。但是从此后通信就死掉了。您能告诉我死掉的原因吗?驱动问题还是程序(上位机?下位机?)。如果拔掉USB线再重新插上,通信可以恢复。


1,你确认下在你的DSP模式0的时候SPI的信号是什么样的?还有确认你的DSP在模式0的时候SPI发生数据是8位数据还是16位数据? 2,至于上传一次和下传一次取决于你的MCU程序以及计算机的程序。我们提供的例子程序就是下传一次和上传一次。这个后面需要MCU和计算机之间做通信协议。


1. 8位数据,波形应该没有问题。不过数据看起来是在时钟上升沿开始变化的,这个是DSP决定的,软件控制不了。如果CH374对MOSI采样时间有差异,可能会造成通讯异常。 可以上传附件吗?可以看看波形。

2.我是想了解具体一点死掉的原因。如果设备在运行过程中上位机软件发出一个数据包给MCU并等待回传,但是这个包在MCU那里时发生了错误,这时PC发出“上传”指令时,系统不就死机了?


点上传后PC上位机有个函数会一直等这个数据


to 7楼,

没有仔细看PC端的程序,如果是这样,那把PC程序关掉后重启应该可以恢复通讯对吧?但是实际上发现不行。 必须拔掉USB线再插上才能通信(PC软件不用关掉)。


上位机软件对应的下位机TEST程序流程是这样的:下传一次数据,点击上传是可以得到数据的取反,你再点一次上传此时上位机程序会一直等数据上床,所以会出现“假死”的现象,但是此时你再下传数据时,上位机程序就能等到数据,而退出假死的现象,你也可以通过重启软件的方法退出假死现象。你说的这种现象是不会的,除非此时你设备断掉了,可能你的硬件不稳定,你在死机后在拔出设备前看下设备管理器下设备是否还存在


只有登录才能回复,可以选择微信账号登录