Cannot make lwip work with freertos on RM57lx launchpad

Hi Pedro,
Can you find out the cause to the data abort exception? You can read the the data fault status register and data fault address register in the CPU. What might have happened is that the FreeRTOS will be operating in user mode and if you are trying to create a task in user mode trying to access some registers that are privileged mode protected then you can have problem or it might be something related to the MPU.

Here is one post that talks about FreeRTOS+Lwip which might be helpful. However, it is not specific to RM57 but rather the TMS570LS3137.
e2e.ti.com/.../1984096

I cannot find these registers addresses on the datasheet, do you know which are their correspondents addresses?
Also I already have seen that post a few times, tried some of their tips but it didn't work

In the register window you can find under Cp15 for these registers. See below snippet.

Please also go to ARM TRM for details to decode the status registers on the cause of the abort. 

Ok, this is what I have.

Can you explain me what does it means?

Hi Pedro,

 I want to make sure that you are getting a data abort. Can you place a breakpoint at the data abort entry which is  at address 0x10? If you are truly getting a data abort then the status register is saying that you have a MPU background fault. A background fault is generated when the MPU is enabled and a memory access is made to an address that is not within an enabled subregion of an MPU region. Looking at the data fault address register the value shows 0x04E58D1C. This is an illegal address region.  You might want to setup a watchpoint such that when CPU accesses address 0x04E58D1C then it will halt to understand what is going on. Also check the ESM module to see if any flags are set.

Ok, using a breakpoint on position 0x10 I've got the data abort. So yes, that's the problem. Adding a watchpoint into the position I passed to you I did not get any break, looking a little bit more I realized that the data fault address register changes on each execution. So this means that The code does not abort allways on the same time, I can also see that while debugging, when my prints are executed different times before crashes. 

Do you have any other tip? 

Thank you

Hi,
Did the crash happen immediately or your Ethernet was working for a while before abort/crash?

Can you try to increase the stack size and see if that makes a difference?

Can you try to comment out your printf statements? I just want to rule out printf has anything to do with the crashing. The printf can invoke dynamic memory allocation and if the stack size is not enough it may lead to crash. Not to say that printf is the problem. It is just one thing to rule out at a time.

Since I was having troubles using both at the same time, I decided to test them separetaly, so right now I'm only starting the connection, without send any packet. I was having trouble with the printf too, but when I reduced the buffer I was able to print something, maybe that could still be the problem.

If I share my project with you will be easier to detect the problem?