The USB topic

[Giovanni]

An USB device-only implementation would fit under the current driver model, I already wrote an USB driver (unrelated to ChibiOS) for that cell so I should already know the pitfalls. It is in the to-do list for after 2.4.x release.

My idea is to stabilize the API before implementing more USB devices. Currently I feel that the dual mode transaction/packet in the USB model, while allows to optimize some use cases (copy-less operations on packet-memory-oriented cells for example), makes the implementation of the LLD much more difficult than supporting transaction mode alone. For sake of simplicity I will probably drop the packet mode and concentrate on a single-mode API.

Making implementations is not the hard part, making correct driver models is. A full-OTG (with host capability) would require another driver model and a complex one (plus the stack of standard host-side protocols), it would be a major development and I don't currently have the bandwidth for this.

Giovanni

[Xamusk]

OK. So today I managed to test the testhal USB_CDC demo, just to make sure the problem was not on my build system.

The compilation only got me one warning:

Code: Select all

main.c: In function 'Thread1':
main.c:401:1: warning: no return statement in function returning non-void

which was pretty much expected.

On uploading the .bin to the board, the blinker runs fine, but I don't even get an enumeration upon connection.

My hardware looks pretty much the same as the Olimex board, apart from some resistors with different values. I'll check now if each connection is proper.

On the scope, I get data on both D+ and D-, but I can't find a good Win7 USB sniffer to rule out problems.

[Giovanni]

Hi,

Does windows report something attached when you connect the board? if not then the resistor does not pull up.

Giovanni

[Xamusk]

No, Windows isn't reporting anything. Nothing on Device Manager. Not even the characteristic USB plug sound.

I have access to the pin that pulls up the data line, and have tested the pulling effect on the line on the scope and it does get high.

[Xamusk]

By the way, shouldn't a simple pull-up trigger the "USB connect sound" on Windows and an enumeration, even if the device isn't recognized?

[Giovanni]

This is strange, if there is a pull-up windows should immediately try to enumerate the device and popup a message about a new device detected.

Giovanni

[Xamusk]

That's what I thought. I guess I must review my hardware again. Maybe some impedance matching problem.

Just for reference, I based my design on the USB part of this board: http://www.etteam.com/product/ARM/manET-STM32F103.pdf

The design is basically the same as the Olimex one, except for some different component values.

[Xamusk]

By the way, I've been doing some tests, and it looks like the hardware is doing what it should. When I ground the control pin, I do get 3V on the D+ line.

Also, at least some of the code is getting called when I connect the cable, specially Vector90 on usb_lld.c.

Upon connection, I usually get istr = 0x2500 (ISTR_ERR & ISTR_RESET & ISTR_ESOF), but sometimes I get other values, like:

0x0900 - ISTR_SUSP & ISTR_ESOF
0x0400 - ISTR_RESET (sometimes when connecting the first time)
0x0500 - ISTR_RESET & ISTR_ESOF (mostly when connecting the cable)

This is for my code, but I also can't get an enumeration on the USB_CDC testhal demo, at least for my board, even with the appropriate code changes.

Does anyone have the Olimex board? I'd like to at least know if the last code (version 2.3.4) is still working on the right hardware.

[barthess]

On olimex STM32-103STK board CDC demo from latest SVN code works fine. After plugging it to USB windows detects "ChibiOS/RT Virtual COM Port"

[Giovanni]

Are clock settings right? the USB only works if driven with a 48MHz clock, this mean that the CPU can only be clocked at 48 or 72 MHz. Dividers in the demos are calculated for boards with 8MHz crystals.

Giovanni