I tried to resume work on one of my LPC11U35 projects today, but I'm unable to get my previously working program to run. It keeps throwing hard fault exceptions before it even gets to main(). Older known-good versions are hard faulting as well. In trying to reproduce the problem outside of my main code, I've discovered something very weird that I think might be related:

If I create a demo program using mbed-rtos and USBDevice, everything works fine. But if I add a class with a destructor to the mix, the USB driver no longer works, and Windows reports a malfunction. Simply removing the destructor "fixes" the problem. Reverting to older versions of mbed-rtos and USBDevice has no effect.

At this point, I believe this may be a compiler/linker problem that's outside of my control... Here is a demo program demonstrating the bug:

[Repository '/users/neilt6/code/LPC11U35_WeirdBug/' not found]

Hi Neil - I'm looking at this but dont have a LPC11u35. Is this behavior confirmed on any other platforms? I see you have a few. Just want to make sure we're chasing the same thing :)

Thanks Sam. I haven't tested any other platforms yet, but I just hit a breakthrough on the LPC11U35. It appears __aeabi_atexit() is the culprit. According to ARM, this function uses dynamic memory to manage a linked-list of destructors for static/global objects at runtime. Overriding it like so allowed my test program to run properly:

extern "C" int __aeabi_atexit(void *obj, void(*func)(void *), void *d)
{
    return 0;
}

Based on this, it would seem the heap isn't working properly during initialization, although I tested it and it still works in main().

I just tested the mbed LPC11U24, LPCXpresso11U68, and LPCXpresso1549, and they're all exhibiting the same issue.

I just tried exporting my test program to Keil µVision 4, and running it on the mbed LPC11U24 with the same optimization levels as the online compiler. It did NOT exhibit the issue.

I built online for the lpc1768 and was not able to reproduce the failure. Will keep trying different boards. I did notice that with both the connect false and the constructor false the hid device did enumerate which I found odd.

I didn't test the LPC1768, but it uses the ARM standard toolchain so it might not be affected. I'll try it tomorrow. USBDevice::connect(false) is for a non-blocking connect.

I just tested the LPC1768, and can confirm that it is NOT affected by this issue. Probably because it uses the ARM standard toolchain, whereas the others use the ARM micro toolchain.

Here's something interesting, startup_LPC11xx.S doesn't appear to be defining __heap_base and __heap_limit properly. The assumption seems to be that __user_setup_stackheap() in sys.cpp will initialize the heap. However, according to Keil's documentation, that method isn't applicable to microlib... I would try changing the values, but unfortunately the online compiler isn't letting me edit startup_LPC11xx.S.

Any luck so far Sam? I've managed to get the rest of my programs to run by overriding & disabling __aeabi_atexit(), but this obviously isn't ideal...

Neil,

I've logged an internal issue to investigate this, we dont have any answers at the moment, but when we do we will post the results here .

Keep up the great work!

-Austin

(wrong account)

Thanks Austin!