This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Part Number: TM4C129XNCZAD
Trying to change the IP address when using the HTTP server gives me the error: 00010.933 llExit: Illegal call to llExit()
The code changes the IP in response to an HTTP GET which contains the new IP value. I am trying to remove the CFGTAG_IPNET configuration in the same CGI function that received the HTTP GET message.
The CGI function gives the error when calling CfgRemoveEntry() and then CfgAddEntry() is not able to run. I can't tell for sure because the chip his loader_exit() when attempting to single step over the functions.
Other post have had a priority issue when getting the llExit error. There is a task called dchild that gets priority 9 (kernel) but I think this task is related to the HTTP server. I did not create this task in XGCONF.
Am I removing IPs in an unreasonable way? What is causing my error?
There's a similar situation here: e2e.ti.com/.../2050531 But Leonardo Muricy's response does not make sense (to me). When I try to ad a new IP configuration entry without removing the old one, I get a callback error and a message that says "00006.623 BindNew: Duplicate bindings ignored"
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Peter Borenstein:
Instead of trying to change the IP address in the CGI function, I created a low priority SWI. The CGI posts the SWI and it still crashes the stack. The chips ends up at loader_exit(), but the console output is different: 00010.186 llExit: Illegal call to llExit() Network Removed: If-1:192.168.0.1 00010.186 llEnter: Illegal reentrant call to llEnter() Network Added: If-1:192.168.0.100 When is it safe for the stack to change and IP address?
Edit: This is actually a bad idea. The CGI function gets interrupted by the SWI, so I haven't actually changed the timing of anything; lateral progress.
I used the clock module to create a half second delay. The CGI function tigers the clock to start, and then the clock function changes the IP address with no problems. This feels more like a "make it fit" fix as opposed to understanding the root cause of a problem and creating a solution. Why does the stack crash when the IP is changed within a CGI function? How much time has to pass before the IP address should be changed?
In reply to ToddMullanix:
Hi Todd, Yes, I still need help. I have more of a workaround than a fix. Everything slows down this time of year, including me! It is vacation season. The goal is to change IP address according to a user input. I chose to do configuration through a browser interface by using the HTTP server module. An HTML page is loaded on the chip's firmware. The web browser loads the page and responds to the HTML form with an HTTP GET message. The chip handles the message in a .CGI function. The chip then sends the browser another HTML page that reads "Success!". The problem is the stack breaks when changing the IP during the CGI function or immediately after the CGI function. I get the error "llExit: Illegal call to llExit()" on the console and the chip hits a break point at loader_exit(). I have seen in other threads this error coming from tasks that exceed kernel priority, but this is not the case. The workaround is the CGI function sets a 0.5 second timer. The timer ISR then changes the IP. I think the ISR is technically called a HWI in the context of your RTOS. This workaround seems dangerous because I am guessing that something changes 0.5 seconds after the HTTP communication to make the IP address change safe. There's a risk that the same something can occur again after 0.5 seconds to make the change unsafe during the ISR.
Could you tell me what this something is and how to check for it?
I just wanted to let you know that I'm looking into this and will get back to tomorrow.
In reply to Steven Connell:
I wanted to update you again. I was able to reproduce the problem you are seeing. I'm still digging into it and will reply back here once I have some more insight.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.