#include "mbed.h"
 
DigitalInOut mypin(P0_10); // this is one of the affected pins

// set this to 0 for the default (buggy) mbed behavior
// set this to 1 to use my hacky workaround
int workAroundTheMbedBug = 0;

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 (section 7.4.1.11 SWCLK_PIO0_10 register)
    // for P0_10, bytes #2:0 should be 0x1 (in other words == 0x00000081)

    if(workAroundTheMbedBug) {
        LPC_IOCON->SWCLK_PIO0_10 = 0x00000081;
    }

    // the code below only works if workAroundTheMbedBug is true
    mypin = 1;
    wait(0.5);
    mypin = 0;
    wait(0.5);
}

Hey @mbed people! I have bug report for the mbed library which affects people [[/blog/entry/Get-your-custom-PCB-made-for-free|building custom PCBs based on the LPC11U24]]. Configuration of certain pins for GPIO use (DigitalOut, DigitalInOut, etc) are not working as expected. It appears that DigitalOut's constructor (and the output() method in the case of DigitalInOut) is improperly configuring the some of the pins which are normally used by the mbed "magic" chip. I have successfully confirmed the bug on at least the following pins: P0_10, P0_15, P0_18. Since I don't have access to the @mbed source code, I'm hoping the team can save me from having to test every single pin since this should be easily spotted in the code. Note that the case of P0_18 (and probably P0_19?) is slightly different, and the config register does not obey the same order as the other two. To work around it is quite ugly because each time you want to use one of these affect pins you need to manually re-configure the pin, especially after any call to DigitalInOut's output() method (or just the constructor of DigitalOut). Here is a clear example: <<code>> #include "mbed.h" DigitalInOut mypin(P0_10); // this is one of the affected pins // set this to 0 for the default (buggy) mbed behavior // set this to 1 to use my hacky workaround int workAroundTheMbedBug = 0; 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 (section 7.4.1.11 SWCLK_PIO0_10 register) // for P0_10, bytes #2:0 should be 0x1 (in other words == 0x00000081) if(workAroundTheMbedBug) { LPC_IOCON->SWCLK_PIO0_10 = 0x00000081; } // the code below only works if workAroundTheMbedBug is true mypin = 1; wait(0.5); mypin = 0; wait(0.5); } <</code>> In defense of the @mbed developers, I believe these pins were rightfully never tested as GPIO, since on a normal mbed, they're busy talking to the magic chip. However, since the LPC11U24 is indeed becoming a popular stand-alone pcb project, this is going to start causing headaches for many users who will wonder "why doesn't it work? Did I mess up my PCB AGAIN?", which is exactly how I discovered this behavior. As for "breaking" a real mbed, I believe that if a user is asking for P0_10 (which is normally connected to the magic chip) to be a DigitalInOut, the mbed library should make it so. I don't believe there is any way to damage a genuine mbed if users are allowed to fiddle with these pins... and most users using the port-notation PinNames are doing so because they have a custom PCB :) Although I haven't tested them all yet, I *suspect* these pins are affected: P0_10, P0_11, P0_12, P0_13, P0_14, P0_15, P0_18, P0_19 and possibly P0_0 (reset) On a positive note, I did test all 8 AnalogIn's on the LPC11U24 barebones, and they all work with the mbed library - even PO_15 (which does not work for Digital I/O, as per this bug report). PS [[https://mbed.org/forum/mbed/topic/3603/|Here is a post]] from a user who never figured out why his PCB wasn't working, and this bug report would have saved him. I did reply, but probably after he gave up. My hope is to prevent any more frustration!

// These pins are setup for UART by mbed libraries, no matter how nicely you ask them to be GPIO
// so we have to blow-out whatever the mbed library is doing behind the scenes to use these as GPIO.
// This *must* come after any calls to DigitalOut constructor, DigitalInOut's output() method
LPC_IOCON->PIO0_18 = 0x00000080;
LPC_IOCON->PIO0_19 = 0x00000080;

Bumpity-bump-bump! Also, I have since confirmed that these are also affected: P0_18, P0_19 You need to set them as follows for use as GPIO. Notice the bit field is not the same as for P0_10, this is because the configuration register is different for these pins: <<code>> // These pins are setup for UART by mbed libraries, no matter how nicely you ask them to be GPIO // so we have to blow-out whatever the mbed library is doing behind the scenes to use these as GPIO. // This *must* come after any calls to DigitalOut constructor, DigitalInOut's output() method LPC_IOCON->PIO0_18 = 0x00000080; LPC_IOCON->PIO0_19 = 0x00000080; <</code>> I hope this doesn't scare anybody... I'm just trying to help save people from giving up in the future because of these somewhat unexpected results. PS a photo showing our tiny dev board which allows us to use all pins on the LPC11U24: {{/media/uploads/robodude/_scaled_lpc11u24-tester.jpg}}

Hi Robbie, Thanks for this. It's something that we're aware of and are hoping to fix at some point. When we have further news we'll let you know. That's a nice photo of your custom PCB. Steve

Hey Steve, Thanks for the reply. Looking forward to this. Hopefully it will be sometime soonish... not just for me but for the others that venture into custom PCBs! PS that's the 48-pin version of the chip!