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.

  • Resolved

RTOS/TM4C129XNCZAD: NDK IP change with HTTP connection

Part Number: TM4C129XNCZAD

Tool/software: TI-RTOS

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"

  • 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.

  • In reply to Peter Borenstein:

    I made a low priority task which successfully set the new IP address. The CGI function posts this task's semaphore and the task runs after the CGI function. The IP address is changed, but the chips runs into loader_exit() in response to any network activity. Pinging unrelated IP addresses will put the chip at loader_exit().
  • In reply to Peter Borenstein:

    I set a button press to change the IP address. This worked very well with the HTTP server.

    This seems to be a timing issue. Something happens after the CGI function to make changing the IP address safe.

    The CGI can set some timer for changing the IP address, but this is poor engineering. There must be some authoritative source that tells me when changing the IP is safe...
  • In reply to Peter Borenstein:

    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 Peter Borenstein:

    Hi Peter,

    Sorry for the delay. The hand-off on handling forum threads did not go smoothly during a vacation.

    Is this still a problem?

    Todd
  • 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?

  • In reply to Peter Borenstein:

    Hi Peter,

    I just wanted to let you know that I'm looking into this and will get back to tomorrow.

    Steve

  • In reply to Steven Connell:

    Hi Peter,

    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.

    Steve

  • In reply to Steven Connell:

    Steven,

    Did you ever get to the bottom of this problem?

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.