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 <[email protected]> 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, [email protected] 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 >>> [email protected] >>> https://lists.nongnu.org/mailman/listinfo/lwip-users >>> >>> End of lwip-users Digest, Vol 142, Issue 10 >>> ******************************************* >>> >>> >> > > _______________________________________________ > lwip-users mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/lwip-users > -- Kjetil Østerås
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
