LPC1837 Xplorer board USB0 and USB1

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LPC1837 Xplorer board USB0 and USB1

411 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by stefacc on Sun Nov 29 02:52:55 MST 2015
Hi all
I bought the Xplorer LPC1837 board for a project.
The board comes with the firmware which sets the USB0 in host mode and the USB1 in device mode.
I did several tests to sets the USB1 in host mode and USB0 in device mode but nothing. The copying does not run.

DEBUG: the program doesn't find any device attached (usb memory) on USB1

Any help is welcome.
Thanks
Labels (1)
0 Kudos
3 Replies

319 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by olaek on Fri Jan 22 06:48:36 MST 2016
I've been fiddling a bit with this too and I think the problem is that the TFBGA100 package doesn't have a P9_5. (see 6.2, Table 3 in the LPC1850/30/20/10 Product data sheet).
It's a bit wierd that under 4.1, Table 2 it is stated that the package supports USB1 host and device but not ULPI. I believe that's where the data sheet is wrong.

0 Kudos

319 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by stefacc on Sun Nov 29 14:21:58 MST 2015
I think that the only problem is the pin configuration because all others functions are developed by NXP

this is my setting sequence:

 /* P2_5 USB1_VBUS, MUST CONFIGURE THIS SIGNAL FOR USB1 NORMAL OPERATION */
Chip_SCU_PinMux(0x2, 5, (MD_PLN | MD_EZI | MD_ZI), FUNC2);

/* P9_5 USB1_PPWR, USB1 VBus function */
Chip_SCU_PinMux(0x9, 5, (MD_PUP | MD_EZI), FUNC2);

 /* P2_6 USB1_PWR_EN, USB1 VBus function */
Chip_SCU_PinMux(0x2, 6, (MD_PUP | MD_EZI), FUNC4);

/* GPIO5[6] = USB1_PWR_EN */
Chip_GPIO_WriteDirBit(LPC_GPIO_PORT, 5, 6, true);

/* GPIO5[6] output high */
Chip_GPIO_WritePortBit(LPC_GPIO_PORT, 5, 6, true);


but nothing
0 Kudos

319 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by mysepp on Sun Nov 29 04:18:40 MST 2015
Hi,
what you describe as "DEBUG" is not debugging, but a test result. It is too far away, too abstract,
you must go deeper into analysis, following what the implementation is doing.
Till a host (LPC1837) does find a attached device (e.g. memory stick), there are a lot of steps needed.
You need to find out what is already working, how far it reaches to detect/find your device.
Usually there is USB communication over EP0 where descriptors are read out from device.
Do you see this communication? Do you see the requests sent by LPC1837?
Do you see the answers of these requests? Are these accepted or contain something
which your implementation doesn't want/not assume to receive?
Usually USB is time sensitive, so perhaps single stepping does not help,
because timeouts occur!
Perhaps you can have a look at the same data packets, function, memory areas,
when you don't exchange USB0<->USB1 to learn how it work before switching to non-working configuration?
Often a hardware analyser is helpful, but I assume you don't have such an analyzer?
Have you connected the device to PC, e.g. had a look with usbview on descriptor,
so you know at least how they are looking? Have you had already a look into books about
USB, like "USB complete" ( Updated: ISBN-13: ISBN 978-1-931448-28-4 -> Fifth edition)?
( http://janaxelson.com/usb.htm )
Have you read the chapters about USB in user manual of LPC1837?
Pay attention: You will need almost all of them, every piece gives a part of the solutions,
to bring you faster to a running solution.
Good luck!
Best regards,
Martin

0 Kudos