UPDATE!
Christian, I have found a workaround to the problem you have been experiencing. I too have a custom PCB based on the 48-pin bare LPC11U24. I found your post by accident and was experiencing the same issues as you.
Basically, I found that in order for pin P0_15 to be used as a digital out, P0_10 needs to be configured as a GPIO as well. This is a dirty hack I discovered by accident. Here is the code that got it working. Basically, you need to set PIO0_10 to GPIO mode before PIO0_15 is accessible (!)
#include "mbed.h"
DigitalOut robbiePin(P0_10);
DigitalOut PWRKEY(P0_15);
int main() {
// this single line commented-out, both P0_10 and P0_15 are unusable as GPIO
LPC_IOCON->SWCLK_PIO0_10 |= 0x00000081;
// this only works if the above line for P0_10 is present (!!)
LPC_IOCON->SWDIO_PIO0_15 |= 0x00000081;
while(1) {
robbiePin = 1;
PWRKEY = 1;
wait(0.2);
robbiePin = 0;
PWRKEY = 0;
wait(0.2);
}
}
I suspect the above behavior has to do with how the mbed/LPC11U24 decides whether or not the debug interface is running. However, there is a slightly more alarming issue the above code demonstrates which I suspect is an innocent oversight in the mbed library itself: It appears that DigitalOut's constructor (and the output() method in the case of DigitalInOut) is improperly configuring the following pins: P0_0 (reset), P0_10, P0_11, P0_12, P0_13, P0_14 and P0_15. If the user code is asking to use these pins as GPIO (instead of their defaults), shouldn't/couldn't the mbed library gracefully accept?
Many users have yet to encounter this bug because it requires a custom PCB to reproduce... but such pcbs are rapidly becoming popular :)
According to the UM10462 PDF manual, [PIO0_10, PIO0_11, PIO0_12, PIO0_13, PIO0_14, PIO0_15, PIO0_0/reset] all require that configuration bits #2:0 be set to 0x1 (instead of 0) in order for the ports to be used as GPIO rather than their default roles. This is in contrast to all the other GPIO pins, which require bits #2:0 to be set to 0 in order to be configured for GPIO. That's why I believe it was an innocent mistake in the case of the mbed library, especially considering these pins are normally tied up on the retail mbed LPC11U24.
Here's a concrete example:
#include "mbed.h"
DigitalOut mypin(P0_10); // this is one of the affected pins
int main() {
// configure mypin to be an output
mypin.output();
// at this point, the above call via mbed library has set LPC_IOCON->SWCLK_PIO0_10 == 0x00000080
// although this *would've* been the right thing to do on most of the LPC11U24 pins, for certain pins
// such as P0_10, this is the wrong thing to do. According to the UM10462 manual (pg. 73)
// for this pin bytes #2:0 should be 0x1 (in other words == 0x00000081)
}
I'm hoping at the very least the tiny mixup on the configuration of the pins affected can be fixed in the mbed library...
Cheers!
So....
I designed a board, with the LPC11U24, in the 48 pin variant. This is because of limited space.
I've got one problem, the pin P0_15 that is used as a DigitalOut, won't work this way.
In the schematic of the mbed-010.2 (LPC11U24), I found that the SWDIO (P0_15) is connected to the mbed interface.
So my question: Is that compiler set up, so that even if i tell it to be controlled from my code,
I cannot use this pin?
If that's the case, how would I go around fixing this?
Thanks in advance
Lerche