Ethernet boot loader and the task?

yyang2000 wrote on Thursday, December 17, 2009:

Hi, I wonder if someone can help me to figure out the issue as below described.

My application is based on the sample of Cortex_LM3SXXXX_IAR_Keil demo under FreeRTOS rev 5.4.2. It used to be booted by a serial boot loader and run just fine. Since I replaced it with an Ethernet boot loader, my application always stopped in midway during the booting. I use the on-board LED to trace the program and found the application ran and passed the hardware initialization code. After then it failed during a UART receive task creation. I use an EK-LM3S6965 Evaluation board to debug on it. It runs just fine with the debug mode. So I cannot find where or what is wrong. I have several quesitons.

Why the serial boot loader can boot the application fine, but Ethernet boot loader not?  (Both have the same definition APP_START_ADDRESS = 0x1000)

Is it possible the application vector table has relocated and conflicted with Ethernet boot loader in SRAM?

Does debug mode just runs from the application vector table at the starting address (0x1000)? Because debug mode does not go through the boot loader, it did not have the problem. So the problem is in Ethernet boot loader, Is it true?

I was talking with Luminary tech support guys, they could not figure out what the cause is. I suspect the problem may relate to the FreeRTOS task priority or stack size settings. The UART receive task was set to the lowest priority that is tskIDLE_PRIORITY.

Any comments will be appreciated.


rtel wrote on Friday, December 18, 2009:

Sounds like quite a complicated problem to track down.  I can only offer the simple suggestion to check that the UART interrupt is not firing before the scheduler is started.  This could cause problems if the interrupt attempted to unblock a task.


yyang2000 wrote on Friday, December 18, 2009:

Hi Richard, thanks for your replying. I am a little bit rusty. What is meant of “UART interrupt is not firing….”? does mean the UART interrupt service routine not get service?

If my understanding is correct, the UART generates a interrupt and goes to its ISR. The ISR sends a message to the UART task through the queue. Since the task scheduler is not started yet. So it cannot access the UART task that causes problem.  Am I right?

In this situation, the solution may disable the UART interrupt during its initialization and enable UART interrupt just before the task scheduler starting. Any other suggestion will be welcome?


yyang2000 wrote on Friday, December 18, 2009:

Hi Richard,

I follow the lead you sugested that I found the problem that could be the UART interrupt is not serviced before the scheduler is started. So I disabled the UART interrupt during its initialization and enabled it during the task creation of the UART receive task routine that is prior to the forever loop starts. It works now.

I don’t know there may be other better solutions than this.  I wonder if you have any idea.