AN3927 - MSD enumeration problem: Set Configuration fails!!

[leesp]

I am using AN3927 MSD Bootloader with MC9S08JM32, CodeWarrior

Keep having Windows Device Manager "Device cannot start" error code 10 problem.

Found out that, sometimes MCU does not acknowledge/handshake the SET_CONFIGURATION request. On protocol analyzer, MCU just does not send the handshake packet back to HOST.

Why is this so?

[Tsuneo]

I received a PM from you,

SP Lee wrote:

Dear Dr. Tsuneo,

I hope you don't mind I send you this private msg. I've read several of your posts on this and other forums.

I have been struggling with this problem for two months, Freescale is unable to provide solution. I have also searched other forums but to no avail. I sincerely hope you can provide some insight to the problem.

My project is to develop a USB MSD bootloader using MC9S08JM32. I got this AN3927 and implemented it on Windows 8. My PBA has this MCU, and a USB touch device which are all connected to a USB hub controller (Cypress CY7C65632).

The MCU USB is configured as:

- EP0 IN, EP0 OUT for control transfer

- EP1 as Bulk-IN

- EP2 as Bulk-OUT

The problem - MSD always fails to enumerate as MSD device, "Device cannot start", Code 10. However I can see that Win8 already recognise its PID/VID. It never succeed

However, if I bypass the hub controller, and connect the MCU D+/D- directly to Host PC, it always pass.

I use USBlyzer to look at the log, and found that the Host PC manages to query the various Descriptors, and finally Select Configuration 1 (the only config). Then the Host PC issue a 31-byte OUT SCSI command, and then on the USBlyzer, I saw IN "Unsuccessful (Babble detected)". The Host would try a few times, and same Babble error happens, and the Host would "Remove device"

Do you see what actually went wrong? With Win8/Hub, it fails 100%. I tested on WinXP/Hub, failure is random, ~10%. If I bypass the hub controller, pass 100%

Please help. Thank you.

In my policy, I’ll answer to PM questions on forum, unless the question requires private answer.

> I saw IN "Unsuccessful (Babble detected)"

Babble error means collision of a transaction and SOF. However, USBDI of Windows often returns USBD_STATUS_BABBLE_DETECTED (error code: 0xC0000012L) wrongly, when buffer overrun occurs on IN transfer (**1). The device returns more data than your PC application requests.

To make it sure (if it would be real babble error or not),

Connect your MC9S08JM32 to a Win8 PC over a stand-alone USB 2.0 hub, skipping the Cypress hub chip.

a) If you don’t see any trouble, the problem should lie in the Cypress hub chip.

The crystal OSC (or external clock source) should be unstable. Hub synchronizes to host at SOF timing. When the clock source on the hub is unstable, hub could fail to synchronize to the host, and "real" babble error occurs.

b) If you still see the trouble, the problem should lie in the MC9S08JM32 firmware.

USB 2.0 hub shortens the interval between USB transfers. The firmware could get timing error.

If you would have a hardware bus analyzer, we’ll get more solid clue.

But this easy test will help us to find the source of the trouble.

Try this test.

(**1) Strictly speaking, "babble" should not be applied to the buffer overrun error on transfer, because it is defined as follows in the USB spec.

Chapter 2: Terms and Abbreviations (usb_20.pdf)

Babble: Unexpected bus activity that persists beyond a specified point in a (micro)frame

Tsuneo

[leesp]

Hi Tsuneo,

I tried skipping the Cypress chip, use a standalone hub, it still fails. After using a hardware bus analyser, I found that there were bugs in the AN3927 firmware, which I think does not work correctly when there is a hub in between the high speed PC and full-speed MCU.

You're are right, the hub shorten the interval of transactions and there were race conditions. The device was sending more data to PC than requested, because the byte count register was overwritten. I think I managed to fix the bugs. I will post my solution to the forum once my work is finished

Thank you..!