USB ROM API

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

USB ROM API

1,765 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by apriori on Fri Sep 11 12:54:40 MST 2015
The documentation of the USB ROM API is way too incomplete to aid in development of a complex (custom class) USB device.
Is it possible to download the source code of the USB ROM API? In all honesty, how is one expected to develop anything more
complex than the example devices using the USB ROM API with almost no documentation and no way to look into the source
code to find out what's going on?
Labels (1)
0 Kudos
4 Replies

1,153 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by ahoyhoy on Thu Nov 05 09:02:39 MST 2015
Hi Apriori,

Unfortunately I find myself in the same situation and agree with your previous post.

Did you have any success with obtaining more information or source code?

I am currently trying to increase the packet size for the HID example from 64 to 1024 bytes per transaction but the ROM is limited to 64 bytes max.

Why have a device with hardware that can achieve High Speed USB but write a ROM to restrict its speed?????
0 Kudos

1,153 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by apriori on Mon Sep 14 12:25:56 MST 2015
I am not frustrated about forum response times. I am frustrated about the USB support dilemma.

Designing and implementing a commercial USB device using the LPC43xx, one has to choose between the following:

[list=1]
  [*] Trying to download (from the ROM), disassemble and basically reverse-engineer the USB ROM API code, because it's a undocumented black box when it comes to custom USB devices. From what I can see, isochronous transfers don't work out of the box (read the errata, applied the "workaround") - and if they do, we'll never find out, because the semantics are unknown to developers outside of NXP. That is mainly because NXP chose to make the ROM API source code not available and doesn't provide any examples for isochronous transfers. Having the ROM API source code at hand, and the LPC43xx user manual in reach would actually be a solution. We could fix the bugs in the ROM API source code ourselves, compile it and link it into the application, having 1 MB flash memory available, I don't care about a couple of K more coming from USB stack code. In its current state, the ROM API is basically unusable for commercial developers who don't tinker with the hardware on weekends but have a deadline to meet and need to reduce their product's time-to-market.
(I looked at the mentioned packages but was unable to find the ROM API source code in there.)

  [*] Using the old LUFA-derived nxpUSBlib. This library was deprecated in favor of the USB ROM API (for non-host applications). Deprecating something that works for something that does not is a clear regression. There are even community-driven forks, like https://github.com/openxc/nxpUSBlib, but there seems to be no activity. It doesn't feel right to depend on a private fork of a deprecated library to be able to implement the firmware for a new product.

  [*] Writing a whole USB stack from scratch based on the LPC43xx user manual.
[/list]
0 Kudos

1,153 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by NXP_Support on Mon Sep 14 08:09:00 MST 2015
Hi apriori,

Regarding your frustration over the delay in responding - your post showed up on Friday afternoon with a response the next business day. 

For source code, please see our LPCOpen packages for NXP MCUs with SW USB support rather that ROM USB support, such as LPC18xx/43xx, LPC17xx/18xx. 

Best regards,
-NXP Support
0 Kudos

1,153 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by apriori on Mon Sep 14 01:44:10 MST 2015
NXP really lets us down with this thing as each day spent with shots in the dark cost money. We will probably move our projects back to the STM32F... series.
0 Kudos