Quality RTOS & Embedded Software

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




Loading

Debugging procedure &Eclipse LPC2368 port

Posted by boozle on December 10, 2007
Thank you Richard for promptly helping me find the location of the Eclipse SAM7 port. Once found that port immediately worked perfectly, including the web server.

I am having difficulties with the Eclipse LPC2368 port. If I exclude the webserver by commenting out:
// xTaskCreate( vuIP_Task, ( signed portCHAR * ) "uIP", mainBASIC_WEB_STACK_SIZE, NULL, mainCHECK_TASK_PRIORITY - 1, NULL ); It works perfectly.

In the LPC2368 port, with the original set of tasks including the vuIPTask, there seemed to be little spare space left in the heap area prior to starting so I commented out some of the other memory intensive xTaskCreates and there seemed to be 1800Hex bytes free before the scheduler was started with the vuip_Task created but it still crashes in the same way immediately after the scheduler starts.

The debugging I have done so far has helped to understand Eclipse and the structure of FreeRTOS, so I am happy to continue. At this stage I think the crash occurs as the scheduler is starting. Two questions:

Are there any known issues with the Eclipse LPC2368 port?
Are there any suggestions about how to approach debugging such problems?

RE: Debugging procedure &Eclipse LPC2368 port

Posted by Dave on December 10, 2007
I just had a quick look at the makefile and it looks like there is not a sprintf() implementation included. This means that the GCC sprintf() will be used and this can cause problems with stack usage depending on the library build used.

Free up heap space by prevent some of the other demo tasks from being created as you have done before, then try assigning a huge stack to the uIP task just as a test. If this makes a difference then you can use printf-stdarg.c in your project as a replacement for the GCC sprintf(). You will find the file in the FreeRTOS zip file.

When it crashes do you end up in data abort? If so then inspect pxCurrentTCB to see which task was running. The structure also gives you information that will help diagnose a stack issue.

RE: Debugging procedure &Eclipse LPC2368 port

Posted by boozle on December 10, 2007
Thanks for suggestion, tried it, but same symptoms.

I note that the SAM7X_256 which is working OK also uses sprintf() and includes a comment in the definition of the vuip stack size related to sprintf(). I used a similar size to the SAM7 noting that minimum size defined for the LPC2368 is much smaller than in the SAM7. There is some other RAM in the LPC2368.

RE: Debugging procedure &Eclipse LPC2368 port

Posted by Dave on December 10, 2007
Can you please select the message you are replying to before writing the reply. The forum is not very clever in its function and this is the best way of ensuring it is easy to read the thread in the right order.

What happens when the system stops working. Do you go into data abort? Does xTaskStartScheduler() ever return?

Try placing a break point at the top of vLCDTask() and vuIP_Task() to see if it is ever hit. This will show if the scheduler actually ever started. You might need to do this one at a time due to only 2 hardware breakpoints being available.

Are you using the same hardware as used to develop the demo?

RE: Debugging procedure &Eclipse LPC2368 port

Posted by boozle on December 11, 2007
Dave

Yes I have re-looked at the bl main in boot.s The code ends up in the endless_loop which is where a return from the scheduler ends up. A comment at that point would have helped.

Yes I am using MBC2300 board

vTaskStartScheduler just points to the first task, starts interrupts and then puts the task into execution by restoring the context. What types of problems will result in a return? vTaskEndScheduler will do this but there appears to be no explicit calls to this.

I will just strip it down to a minimum number of tasks including vuIP and see which tasks start and which don't using two breakpoints at a time as you suggest.

Thanks for the suggestions it is only when I looked back at boot.s that I realised that endless_loop was the return.

Would it not be better to create that loop in main.c after the call to vTaskStartScheduler?

Is there any useful information to look at once it is in endless_loop?

I configured the trace but I don't think there was any record of tasks starting. I will look at the trace on the working SAM7 port to see the normal starting sequence of tasks and look again at the trace.



RE: Debugging procedure &Eclipse LPC2368 port

Posted by Martin on December 14, 2007
Check the revision of the LPC2368 populated on your eval-board. For marking see errata sheet 1.5 or later (topic Ethernet.1) on NXP website.
If you use revision 'A' or 'B' you must not set P1.6 in PINSEL2 otherwise the whole application crashes! In the original Embedded Ethernet Demo this bit is set!



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




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

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

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

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

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists