lwip+modbus/tcp

[alireza_roozitalab]

Posted on September 03, 2013 at 17:04

hello every one .i tried to add modbus/tcp protocol in lwip(in webserver demo).

i did it and it worked .but the problem is : if i use modbus/tcp protocol(via modbus poll software) it works correctly and if i use the web server is works too

correctly.

but if i use both of them in same time(refresh the web and read data via modbus poll) it makes hard fault.and stop working!

thanks for helping me

alireza roozitalab

#rtos

[Tesla DeLorean]

Posted on September 03, 2013 at 18:36

Code that Hard Faults should be easy enough to debug. Decode the faulting state, understand the instructions that faulted, and why they could have faulted.

Add more diagnostic or telemetry data to understand how it got there, or utilize hardware trace if you have it.

At a guess I'd say look at the stack size, and corruption of the stack.

[Palacios.Bruno]

Posted on September 03, 2013 at 21:28

Hello,

clive1 could be right, maybe you are using more memory than available or you´ve created a variable (array) bigger than.

But as he said, debug it and see what routine/variable is corrupting the program. Put a breakpoint in the while() of the hard fault routine to see when it happens.

Best regards!

[jpeacock2399]

Posted on September 03, 2013 at 21:35

A common problem in realtime systems is when tasks work standalone but not together.  You likely have some kind of race condition where global variables are updated at the wrong times, or access is optimized by the compiler to mask updates (check your volatile declarations).  Or you may have a simultaneous update problem where both tasks update a global without some type of synchronization, like a semaphore or mutex.

If you are seeing hard, bus or usage faults you may be clobbering a task stack or a shared global with some kind of buffer overrun.  Or you are passing data that's on a stack, which is corrupted when you exit the calling routine.  Check for data passed between tasks that's on a stack and not statically allocated.

These types of bugs can be very difficult to find, especially if it's someone else's code that wasn't designed for multi-tasking.  For a first pass make sure the shared globals are declared as volatile, and you have some type of locking mechanism to manage updates. 

Remember, an interrupt and task context change can happen in the middle of a line of code.  Between the time you evaluate the assignment on the right side and store the result on the left side of a statement the underlying variables can be altered by another task.

  Jack Peacock

[alireza_roozitalab]

Posted on September 04, 2013 at 09:49

thanks for your reply .but i don't use rtx or rtos.i write the program standalone.when the packet received , lwip check its' type and protocol, the condition is :if it is ip type and tcp protocol ,it checks the port.if port is 80 lwip it will  go on its' web server demo.if the port is 502(modbus/tcp standard port) the program use the source that i wrote and then go to low level layers and send modbustcp/packet.i debug the fault.when the fault

occurred

the check box of the preciserr and bfarvalid will activate and bus_fult_state=0x82 and bus_faultaddr:0x56203a79 .

[Tesla DeLorean]

Posted on September 04, 2013 at 14:31

That looks as if it could be ASCII data being loaded as a pointer. You're going to have to dig into the code that's faulting, I have no context to work with here.

You'll want to look at the assembler code, and work backward to try and understand how it got to the state it did. You can examine the processor registers, and stack frame.

[frankmeyer9]

Posted on September 04, 2013 at 15:23

That looks as if it could be ASCII data being loaded as a pointer ...

 

...which could possibly be caused by a stack overflow.

AFAIK, TCP/IP packets can have a size up to 4k.

[jpeacock2399]

Posted on September 04, 2013 at 15:45

The MTU (max transmission unit) field determines the packet size, up to about 1500 for regular packets, or 4K for jumbo packets.  This sounds like a buffer overflow or buffer allocated on the stack, address passed to subroutine, then stack is released.

  Jack Peacock

[alireza_roozitalab]

Posted on September 07, 2013 at 09:58

thanks for your reply,

i increase the stack size but the problem still  stands

the fault  occurred in ''tcp_in'' function in pcb(protocol control block) part.

i have three tags in index.shtml if i remove them ,  the program with modbus tcp work correctly.the cgi works but i cant use tags in program.

[sayagyimyo]

Posted on August 16, 2016 at 05:44

hi mr roozitalab.alireza

I am trying Modbus server on stm32f207 device.how you implement in your case?what board you use? any source code for me to reference.

pls kindly send me the source code to

mailto:[e-mail]

if you still have one.

thanks in advance.