USB example gives unknown device on MCB4300 dev board

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

USB example gives unknown device on MCB4300 dev board

1,186 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by agemoz on Sat Dec 19 17:52:48 MST 2015
Hello,
   I've been writing code for my custom LPC4357 board, this has so far gone very well.  I've just started attempting to turn on its USB port to make my board look like a disk drive that will supply web pages on a server.  I used the LPCOpen usbd_rom_msc_ram example on the Keil MCB4300 board to help me get started.  This compiled and linked fine on the Keil dev board, I was able to use the cortex M3 debugger to run it from reset.  It appears to step through the USB example without failing or getting a hard fault, I see it sitting in the WFI (wait for interrupt) routine. 

  However the PC that connects the USB port is showing an unrecognized device and that the USB port has been disabled.  I would appreciate some guidance why this example is not running on the Keil board as expected?  I thought I would see an unformatted disk but that is not happening, although the example code seems to be running.

I'm running LPCXpresso v7.4.0 [Build 229] [2014-09-16] on a Win7 PC.

Thanks,
Bob
Labels (1)
0 Kudos
16 Replies

1,083 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by agemoz on Sat Jan 16 17:06:30 MST 2016
Finally figured out how to track this USB ROM code--you cannot singlestep, but you can set consecutive assembly code breakpoints.  It turned out that when I migrated my code to 8.0 LPCXpress, a routine that sets up the USB PHY was not getting called.  If you try to init the USB without a powered-up phy, the processor dies badly.  I put the USB PHY powerup (bit 5 in CREG0) set to zero active, and I'm back up and running.

This issue is resolved.
0 Kudos

1,083 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by agemoz on Sat Jan 16 10:48:55 MST 2016
Well, no luck--even with a huge amount of work, I have not been able to troubleshoot this USB problem over the last month.  I was successful in updating my environment to version 1.8, the configuration had to be modified, I found all the issues, and now can run my non-USB code successfully in the latest LPCXpress.  But running the int USB API call hangs.  When I try to debug it, I can run fine up to the line

/* USB Initialization */
ret = USBD_API->hw->Init(&g_hUsb, &desc, &usb_param);

I checked that the descriptors are pointing correctly and have valid data, but when I run this instruction, the emulator (the Keil cortex M debugger) disconnects.  There are no warnings or errors.  If I load this code into flash and reset (without the emulator) it just hangs.

How do I debug this?  As long as I don't try to init USB, all my code works fine.  How do I determine why the USB ROM code is dying?  I've exhausted all the ideas I have why this doesnt work.

It seems like it is a fatal showstopper for using this part that the USB ROM code cannot be traced--is there any way to find out why the processor locks up in here.

Bob
0 Kudos

1,083 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by agemoz on Sun Dec 27 08:32:51 MST 2015
Thank you, this is very helpful--I had done a search both in nxp and google and looked in the user guide but didnt catch this one.  I do want to do the migration but was not expecting it to wipe out my existing configurations--I thought I'd be able to copy over settings, but in retrospect it's easy to imagine the settings would change.  I'll try again soon with a new workspace.

Bob.
0 Kudos

1,083 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by TheFallGuy on Sun Dec 27 03:30:49 MST 2015
There is a porting guide...
https://www.lpcware.com/content/faq/lpcxpresso/migrating-existing-projects

I notice that v7.4 was released in September 2014, making it 15 months out-of-date, so I am not surprised *some* migration is required...
0 Kudos

1,083 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by agemoz on Sat Dec 26 18:36:47 MST 2015
Yuck.  Gave up, restored from a workspace backup, now back to running 7.4, works fine.  whew!  Lesson learned.  Looks like moving to version 8.0.0 is not a clean process--shouldnt be wiping out configurations without some sort of port guide, or at least saving the old configurations.

Bob
0 Kudos

1,083 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by agemoz on Sat Dec 26 18:28:48 MST 2015
Well, I made a terrible mistake and updated to version v8.0.0.526.  That wiped out my configurations, didn't give me an option to save the old ones, and I had to try to recreate it--I'm thinking I might unwind the whole workspace from a backup, what a disaster.   Never ever update in the middle of a project--what a colossal mess.  I had one day of functioning USB, then lost it all.

I tried regenerating all the configuration stuff in this version, but now it dies with arm-none-eabi/bin/ld.exe: invalid data statement.  There's no indication of what linker entry is failing--no clue where this came from.  Nothing in any of the user guides.  Anybody know what this means?

Thanks, Bob
0 Kudos

1,083 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by MikeSimmonds on Sat Dec 26 09:39:59 MST 2015
USB enumeration is somewhat time sensitive so maybe when run under the debugger,
the responses are not fast enough for the host and it gives up.

Mike.
0 Kudos

1,083 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by agemoz on Thu Dec 24 09:51:49 MST 2015
Hi vtw, et.al,
   Thank you all for your help during this holiday season!  I really appreciate it--I've made considerable progress.  Knowing that people have successfully used this example caused me to redouble my efforts.  The problem isn't resolved, but it has something to do with how the LPCXpresso debugger comes up.  If I program flash in release mode, shutdown the debugger, and push the reset button on the MCB4300 board, it finally creates a disk that I can see on the host.  I was able to format it and put a test file on it.  This provided a valuable clue that the debug mode, or running the debugger in release mode, is interfering with the USB enumeration process even though it looks like the code is running correctly.  It's only when LPCXpresso is shut down that USB functions correctly.

  Now the effort is to figure out what is different.  It would be of enormous help if tracing or setting breakpoints within the USB API were possible, but it sounds like this is not an option?

Thank you all,
Bob
0 Kudos

1,083 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by vtw.433e on Thu Dec 24 06:47:14 MST 2015
Despite what whitecoe says, I doubt that the old version of LPCXpresso you are using has any relevance. I use 7.9.0 for what its worth.

The code works 'as is' from the LPCXpresso (LPCOpen) example (lpcopen_2_12_lpcxpresso_keil_mcb_4357) on my MCB4300 with 4357 chip.

I changed no config - but you may want to check all your jumpers are installed in their default position. Check the user guide at http://www.keil.com/support/man/docs/mcb1800/mcb1800_intro.htm

I have been connecting to USB0, which has also provided the power - make sure you are using a USB port on your PC that provides the full 500mA - otherwise, try powering it using the DC connector.

As mine work, I have no idea what is wrong with your setup, except as mentioned above.

Good luck.
0 Kudos

1,083 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by whitecoe on Thu Dec 24 02:44:44 MST 2015

Quote: agemoz

I am using the latest LPCXpresso version 7.4.0.



I'm not saying that your problem is being triggered by this, but you do realise that the current release is LPCXpresso v8.0 don't you? v7.40 is now well over a year old :  https://www.lpcware.com/content/forum/lpcxpresso-latest-release

HTH!
0 Kudos

1,083 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by agemoz on Wed Dec 23 12:43:40 MST 2015
Hi vtw,
   That's great news!  If you don't mind, could you answer a few questions? 

I am using the latest LPCXpresso version 7.4.0.  The usbd_rom_msc_ram code is the latest version 2.12 from the lpcopen site (lpcopen_2_12_lpcxpresso_keil_mcb_4357.zip).

Did you have to modify or add any code to the usbd_rom_msc_ram example?  I linked in the lp_chip_43xx and the lpc_board_keil_mcb_4357 libraries.

Is there any configuration settings that you had to change?  I had to add include file paths but did not change anything else.

Do you have any board jumper changes?  I am powering the board through the USB0 connector.

Did you use usb0 or usb1?  I'm assuming if it worked for you that this device appeared as a mass storage device in the PC devices and printers view.

Any other thoughts what might be a problem with my setup?

Thanks,
Bob
0 Kudos

1,083 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by vtw.433e on Wed Dec 23 11:53:13 MST 2015
The example works for me on the mcb4300 board ( with lpc4357 chip). Must be a problem with your setup.
0 Kudos

1,083 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by agemoz on Wed Dec 23 10:11:36 MST 2015
Hi mc,
   This example does not work on the MCB4300.  I have not found any configuration that allows it to work correctly.  It always shows an unknown device after about 30 seconds.   The LPC4357 USB command and status registers do not show anything out of the ordinary--no error conditions.  Stepping through the example code looks exactly correct, and when I step over the API USB connect function, the PC host responds with an interrupt packet and an attempt to handshake--but then the interface appears to stop.  I see no descriptors or other packets going to the host.

   I am connecting directly to PC.  I a trying a number of experiments, different PCs.   I will also try a hub.  I have a custom board I have built, I will try it as well.  

   But so far with all the different experiments I have tried, the PC sees a device but fails to enumerate it.  Do you have any suggestions for debugging?    Is there a way to trace through the API code to see what is going wrong (I am using the Keil Cortex-M USB debugger with the LPCXpresso IDE version 7.4 (the latest one).

Bob
0 Kudos

1,083 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by mc on Wed Dec 23 09:54:56 MST 2015
Hi Bob,
Just to confirm that this example works on MCB4300 board without any problem.
Are you connecting your board directly to PC or through hub?
0 Kudos

1,083 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by agemoz on Tue Dec 22 14:45:59 MST 2015
Still more information:  I tried switching to USB1 (commented out the Use_USB0, turned on the Use_USB1 defines) and moving the cable to the USB1 connector on the MCB4300, same behavior.  The debugger shows the USB_IRQHandler interrupt triggering once, but there seems to be no way to step through the USB_ROM_API code, the debugger just runs rather than steps--I'm assuming you cannot step through the ROM).  I see the descriptors in memory but as far as I can determine these are not ever sent.  The debugger shows that execution makes it all the way to the USB_connect function, and no further traceable execution occurs until I get the unknown device error.  I moved the system stack and USB stack base addresses to different SRAM locations to no avail, the host never successfully enumerates.  I programmed flash and just ran without the debugger, and got the same behavior. 

As far as I can tell, the Keil MCB4300 does not enumerate no matter what I do.  Should I abandon this project, has anyone successfully enumerated the MCB4300 board?

Bob
0 Kudos

1,083 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by agemoz on Sun Dec 20 18:29:57 MST 2015
More information, did a little USB sniffing.  I see the USB device endpoint IN and OUT transfers, so it does look like a very basic initial communication going back and forth.  The unknown device has the 0x2B (43) USB error code (failed to reset).  I see an initial URB from the host to the endpoint (the MCB4300) with data of 0, followed by a URB from the endpoint of 01 01 00 00.  A little while later I see a URB from the endpoint to the host of 20.  Then I see a URB from the host of 0, followed by the endpoint sending a 03 05 00 00.  I see this last step repeated at periodic intervals, although eventually the sequence stops and the unknown device message pops up.   Looks like the initial ack handshake is not succeeding.  I never see anything that looks like a transfer of descriptors/setup information.  Any help much appreciated.

Bob
0 Kudos