FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [December 2009 Threads] Ethernet boot loader and the task?Posted by Bill Yang on 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.
Bill
RE: Ethernet boot loader and the task?Posted by Richard on 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.
Regards.
RE: Ethernet boot loader and the task?Posted by Bill Yang on 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?
Thanks, Bill
RE: Ethernet boot loader and the task?Posted by Bill Yang on 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.
Regards, Bill
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|