在数据传输过程中出现1F错误。如何能快速的复位，让程序继续传输？只总线复位，375不复位的情况下可以吗？我的意思是保留跟U盘建立的通道信息，只以最少的复位来继续数据传输。

上次的问题终于解决了，那天早上你们一个工程师接我电话的时候说的一句话提醒了我，u+u-接反了有些U盘也能通过。哎，怎么都没想到，电路图是对的，在接线的时候会给接错，而且从开始大家都是按照这个破线接，谁都没想过对电路图看看，真是哭死了。

把具体的情况说一下,如果你复位 了设备,那么要重新进行枚举的.不能继续数据传输了,需要重新开始, 复位的方式是设置模式7,延时10MS,然后设置模式6,然后开始通讯就可以了. 把返回0X1F的情况具体说清楚.

我一次向U盘内写入128簇的信息，也就是说最少一次写入128个扇区。在这样的过程中，经常莫名其妙的发生错误，卡在中断上，我跳过等待中断的指令，发送状态获取指令，得到的就是设备操作失败0x1f的返回值

那你是一次写入128个扇区吗?比如你每次写8个扇区,分16次写完,结果如何?你可以用我们读写文件的子程序库

对，一次写入128个扇区甚至更多。U盘的簇对应的扇区不同，我只能对应一个簇来写，如果分多次写的话，时间上会有点慢。每次写8个扇区，要么是一次提取8个簇号，也有可能是一个簇号。这样变动太大，对我的程序来说就复杂了，速度也会下降。而且不能保证不出现错误的状况，出现了错误我还是要解决。现在出现了1F这个错误后，不论我对375做什么测试似乎都不行了。我不想复位375，因为要重新枚举，时间上更慢。

你这个和簇有什么关系呢?你自己分析文件系统来进行文件级的操作吗?,你这样先做一下实验,就从0号扇区开始写每次写10个扇区看看结果是什么.你用的什么MCU?

对，我是分析的文件系统（FAT32）然后进行扇区级的操作。我使用的是DSP2812。这个错误不是一定的，只是不定的出现，有时候写十多个扇区就会出现这个问题，有时候50个扇区以后才出现问题。很少有全部写完的时候，它要是稳定的话就好说了。因为我现在的延时很不准确，可以说时间一定都是超时的。所以我曾经怀疑过会不会有超时性的错误，但你们的工程师说扇区级操作，375的内置固件程序是没有超时错误的。

这个问题主要出现在写扇区的时候。读扇区到还没有发现任何问题。

这样吧,把你的代码发到lht@wch.cn邮箱,我看一下.

375正常情况下，读100扇区（每扇区512字节）的时间应该是多少？

这个时间没有具体的，与程序、U盘都有一定的关系，可以在系统上实测一下

我是说在支持大多数主流U盘的情况下（现下1G的U盘或更大），读100扇区的时间。我现在将uS延时程序降了下来，时间是5S读100扇区，10S写200扇区。这样的速度对大数U盘是否都可以接受？另外，这个速度对375传输给U盘来说是否还行有余力？如果是的话，我想再缩短延时的时间，毕竟在保证稳定的情况下能越快越好。

这个时间还是比较慢的,100个扇区应该1S都用不到,不要测试写,测试读速度.400KB/S应该是没有问题的,也就是说800个扇区每秒.

对于DSP来说，5S读100的扇区，速度仅为10KB/S，这个读速度不正常，U盘的速度远比这个快，同样也没完全发挥CH375的性能，不知道CH375的3个读写子程序是怎么处理的

好的，我了解了。我只负责U盘这部分的编写。估计在总线传输的部分有延时，导致我这边计算延时出现很大的误差。3个读写程序都是按照你们给的流程来进行，除了延时不准，其余的没区别。谢谢各位的帮忙。