CPU和CH378L之间是硬件并口连接，没有使用中断信号。用CHECK_EXIST命令测试正常，读取到的芯片及固件版本信息是51H。用DISK_CAPACITY和DISK_QUERY命令查询到的TF卡容量和空间信息都正确。用大写字母设置好文件名，用FILE_OPEN命令打开文件，返回成功。但用GET_FILE_SIZE命令+68H去查询文件长度时，返回数据不对，好像是偏移了一个字节。比如文件长度应该是1,409,528 字节（001581F8H），但返回的是00001581H。

请问有可能是什么原因？谢谢！

换用FILE_QUERY命令，获取到的文件长度就正常了。

那有没有尝试在第一种情况下GET_FILE_SIZE的时候去读取第五个字节，会不会是写完命令到读取数据之间的延时不够？

尝试了在第一种情况下GET_FILE_SIZE的时候去读取第五个字节，读到的是00H。

在单步调试时情况也一样，所以不是命令和数据之间的延时不够的问题。因为CH378是先传低字节，我没读到，我读到的第一个字节实际上是CH378传输的第二个字节，所以倒像是我读的慢了。

现在发现用RD_HOST_CUR_DATA命令读取文件内容也有问题，文件的首字节读不到。

这两个命令的共同点是都不产生中断。

我使用的是Motorola 并口时序，RD#引脚接低电平

自动演示生成的文件内容为：

在CH378芯片自动演示时写入当前信息:

(1)、芯片版本: V1.2; 

(2)、当前通信接口模式: 8位并口;                    

(3)、当前插入设备为: SD卡       

     文件系统: FAT32

     扇区大小: 512 字节

     总容量:   15095M

     剩余容量: 15086M

文件系统、扇区大小、总容量、剩余容量信息和我用DISK_QUERY命令获取的信息相同，芯片版本V1.2和我用GET_IC_VER命令获取的信息不一样，多试了几次，发现第一次返回51H，之后再发GET_IC_VER命令返回的都是43H，不知道和V1.2有什么关系？

把RD#信号与地断开，用GPIO管脚控制，模拟使用Intel时序，使用GET_FILE_SIZE命令获取文件长度就正常了，使用RD_HOST_CUR_DATA命令获取文件内容也正常，问题算是解决了。

建议技术支持反馈给研发部门，CH378芯片的Motorola 并口时序可能有缺陷。

另外，用GET_IC_VER命令获取版本信息，第一次返回数据51H，应该是把CH378从睡眠状态唤醒，51H即CMD_RET_SUCCESS，然后可以用GET_STATUS命令获取到中断状态USB_INT_WAKE_UP（E0H），再次用GET_IC_VER命令获取版本信息，返回数据43H，如果是表示第3个版本的话，则可以理解为V1.2。

您好，命令返回的43H版本是最新的芯片，并口问题我会进行反馈