Using USB on MCF52258 a Data Tranfer from a PC to a Device Completes but Windows Does Not Close the Window

[dmw]

We're having a problem with the USB on the MCF52258.  We're using it to transfer firmware from a PC to a device.  The PC is the USB host and it runs Windows 7.  The transfer works, but windows doesn't close the window till long after the transfer has completed.  Looking at a USB trace, it looks like the problem is that the processor keeps sending NAKs after the transfer has completed which keeps the connection open.  How do we keep this from happening?

[pint]

A NAK on an OUT endpoint means that the transfer is not complete - from windows point of view - but the device does not accept any more data. You need to start another read transfer on the device endpoint.

[dmw]

Why would I start another read transfer after the transfer has completed?

[pint]

Because your first transfer did not transfer all the data that was available. You must keep on reading until everything has been transmitted.

[dmw]

But all the data has been transferred.  The file being transferred consists of S-records which contain the firmware for the device.  The code on the device reads in each S-record and writes the data to the address in flash indicated in the S-record.  After the last S-record, which starts with S7, is read the device reboots and comes up successfully, but Windows doesn't close the window.

[TomE]

> After the last S-record, which starts with S7, is read the device reboots and comes up successfully

My guess is that it is like dropping a phone in the middle of a conversation, and the other end is still saying "Hello, Hello?". The other end is expecting to hear that the data has been received properly and is then expecting to cleanly end the "call".

After receiving the last S-Record, the code should not reboot immediately, but should hang around running the USB processing loop until the transfer has been ACKed or the the connection has been closed and all the handshakes finished. Only then should it reboot.

BTW, can you EDIT the original post as there's no such chip as an "MCF52289" like you have in the "Subject" line.

Tom

[pint]

I don't know the details of the protocol that the download program uses but obviously it wants to send more. Maybe it is just a empty terminating packet. Why not just read it and see what you get. When the program closes the handle you should get a configuration request that disables the usb interface. That would be the right time to reboot.

[dmw]

Windows is indeed sending more packets.  The content of the packets is

C3 55 53 42 43 30 D5 A7 03 00 00 00 00 00 00 06 1E 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 1C 85

The six characters starting with the second are ASCII for USBC0.  They're all NAK'ed by the device.

[melissa_hunter]

Hi David,

Since you're using a standard class, the data is coming from Windows. There won't be a way to prevent Windows from doing this (unless you write a custom version of the mass storage driver instead of using the standard windows driver). All you can do is change what the bootloader does in response. The packet doesn't seem to be a standard SCSI command sent over USB. I'm not sure what the packet is or how you might respond to it in order to make Windows happy.

dereksnell,

Do you know what these packets windows is sending after the s19 file transfer is complete are?

-Melissa

[dmw]

I don't know what those extra packets Windows is sending are.  Since it hasn't been determined what can be sent to Windows to get it to close the window, and since disconnecting the cable will close the window, is there any way to set something in the MCF52289 which will do the equivalent of disconnecting the cable?

[dereksnell]

Hi David and Melissa,

From the packet data David shared, this is a CBW packet using the CBW signature 0x43425355.

http://books.google.com/books?id=gzUOUeEbozQC&pg=PA59&lpg=PA59&dq=usb+cbw+signature+0x43425355&sourc...

And it appears to be a SCSI command with the opcode 0x1E, which is the Prevent/Allow Medium Removal command

SCSI command - Wikipedia, the free encyclopedia

But it sounds like David has found the root of this issue, and the MCU resets after S19 file download, and no longer ACKs these packets, but the Windows host is unaware that the device finished and reset.

David, yes the USB peripheral can do the equivalent of disconnecting the cable.  You can configure it to stop driving the USB data signals, and no longer pull those signals, so the host sees a detach event.  The bootloader example in appnote AN4379 does this, and forces a re-enumeration, so you can use that as an example: 

AN4379, Freescale USB Mass Storage Device Bootloader - Application Notes

AN4379SW

Thanks

[dmw]

Derek,

I couldn't find the place in the example code where it stops driving the USB signals.  Would you please tell me exactly where that is?

Thanks

[melissa_hunter]

Hi David,

I'm not seeing a place in the code that does this either, but you should just need to disable the pullup on the D+ line:

MCF_USB_OTG_USB_OTG_CONTROL &= ~MCF_USB_OTG_USB_OTG_CONTROL_DPPULLUP_NONOTG;

When the host sees that the pullup on D+ is going it should recognize that as a detach event.

-Melissa

[dmw]

Melissa,

I tried adding that line of code, but Windows did not recognize it as a detach event.

David

[melissa_hunter]

Hi David,

Sorry for the delay in getting back to you. I've been in and out of the office the last few days.

You might need to wait longer. The USB spec says that the host can wait as long as 2.5us from the time is starts seeing the SE0 state on the data lines (both D+ and D- pulled low by the host/no D+ pullup active on the device) before it should recognize that as a detach event. Section 7.1.7.3 of the USB 2.0 spec has the description on connect and disconnect signalling if you want to read more about it.

So you will need to make sure that you leave the D+ pullup disabled long enough for the host to detect the detach. Maybe you're re-enabling the pullup too quickly so that you can re-attach and that is preventing the host from ever seeing the detach?

-Melissa

[dmw]

Melissa,

I put in a long wait after disabling the D+ pullup, on the order of several seconds, and Windows did not disconnect.

David

[dmw]

That is Windows didn't close the window.

[TomE]

> That is Windows didn't close the window.

Does it close the window if you physically UNPLUG the cable?

If it doesn't close then you're not going to fix this one in software by disconnecting from the device side.

If it does close then your software isn't doing the "same thing" as a physical disconnect and you should investigate that.

Tom

[dmw]

As I said in an earlier post, disconnecting the cable will cause Windows to close the window.  And I tried the code that Melissa suggested to do the equivalent of disconnecting the cable, but, as I said earlier, it didn't work.  If anyone has any ideas about what will work, please let me know.

[TomE]

So put an oscilloscope on the D+ line and see if the voltage changes when you clear the MCF_USB_OTG_USB_OTG_CONTROL_DPPULLUP_NONOTG bit.

At a pinch you can use a multimeter to monitor the voltage, but I'd recommend an oscilloscope.

If it doesn't drop, then you're not programming the correct bit or maybe the hardware design has a pullup resistor when it shouldn't.

Tom

[dmw]

There was indeed an external pull-up.  We removed it and then resetting MCF_USB_OTG_USB_OTG_CONTROL_DPPULLUP_NONOTG closed the connection.  However, we're not sure we want to put in a hardware change at this point.  One thing we want to know is the value of the internal pull-up.  Does anyone have that information.