Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT




Loading

Problem porting from LPC1114 to LPC11U3

Posted by henning larsen on December 26, 2012
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.

RE: Problem porting from LPC1114 to LPC11U3

Posted by Dave on December 26, 2012
Are you sure the LPC11U35 is running at the speed you think it is? Maybe there is a problem with the clock configuration.

RE: Problem porting from LPC1114 to LPC11U3

Posted by henning larsen on December 29, 2012
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

RE: Problem porting from LPC1114 to LPC11U3

Posted by Richard on December 29, 2012
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.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS