Found a mini-USB connector--will need to find a second one if I want to debug USB functionality.
Might be useful when using a standalone chip: LPC11U24/LPC1347 JTAG/SWD debugging with LPC-Link
Can't seem to get the board to get recognised as a USB device...might be the cable?
The LED2 on the target side of the board blinks when the USB cable is connected to the debugger side. But not when power is supplied to the target side.
In neither scenario is the device recognised as a USB device by OS X.
Sometimes syslog gives the message "The IOUSBFamily was not able to enumerate the device".
Hmmm, okay, now I'm slightly confused...
I've now got it recognised correctly.
System Information > Hardware > USB section the device appears as:
- "Composite Device"
- Product ID: 0xdf55
- Vendor ID: 0x0471 (Philips Consumer Lifestyle BV)
I'm not sure why it didn't appear to work before--I do recall seeing that Vendor ID before.
It may or may not be picky about the USB port to which it's connected?
When you choose "Debug" from the quickstart menu the code stops at main...it's not immediately clear you need to press the "Resume" toolbar icon toward the left of the tool bar, or use "Resume" from the "Run" menu or press F8.
Once the code is running, the LPC-Link side actually flickers LED1 but previous to that there's no way to even tell if it's powered.
The Target side "Blinks" LED2 but it's more of a "bouncy shimmer".
It's not entirely clear to me how the variable timing of the blink occurs. I'm assuming it's something to do with the length of time between interrupts changing but I can't tell where that's set. There's not a whole lot of explanation in the example...
There's more detail in "4.4.2 Controlling execution" section of
LPCXpresso_User_Guide.pdf on the debugging controls.
I thought a single-click in the "margin" would be enough to set a breakpoint but apparently you need to double click there to set a breakpoint.
Could be useful: Lab 1: Introduction to the LPCXpresso Code Red IDE and the Arm Cortex M0
Hmmm, interesting, viewing the USB device (when it's active?) from System Information now shows:
- LPC-Link Probe v1.3
- Product ID: 0x0009
- Vendor ID: 0x1fc9 (NXP Semiconductors)
Could be useful for getting started with bare standalone chip: ARDUINO to ARM NXP tools
Ah, as I suspected, from "LPC-Link may not initialize on Mac OS X":
"Mac laptops seem to be particularly prone to USB issues related to the power supplied by certain USB ports to connected USB devices."
One approach they suggest is "Providing separate power to the 'MCU portion' of the LPCXpresso board, so that only the LPC-Link is powered from the USB debug connection."
[Update: Another reference to the issue (via):
"If you are using a MacBook or MacBook Pro, you may have issues with some USB ports. The LPCXpresso board wants the full 500 milliamps and some of the MacMook/MacBook Pro USB ports will not accommodate it. If you are on a desktop machine, you should plug directly into a USB port on your machine, the USB ports on your keyboard or a hub can cause trouble too."
I still don't understand how the variable blinking rate works on the LED example. I don't see where anything timing related is adjusted.
Hmmm...from looking closer, I think it's because of the difference between the
Right... yeah, so, that's how they get the "bouncing" blink behaviour...
It's the interaction between the
SysTick Timer at one tick rate and the
LPC_TIMER32_0 at the other tick rate.
Changing the values of
TICKRATE_HZ2 change the blinking.
Sometimes it seems you have to terminate a debugging session manually to run a new one?
So, in conclusion: Cute blinky example but a more "typical" one one would be easier to understand as an initial intro...
This gives a more typical "blink" action:
#define TICKRATE_HZ1 (10) /* 10 ticks per second */
#define TICKRATE_HZ2 (5) /* 5 ticks per second */
Build it, run it, blinks like a normal blink. :)
Far more sensible.
Was going to look at some USB examples but seems like they're not all for the 11u14 board so will take further investigation.
FLOSS project equivalent to CMSIS: libopencm3 (Doesn't yet seem to be useful for NXP devices.)
nxp_lpcxpresso_11u14_usbd_lib_hid_generic succeeds but the device doesn't appear as a USB device when plugged in--I'm not sure if the target board is actually powered or something else...
Might be useful sometime: "Tutorial about USB HID Report Descriptors"
LPCXpressoLPC11U14revA.pdf schematic file. This document helpfully includes the comment:
"SJ1 - short to power LPCXpresso board from target side USB VBUS (J8)."
When I shorted the solder jumper in question (near the Target's mini-USB connector) the generic USB device appeared! Yay. :)
Random link: "ChibiOS EmbeddedWare • View topic - LPCXpresso LPC11U14 (anyone working on it?)"
Looks like it might be older but may be useful: http://nr-sdk.googlecode.com/svn/trunk/firmware/device/NXP_LUFA/Example_GenericHIDDevice/readme.txt