┬ÁTasker Forum

┬ÁTasker Forum => NXPTM LPC2XXX and LPC17XX => Topic started by: mark on April 14, 2010, 10:45:55 PM

Title: USB for LPCXXXX
Post by: mark on April 14, 2010, 10:45:55 PM

I would like to give some information about USB support for the various LPC devices.

For the moment USB device mode is being extended to include the LPC214X, LPC23XX and LPC17XX.
- The LPC214X is the smallest USB capable device, supporting device but not host mode.
- The LPC23XX and LPC17XX support device, host and OTG modes.

The USB device controllers are FIFO based but most of the devices have also additional, optional DMA support, with an area of RAM specifically for this use.

The present state of development allows the FIFO based operation (CDC class as reference) to operate on the LPC2148, LPC2378 and LPC1766 reference boards. The USB device controller is almost identical in all of these chips, with just some differences in the set up of the ports and also the configuration of the USB clock [the LPC2148 and LPC1766 derive it from a dedicated PLL and the LPC2378 derives it from the processor's main clock].

Although the control of the serial interface engine (SIE) via a command interface requires a bit of learning (and experimentation), the USB controller proved to be highly autonomous. This means that it doesn't need much software control of things like data toggling, which can be a bit tricky with some devices and require keeping backups of various flags to get it all right.

With the 3 references operating correctly as standard CDC devices (allowing menu interface, RS232<->USB etc.) in basic FIFO mode the next step is to add DMA support for the devices which allow this (which are most - just the simpler ones like LPC2141/2/4 don't).
In parallel, a USB mass storage device class is being worked on to go with general SD card support, allowing the SD card to be seen as a hard disk at the PC host.

It is thus anticipated that this important addition to both the LPC2XXX and LPC17XX projects will be able to be released in the fairly near future. Not only will this give an interesting improvement of functionality but will shoot the LPC17XX project up to a mature status (thanks to the fact that has been used successfully in some first projects and because its peripherals are highly compatible with existing ones from the LPC2XXX project)!!


Title: Re: USB for LPCXXXX
Post by: jezc on April 15, 2010, 10:17:13 AM
Hi Mark,

That sounds like great news!

We're using both LPC24xx & LCP17xx devices already and would be very interested in the USB functionality being included (both Host and slave/device) - USB mass storage would be useful but I'd also be interested in the BlueTooth option in your other thread.

We currently have our own separate module to provide BlueTooth to serial conversion into our products but these are certainly more expensive than a cheap USB to BlueTooth dongle!

Any further information you'd be prepared to share would be of interest!

Title: Re: USB for LPCXXXX
Post by: mark on April 15, 2010, 02:56:07 PM
Hi Jez

I didn't list the LPC24XX but I expect that it is adequately similar to the LPC23XX (this is true for all other peripherals in it) that it will be a case of configuring the appropriate port lines. I will verify this shortly - and don't expect any problems.

Certainly I would like to implement the DMA support as next step since it would be a shame to not make use of the chip's capabilities, and thus have a sub-optimal solution.

Host (and OTG) operation modes haven't actually been demanded and this is why it is taking time to get down to implementing them. USB device is however picking up in popularity and so underlines the importance of this mode in all projects (once the LPCs are sorted out the AVR32 will be next candidate - after which there will be nothing more to get in the way of host mode).

I was also on the look out for host mode embedded uses which would help to give some impetus - I may well have found it with the Bluetooth modules. This is also be relevant for other radio technologies - there are lots of very small USB devices (wireless mouse, wireless keypads etc.) which are probably also suitable for short distance applications. ZigBee USB dongles are also available for about the same price (when not already used for wireless mouse etc. - even if a bit larger). Or WIFI USB dongles.... [these are also available as SD card insert by the way...]

Although it may not be a truly general purpose solution (requiring host support and an available host socket) it does show the flexibility that a free host socket gives an embedded product - being able to plug in the communication technology and go (as PCs can) [albeit with some extra embedded SW development].


Title: Re: USB for LPCXXXX
Post by: mark on April 16, 2010, 08:49:55 PM

OK. USB device on the LPC2478 (Olimex board) is working - but it didn't go that smoothly...

The LPC24XX (like LPC2378) can connect the USB device to one of two port mappings (1 or 2). The circuit diagram that I have from the Olimex board shows the device connector on port 2; this is logical because a device has to be on port 2 if host is to be operated at the same time on port 1. Strange is however that the VBUS line is not connected to VBUS but to the USB CONNECT 2 signal. USB1_CONNECT is used to switch the pull-up to the USB device D+ line, which would be a mix up because it is not port 1 - furthermore the signal names USB1_CONNECT is not actually connected to the pin with this name...

Not a big deal, I thought. Just switch some signals as ports and use ports to control the USB signals.

No signs of life though, so the traces were checked on the board and it was noticed that the USB port 2 was not being connected to the USB device but instead to the USB host connector. On the Olimex web site I found a user's manual with circuit diagram in it which also showed this connection, meaning that the other circuit diagram (also on the web site) has swapped USB connections...

Swapping the USB port to port 1 and working around the fact that the USB control lines are not actually connected to the USB control pins eventually got it running.



PS. More details here: http://tech.groups.yahoo.com/group/lpc2000/message/48968
Title: Re: USB for LPCXXXX
Post by: aaronlawrence on June 03, 2010, 12:15:29 AM
So... just how thoroughly is the USB CDC support tested?
Will it handle high baud rates with lots of randomly timed data? (You know the kind of thing now Mark ;)

Our Ethernet approach has proved fairly problematic, so I'm casting around for alternatives. At the uTasker end, we have USB as an option. At the other end we will have to buy a CDC driver for Windows CE which makes me very nervous, but one step at a time!
Title: Re: USB for LPCXXXX
Post by: mark on June 03, 2010, 03:14:14 AM
Hi Aaron

USB is a rather special case. It involves the classes and the drivers, whereas Ethernet is 98% protocol.

USB also has a certification process which is optional. The uTasker stack will not be certified since the process is rather expensive and would be academic in certifying a reference project although each product would still require its own certification. Each user therefore needs to decide whether certification is something that his/her product requires and then go the process without any reference of the USB stack having been previously certified in any reference project. As far as I know, this path has not been an option for any user up to now whereby there are a few products using CDC for various purposes (including MODBUS).

There have been problems which which were solved on the way but the present reference projects/product (based on SAM7X and Coldfire parts) seem to be behaving well at the moment.

Back to the opening point: The original Coldfire CDC development was quite an effort since it took a number of months of quite intensive work to get it developed, documented and tested adequately for first release. The CDC part could then be used by the SAM7X but again the driver development had to be performed on top of it (this is always a big part of each processor since the USB controllers are hugely different - unlike Ethernet drivers - and very interrupt intensive - needing a lot of tests and reading between the lines in the data sheet before it is mastered to a degree of half-certainty).

In the case of the LPC parts, the USB driver was in fact rather easier to get working than, for example, the Coldfire (its USB engine takes over a lot more work, hiding a lot of details [could be good or could turn out to be a bad thing in the long run] ??). It was thus not such a big job to get it basically working in CDC mode. In DMA mode (an option on most chips) it didn't prove to be that successful at first attempt so there is still a certain amount of learning to be done there.

Due to the fact that the CDC based projects which are in operation (most experience with Coldfire, followed by SAM7X) have been used for some time without known problems [note that CDC allows about 1MByte throughput to be practically achieved and also randomly timed data has been tested - there was indeed an interrupt problem with this once along the development path...] I have high confidence in the solution but can never exclude the need to investigate a new issue in the future. In the case of the LPC and the fact that the CDC development represents only half of a new processor development - the other half being the new processor-specific driver - this requires first test case projects with these chips to get it to the same state of confidence.

The great thing about CDC is that it is adequately versatile to be used for most USB interfacing (even if not specifically designed for it). Windows PCs should have the standard USB serial driver and so shouldn't need anything installed (additionally licensed) - I wouldn't expect CE to be be any different (?) or accept the usbser.sys driver file. The fact that the USB connection looks like a COM port (but faster) means that many old serial interface based programs can immediately use it without needing to be modified. One thing that is sometimes a bit of a nuisance is that the USB cable has to be unplugged and plugged in again (re-enumeration) and the program re-started if the program (or Windows driver?) blocks the interface (which often happens when the start-up / close-down sequences are not respected). It is possible that custom drivers will help in this case since they may offer more control from the application.


Title: Re: USB for LPCXXXX
Post by: aaronlawrence on June 15, 2010, 07:47:04 AM
OK, that's clear - we would be one of the first major test cases. 

No, Windows CE does not have a CDC driver, and uses completely different drivers from the desktop.

Anybody have experience developing a custom USB driver for a desktop OS? It looks a bit nightmarish to me, but I imagine once you get all the layers in place it's just passing packets back and forth...
Title: Re: USB for LPCXXXX
Post by: mark on June 15, 2010, 12:19:56 PM
Hi Aaron

During the USB development process the Windows Driver side was also looked into. I read the book "USB Complete - third edition" by Jan Axelson as well as a more text book one "USB2.0" - Franzis Professional Series. Each was helpful in its way, whereby the Axelson one gave a more practical, when not so deep, overview of the complete process, as well as some words about the Windows Driver development.

After reading about the driver development SW needed, debugging one PC via serial interface from another I basically resigned to the fact that it is a job for a dedicated developer and not something that you just do in a few hours of spare time. I have heard that about 3 man months may be typically needed to get up to speed with a fist driver.

Basically that is why there is no uTasker USB driver to go with the embedded side (also it wouldn't have been practical to have one for Linux and possibly other OS that are out there) and why the CDC class was chosen as one with least stumbling stones on the way. I didn't known that there was nothing inherently in Win CE - that is big disappointment.

Some semiconductor manufacturers have interesting USB support for users of their chips (eg. Cypress). They deliver their own generic USB driver which, although maybe no highly optimised for a particular function, which can easily interfaced to any Windows program through a nice API interface. Of course this restricts use to silicon from this vendor but makes work easy.

Jungo seems to be a big player in supplying USB PC drivers (they also supply embedded drivers too) but there are no details of licensing fees - I believe it is royalty based and companies not listing prices are usually supplying good SW but at a price that they don't like to advertise...;-)



P.S. Ethernet is still my interface of preference - generally it is easier to use (with WinPCap the PC SW can also be totally bypassed), is hugely flexible, fast and is not limited to effectively point-to-point connections as USB is. USB has its place too but hopefully only when there is a suitable, standard driver present that doesn't complicate the issue more than necessary.
Title: Re: USB for LPCXXXX
Post by: mhoneywill on June 15, 2010, 01:55:36 PM
Hi Araon,

I've never done any USB development but I am aware of a driver stack built for the AVR called LUFA see http://www.fourwalledcubicle.com/LUFA.php I mentioned it before in this post http://www.utasker.com/forum/index.php?topic=880.msg3870#msg3870 I mention it again, incase you hadn't seen the other post. There seems to be a lot of support for devices and classes that exist on PC's like HID and joystick etc. You might be able to glean some info from the code.


Title: Re: USB for LPCXXXX
Post by: aaronlawrence on July 30, 2010, 02:48:50 AM
It turns out that Microsoft added a CDC serial driver in Windows CE6, although without announcing it.
It seems to be somewhat buggy ...

Our device end is working with LPCUSB

since the uTasker USB support was not released.

Title: Re: USB for LPCXXXX
Post by: vini on August 05, 2010, 01:37:16 PM

I am doing project on designing wireless sensor node. I have designed using LPC1768. In this i want to use USB port for forwarding data to PC. But my usb port is not getting configured. I am using the Keil 1700 examples for USB. When i connect my device to PC. PC just displays "USB device not recognized". I am doing usb related programmin first time can anyone please guide over it. Is a driver need to be developed for my embedded testing.

Title: Re: USB for LPCXXXX
Post by: mark on August 05, 2010, 02:31:49 PM
Hi Vini

You will get that error message when the USB device is not responding to requests from the USB host. This may mean that you don't have USB SW (correctly) operating on your LPC1768 board, but it could also be due to HW problems.

It is best to load some "known-good" reference software (perhaps the Keil USB examples should do this ?) to ensure that it can enumerate. If this doesn't work it is unfortunately very difficult to know why without using a USB analyser connected in the line. Therefore first make sure that you have a working reference before taking any further steps since it is otherwise extremely difficult to advise what to do about it - USB is unfortunately rather complicated...


Title: Re: USB for LPCXXXX
Post by: vini on August 08, 2010, 07:20:00 AM

I tried different examples of Keil. In that in USBHostLite example at first it shows Device not recognized but as program executes  my device get removed from Device Manager list. Again when i press reset it says Device not recognized (  unknown device). For all other examples unknown device is only displayed. What can be the reason for it?


Title: Re: USB for LPCXXXX
Post by: aaronlawrence on September 16, 2010, 11:38:15 PM
have responded to your PM. Please post further discussion here.

I think you should be asking on the Keil forum, no?

I'm prettty busy and can't help you in depth but below are some hints

I am at present working over USB device sstack in LPC1768. I want to establish USB Virtual port communication. But on loading the program and connecting the device to PC i get USB device Unrecognized.

What is the exact message?
What operating system?
What device driver are you using? Which .INF file?
If you are using Windows Vista or 7 you may need to switch off signed drivers (boot time option) before it will even ask you to load your device driver.
You should know I could not get it always to work reliably on XP either - sometimes it worked, sometimes not.

Now the next thing is that in soft connect mode insead of using a switching transistor i am using soft connect line as GPIO line and pulling D+ line to high.
When this GPIO line is low system doesnt detect any device when pulled high shows unknown device.
This sounds about right. So long as your GPIO link can drive enough current to pull it up properly.

Title: Re: USB for LPCXXXX
Post by: vini on September 17, 2010, 12:40:58 PM
Thank you sir
I am on Keil forum also, but not getting any adequate help.

Exact message which i get on connecting my device to PC :

USB Device Not Recognized
One of the USB device attached to this computer has malfunctioned, and windows does not recognize it. For assistance in solving this problem, click this message.

Operating System :  Windows Xp

I am using Windows usb host driver(usbser.sys)
INFfile : lpc 17xx-vcom.inf


Title: Re: USB for LPCXXXX
Post by: vini on January 06, 2011, 03:36:29 PM
Is there any problem if for USB Device , if we use USB type 'A' connector , instead of usb type 'B' connector
Title: Re: USB for LPCXXXX
Post by: mark on January 07, 2011, 01:54:44 PM

According to USB2.0 specification the host must use a series "A" receptical and a device must use a series "B" receptical. This means, to respect the specifcation (and ensure inter-operability and avoid risk of damage) the device should not use an "A" receptical.

A low speed device should also not have any receptical - it requires that the cable is fixed (like a mouse).


Title: Re: USB for LPCXXXX
Post by: mark on January 31, 2011, 04:43:03 PM
Hi All

Following is the link to the present LPC2xxx Beta containing USB device (in interrupt mode and not [yet] DMA mode):

The following Beta version includes USB device support as well as SDIO controller for the utFAT module.
The password is the same as for the official release. The project is configured for the Olimex 2478 board with TFT where it will show a slide show in the TFT of images in the directors "pics" on the SD card (when inserted). When no SD card is inserted it will run a graphical demo.
http://www.uTasker.com/software/V1.4/uTaskerV1.4-4B_LPC2XXX.zip [9.9.2010]
When USB is activated (in config.h) it will allow the SD card to appear as a disk to the PC. The USB interface is running in interrupt mode whereby the SDIO is on DMA mode. The demo can be seen here with some details of the SDIO configuration: http://www.youtube.com/watch?v=5dD2cZ8FEqo