Using pins meant for mbed interface

08 Jun 2012

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

08 Jun 2012

Got it, just pushed a couple of bytes into the SWDIO_PIO0_15 register.
Just for laughs, of how simple it was: LPC_IOCON->SWDIO_PIO0_15 |= (0x11); - Makes it Digital...

11 Jun 2012

Now I tested the darn thing, compiles perfect,
and I can set it high.

But... The program doesn't "return" after setting the pin high.
This is strange behaviour.
Anybody got an idea?


11 Jun 2012

#include "mbed.h"

DigitalOut PWRKEY(P0_15);        // This Pin is the troublesome

int main(){
    LPC_IOCON->SWDIO_PIO0_15 |= (0x81);              // Take control of the pin
    PWRKEY = 1;                                      // It goes high - But never go low after the wait. 
    PWRKEY = 0;

This simply stops the program from going any further. Not very nice.

11 Jun 2012


11 Jun 2012

would the pin only be low for a few microseconds?

because there is only one delay.

?? the "ASM" in the loop?

not sure Ceri

13 Jun 2012

Tried putting the LPC_IOCON->SWDIO_PIO0_15 |= (0x81); line in the loop to the PWRKEY digitalout. This doesn't change a thing.

Perhaps Simon, Chris or any "deep-mbed'r" can answer this?

Thanks very much in advance.

Once this problem is solved, I'll put up to the site, what it is the LPC11U24 is doing.


14 Jun 2012

Sorry for doing this again -> up.

18 Jun 2012

Try -1 or subtract 1 or -= 1

26 Jun 2012

Found the problem: Some sort of error when running the program. I threw HardFault at me.

Rewrote, now it's working.

01 Jul 2012

Christian, can you post the working code?

01 Jul 2012

Sorry it didn' follow up on the post. Never actually got it working,
just rewired on my board.

/ Lerche

20 Sep 2012


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;
        robbiePin = 0;
        PWRKEY = 0;

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

    // 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...