This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

USB: indication of end of transfer

Hello,
I am transferring a file using USB MSD to a device, based on the Keil USB library. Can I know, when the transfer starts, how many bytes to expect? What is the indication in software as to the "end of file"?

Parents
  • The thing is that when I transfer the file to the device, I apply the folllowing logic:
    "A bulk transfer ends in one of two ways: when the expected amount of data has transferred or when a transaction contains either zero data bytes or another number of bytes that is less than the endpoint’s maximum packet size."

    none of the above occurs! I receive three 64 byte packets for a file that is 4KB on disk, 40 bytes real size. what's up? how can I know when the entire file has been transferred?

Reply
  • The thing is that when I transfer the file to the device, I apply the folllowing logic:
    "A bulk transfer ends in one of two ways: when the expected amount of data has transferred or when a transaction contains either zero data bytes or another number of bytes that is less than the endpoint’s maximum packet size."

    none of the above occurs! I receive three 64 byte packets for a file that is 4KB on disk, 40 bytes real size. what's up? how can I know when the entire file has been transferred?

Children
  • You miss these facts,
    a) The disk I/O system on most of OS has buffering to reduce frequent media access. The PC doesn't always read/write to media to access files/directories.

    b) The disk I/O system is established on a presupposition that data on a media is never changed without the intervention of the system. When the device firmware modifies the data without command from the host, it may be regarded as disk error, or may be just ignored.

    Many people (including me :-) ) have once thought MSC is handy way to implement data transfer over USB. But it's bad idea, actually.

    Tsuneo

  • If you are trying to do firmware upgrade, then you should probably do it like this:

    1) Implement a true USB mass storage device in external RAM.
    2) Fill FAT data structures for empty filesystem on that device prior to mounting.
    3) Mount the device.
    4) Transfer a file from PC to the device.
    5) Unmount the device.
    6) Analyze the contents of the filesystem. If a suitable file is found, use it to upgrade the firmware.

    That's how I see it, anyway.
    - mike

  • 3) Mount the device.
    5) Unmount the device.

    The problem lies in the detection of unmount.
    While mounted, Windows put "Test Unit Ready (TUR)" SCSI command periodically (about every 1 sec). Also, SOF is put to the bus connected to the MSC device.

    When unmounted,
    Windows XP SP2 and SP3 stop both of TUR and SOF.
    Vista SP1 stops TUR, but SOF is continuously put to the bus.

    If you detect unmount by SOF, you'll fail in Vista.
    It is the reason that many USB hard disk on the market tell that the power-down function on unmount doesn't work on Vista.

    I don't know how it may change on Windows 7.

    In this way, when you depend on the feature not original in the MSC/SCSI spec, you'll get suffered minor incompatibility between OS versions.

    I repeat that firmware update using MSC is a bad idea, even if NXP have released such an example.

    Tsuneo

  • In addition,
    MacOS X 10.5.6 doesn't stop either TUR nor SOF while unmounted. :-)

    Tsuneo