lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] tcp_output.c fault?


From: Kjetil Østerås
Subject: Re: [lwip-users] tcp_output.c fault?
Date: Sat, 13 Jun 2015 08:05:16 +0200

Hi Xun,

This might be an alignment issue. What is the values of R0 and SP when this happens? LDR arguments must be 4-byte aligned.

--
Kjetil Østerås

Den fredag 12. juni 2015 skrev Xun Chen <address@hidden> følgende:
More on the configuration:

1) No RTOS
2) 80000KB heap

A few more faults generated, always the same place inside tcp_output

It seems the image were dropped.

So I am going to add some text to it.

Hi there,

I am using TI's TiVa (TM4C1294) for a TCP-based project

The code is developed on CCS, and the TiVaware contains lwip 1.4.1.

I got my codes working (sort of), pumping out data acquired from SSI
port (via ISR) to TCP port at around 200kb/sec.

After hours running, it ran into a hard fault, with NVIC_FAULT_STAT_IMPRE
flag, which means Imprecise Data Bus Error

<This screen capture is not so important to lwip community since it only deal with TiVa status>


Then I began to study the stack to see what caused this fault, here is
the SP pointer and the memory dump of the stack

<This screen capture is not so important to lwip community since it is only a memory dump that leads to the next section>


>From there, I can track down the last instruction before the hardfault

The fault is inside tcp_output.c, around the highlighted area.

Here are the codes inside tcp_output.c

----------------------------------------

tcp_output(struct tcp_pcb *pcb)
{
...........


    if (TCP_TCPLEN(seg) > 0) {
      seg->next = NULL;
      /* unacked list is empty? */
      if (pcb->unacked == NULL) {
        pcb->unacked = seg;
        useg = seg;
      /* unacked list is not empty? */
      } else {
        /* In the case of fast retransmit, the packet should not go to the tail
         * of the unacked queue, but rather somewhere before it. We need to check for
         * this case. -STJ Jul 27, 2004 */
        if (TCP_SEQ_LT(ntohl(seg->tcphdr->seqno), ntohl(useg->tcphdr->seqno))) {
          /* add segment to before tail of unacked list, keeping the list sorted */
          struct tcp_seg **cur_seg = &(pcb->unacked);
          while (*cur_seg &&
            TCP_SEQ_LT(ntohl((*cur_seg)->tcphdr->seqno), ntohl(seg->tcphdr->seqno))) {
              cur_seg = &((*cur_seg)->next );
          }
          seg->next = (*cur_seg);
          (*cur_seg) = seg; <<<<<<<<<<<<<<< hardfault around here
        } else {
          /* add segment to tail of unacked list */
          useg->next = seg;
          useg = useg->next;
        }
      }
    /* do not queue empty segments on the unacked list */
    } else {
      tcp_seg_free(seg);
    }
    seg = pcb->unsent;

........
}

---------------------------------------

(*cur_seg) = seg; <<<<<<<<<<<<<<< hardfault around here

Does any one have suggestion on what I should trace next? Or is there a
known bug in lwip around this area?

Thanks!




On 6/12/2015 1:18 PM, address@hidden wrote:
----------------------------------------------------------------------

Hi there,

I am using TI's TiVa (TM4C1294) for a TCP-based project

The code is developed on CCS, and the TiVaware contains lwip 1.4.1.

I got my codes working (sort of), pumping out data acquired from SSI
port (via ISR) to TCP port at around 200kb/sec.

Once hours running, it ran into a hard fault, with NVIC_FAULT_STAT_IMPRE
flag, which means Imprecise Data Bus Error




Then I began to study the stack to see what caused this fault, here is
the SP pointer and the memory dump of the stack




  From there, I can track down the last instruction before the hardfault





The fault is inside tcp_output.c, around the highlighted area.

Does any one have suggestion on what I should trace next? Or is this a
known bug in lwip?

Thanks!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nongnu.org/archive/html/lwip-users/attachments/20150612/2a0ef8c3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gecbhcjb.gif
Type: image/gif
Size: 204990 bytes
Desc: not available
URL: <http://lists.nongnu.org/archive/html/lwip-users/attachments/20150612/2a0ef8c3/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fgdjgeae.gif
Type: image/gif
Size: 189632 bytes
Desc: not available
URL: <http://lists.nongnu.org/archive/html/lwip-users/attachments/20150612/2a0ef8c3/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bhddgifd.gif
Type: image/gif
Size: 311041 bytes
Desc: not available
URL: <http://lists.nongnu.org/archive/html/lwip-users/attachments/20150612/2a0ef8c3/attachment-0002.gif>

------------------------------

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users

End of lwip-users Digest, Vol 142, Issue 10
*******************************************




_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users


--
Kjetil Østerås

reply via email to

[Prev in Thread] Current Thread [Next in Thread]