usbn9602初始化后，一系列的reset信号。。。死循环了？

usbn9602初始化后，一系列的reset信号。。。死循环了？
我通过了usbn9602的初始化，使主机能够知道插上的东东是个USB，然后进入中断，处理USB的alternate events，先是探测到SD3(SUSPEND EVENT),然后有RESET_A(复位信号）产生，接着处理reset event(复位事件）；
以上还算正常：）
可是，处理完复位事件后，复位信号又开始不断的产生，程序再处理，处理完，复位信号再产生。。。

死循环了：（

我到国半上发现一下的东东：
大概是说，出现以上原因是因为：
1）MCNTRL设置不正确。（我认真检查了MCNTRL的设置，没有问题）
2）产生一堆的reset signal 是正常的，最终，枚举还是能够正常进行的，这个过程由主机来完成。

按照他的说明，我就开始等，结果仍是reset。
我不知道是为什么，，，请教 各位有经验的大侠，帮忙看看
Q: After initializing the \'9602 and attaching the USB cable, my firmware detects lots of \"reset\" events, but nothing else. What is going on?

A: The USBN9602 will detect a reset event whenever both USB lines are low for 2.5 bit times or longer. When the NAT bit in the MCNTRL register is cleared, it physically forces both USB lines low. So whenever this bit is cleared, the USBN9602 will also be detecting a string of reset events. This is normal, and presumably the NAT bit is set before USBN9602 interrupts are enabled.

When enumeration begins (after connecting the cable), the host will assert reset for 10 milliseconds or longer. This is much much longer than 2.5 bit times, and so it is entirely possible that your device will see the reset signal-ling several times in rapid succession (depending on how fast you service the reset interrupt). That\'s ok. Eventually the host will stop signalling and will move on to begin the enumeration process.

The danger here is in your reset interrupt handler. If you somehow clear the NAT bit in the MCNTRL register, this has the same effect as disconnecting the cable. The USBN9602 will think it\'s seeing more reset events, and the upstream hub will detect the state change too.
It will signal the host, and the whole ugly process will start again.

Never clear the NAT (or the VGE) bit in your reset handler, intentionally or otherwise. Don\'t issue a hardware or software reset to the USBN9602.

The following code example is typical of what you should do:


if(evnt & RESET_A)          /*reset event          */    {     write_usb(NFSR,RST_ST);     /*enter reset state     */     write_usb(FAR,AD_EN+0);     /*set default address      */     write_usb(EPC0, 0x00);     /*enable EP0 only      */     FLUSHTX0;          /*flush TX0 and disable     */     write_usb(RXC0,RX_EN);     /*enable the receiver     */    /*adjusting ints is nec. here in case we were in suspend     */     write_usb(ALTMSK,NORMAL_ALTMSK);/*adjust interrupts     */     write_usb(NFSR,OPR_ST);     /*go operational     */    }

各位大侠：
我受了一下，以前的帖子，有类似的问题，可没有发现解决的方案
斑竹又没有高见？

俺没有用过NS的东东耶！ :D

郁闷死了
有没有知道的指点一下：）

你的设备通过枚举了吗，还有把你的设备是高速设备还是低速，再有就是把问题列详细些，在那一步出现的问题。这样才有人给你解决吗

你的设备通过枚举了吗，还有把你的设备是高速设备还是低速，再有就是把问题列详细些，在那一步出现的问题。这样才有人给你解决吗

谢谢你的回答：）这样的，程序开始是SD3的状态reset，然后就是一直处于reset的状态，几百次之后就没有reset中断信号了，在主程序的死循环内跳不出来了。没有其他的中断信号，所以就没有枚举过程了。RXC0和TXC0赋值后读出的值一直为零，不知道是为什么？
是否和时钟有关？晶振48mhz,usbn9602是12MHZ，没有错啊，怎么就不能枚举呢。
高手们 ，枚举过得高手们，。请指教了：））

用9603或者9604吧，NS的9602器件设计的本身就有问题，很难调试，我用的是9603，没有出现你这样的问题

用9603或者9604吧，NS的9602器件设计的本身就有问题，很难调试，我用的是9603，没有出现你这样的问题

请问哪里有9603或9604？？在北京的？

[quote]用9603或者9604吧，NS的9602器件设计的本身就有问题，很难调试，我用的是9603，没有出现你这样的问题

请问哪里有9603或9604？？在北京的？ [/quote]
问题找到了，是因为硬件。开心中。。。

关注：祝你成功

有问题欢迎到http://liumd.xilubbs.com(我刚刚申请的）留言！