The USB topic

[Xamusk]

Yes, my board uses an 8MHz crystal clock, with the 9x PLL I get 72MHz.

I'll check for the fifth time for more subtle hardware problems.

[barthess]

Are you sure your 8MHz resonator starts and works correctly? Can you check it with scope?

[Xamusk]

Yes, it does start with 8MHz. Checked with the scope and the ST demo of toggling pins as fast as possible reaches the theoretical maximum of 18MHz.

What's interesting is that the USB ISR is triggered when I connect the cable, so the chip is recognizing something. Yet, Windows is not.

[Xamusk]

Damn! I just got some response from Windows. I remembered that the ports I'm connecting the board to are USB 3.0 compatible, so I tried connecting to a USB 2.0-only port and it worked! Well, sort of... it didn't enumerate right yet, but at least the OS saw the device there.

This is quite strange, as the 3.0 port should be 2.0 compatible transparently. Also, I tried plugging it through a USB hub and it didn't work either.

Also, the enumeration didn't work right for either the USB_CDC demo or my app, but at least I have a starting point now.

[mobyfab]

if you are running nec/renesas usb 3 ports there are some driver updates to solve the problem

As soon as the USB support is available for the F4 I'll do some tests.

[Xamusk]

Thanks. Updating the driver at least now makes Win7 recognize that there is a device there, though it doesn't play the "USB connect sound" and I still couldn't enumerate the device. Maybe I still got some other thing missing... maybe I've still got a hardware problem.

[Xamusk]

Well, I've run out of options. I've tried to use the scope to decode the bits in the USB stream, but I only got so far as seeing SOF packets. My logic analyzer doesn't decode USB either, and its memory isn't that big.

I guess I'll have to wait to get my hands on a proven USB board to test it again, which won't happen anytime soon. So the USB function on my board will just stand by. That or I try ST's or some OS's library.

[Giovanni]

If it is an HW problem then other libraries won't help. Probably the cheaper solution is to get a reference board and then test your setup there, you would have a working demo to start with. An USB analyzer would cost you a lot more and probably would not help much if it is an HW problem.

About debugging, I would monitor with a breakpoint the USB events callback (usb_event in the demo), do you get one or more reset events? SOFs are not that important but reset is what starts the enumeration process. If you get the reset then monitor the messages callback and see if you get the update packets. Put breakpoints in USB_EVENT_RESET, USB_EVENT_ADDRESS and USB_EVENT_CONFIGURED, do you get any of those?

Debug using -O0 or it will be hard to place breakpoins.

Giovanni

[Xamusk]

I won't get an USB analyzer. I was thinking more of writing a plugin for the Open Logic Sniffer to analyze USB. Getting a reference board is also too expensive in my country (the shipping and imports taxes are outrageous). I considered borrowing one that worked with the ST USB library, but I'll only meet a friend who has one in the end of the month.

Using -O0 gets me into chDbgPanic(). I'm using -O1.

I do get the USB_EVENT_RESET event every time I connect the USB cable. However, I don't know if I get two in a row because the breakpoint prevents the reception of other events, if any.

Also, I don't get the other USB events: USB_EVENT_ADDRESS and USB_EVENT_CONFIGURED. I do get usbp->state to be USB_READY though. But usbp->ep0state doesn't get out of USB_EP0_WAITING_SETUP, even though usbp->epc[0] is set. Looks like _usb_ep0setup() isn't getting called.

[Giovanni]

if you get the reset remove that breakpoint and see if you get any of the others, USB_EVENT_ADDRESS would mean that at least some packets have been exchanged.

Giovanni