Starting from CORTEX_M0_LPC1114_LPCXpresso(CodeRed) demo which works flawlessly, I have ported this to an LPC11U35 processor (CodeRed). It works - almost.

When IntQueue is NOT in the testsuite - "BlockTim.c, CountingSem.c, RecMutex.c and RegTest's" works flawlessly.
When IntQueue is included alone, it fails the built in tests.
When IntQueue is included together with one or more of the other test demo's, then IntQueue AND the other tests fails.
In other words, it appears that the IntQueue test is corrupting the system. There are no fatal halts, stack overflow or exceptions - the test's simply fails after a variable time (< couple minutes)!

I use the port.c, and portmacro.h from the Cortex_M0 folder like the LPC1114 port does. I have updated the systemLPC11xx.c to include the LPC11Uxx.h header file instead, and updated the cr_startup_lpc11.c to have the proper interrupt handlers hooked. Those who differ from the LPC1114 are routed to the IntDefaultHandler and are never called.

I would not expect any core functionality differences between LPC1114 and LPC11U35.

This is very frustrating. Anyone with good ideas of what can be the probable cause?

Main difference apart from periperals is Ram and flash. LPC11U35/401 64kB Flash, 10kB Ram, LPC1114/301 32kB Flash, and 8kB Ram - surely not the problem here.

Are you sure the LPC11U35 is running at the speed you think it is? Maybe there is a problem with the clock configuration.

Thank you Davedoors for your most relevant suggestion. I have very carefully checked and the clock is 48MHz - which should be fine.
May I add that Dave's suggestion is very relevant because the PLL and the clocking scheme is bewildering configurable (!) and you can easily get it to generate much higher frequencies than specified by NXP and eventually it will fail due to hardware timing violations or you may end up having an unstable clock when operation of the PLL's CCO oscillator is asked to operate beyond its range of 156MHz to 320MHz.
In fact you may - as I did during my tests - end up in a deadlock with an unusable board at hands! This happens if the programmed system frequency is too high, the LPCXpresso debugger can no longer program the flash! I did not find any way to change the LPCXpresso tool chain to get out of this deadlock. Is this a bug? I was saved by an IAR toolchain and I-jet debugger. Apparently IAR tools "overrules" the flash settings and works also in such cases.
Bottom line with respect to the topic of this thread, however - I did not find the reason for the COortexM0 LPC11U35 port failing its test suite. Except that it appears to apply to the original port for LPC1114 as well, as described in another thread.
Thanks again for your suggestions.
Henning

In the LPCXpresso tool, if you go to the debug tab of the launch configuration window you will find a check box called "vector catch". Checking that might enable you to connect to your misconfigured board.

Regards.