Debugging procedure &Eclipse LPC2368 port

boozle wrote on Monday, 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?

davedoors wrote on Monday, 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.

boozle wrote on Monday, 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.

davedoors wrote on Monday, 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?

boozle wrote on Tuesday, December 11, 2007:


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.

martin_99 wrote on Friday, 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!