Re: [lwip-users] LwIP RAW - Simultaneous (full-duplex) communication
On 05.07.2018 16:18, Nenad Pekez wrote: [..] I don't think any calls to lwIP are made from an ISR. Yes, that looks good so far from what you wrote. I'm afraid I don't have any more ideas now. You'll have to try and debug it yourself. E.g. set a breakpoint at when the stats underflow happens. Simon ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LwIP RAW - Simultaneous (full-duplex) communication
And from which context are timers processed?
Xilinx timers are used. Each 250ms timer callback is called inside which
TcpFastTmrFlag (for 250ms) and/or TcpSlowTmrFlag (for 500ms) variables
are set to 1. In the main loop, there is this:
while (1) {
if (TcpFastTmrFlag) {
tcp_fasttmr();
TcpFastTmrFlag = 0;
}
if (TcpSlowTmrFlag) {
tcp_slowtmr();
TcpSlowTmrFlag = 0;
}
xemacif_input(echo_netif);
transfer_txperf_data();
}
Inside of timer callbacks, there is some SW workaround for HW bug of
Ethernet controller:
/* For providing an SW alternative for the SI #692601. Under heavy
* Rx traffic if at some point the Rx path becomes unresponsive, the
* following API call will ensures a SW reset of the Rx path. The
* API xemacpsif_resetrx_on_no_rxdata is called every 100 milliseconds.
* This ensures that if the above HW bug is hit, in the worst case,
* the Rx path cannot become unresponsive for more than 100
* milliseconds.
*/
#ifndef USE_SOFTETH_ON_ZYNQ
if (ResetRxCntr >= RESET_RX_CNTR_LIMIT) {
xemacpsif_resetrx_on_no_rxdata(echo_netif);
ResetRxCntr = 0;
}
#endif
I don't think any calls to lwIP are made from an ISR.
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LwIP RAW - Simultaneous (full-duplex) communication
Nenad Pekez wrote: > I took a look at this. This has been provided by Xilinx drivers already. > In their MAC receive handler they allocate memory for pbuf (call to > pbuf_realloc() actually) and enqueue it. In the main loop, I call Xilinx > function xemacif_input() which check if there is anything in the queue > and if there is netif->input() is called as described in the example. And from which context are timers processed? If you don't have an OS, you still have to ensure *not* to call into lwIP from an ISR. > > What I also noticed, when Zynq->PC side becomes active, in the TCP recv > callback I get p->tot_len much larger than 1446, and from time to time > there is also a print "Receive over run" from MAC error handler. With OOSEQ queueing enabled, you can get pbuf chains after some segments were lost and retransmissions have been received. This is normal, but if you encounter this unexpectedly, you could either just have buffer overruns (i.e. processor is not fast enough, or not enough memory available) or driver bugs. Simon ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LwIP RAW - Simultaneous (full-duplex) communication
Have you read this: http://www.nongnu.org/lwip/2_0_x/pitfalls.html I took a look at this. This has been provided by Xilinx drivers already. In their MAC receive handler they allocate memory for pbuf (call to pbuf_realloc() actually) and enqueue it. In the main loop, I call Xilinx function xemacif_input() which check if there is anything in the queue and if there is netif->input() is called as described in the example. What I also noticed, when Zynq->PC side becomes active, in the TCP recv callback I get p->tot_len much larger than 1446, and from time to time there is also a print "Receive over run" from MAC error handler. More I look at this, it seems as this is another problem in Xilinx drivers. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] esp32 and atsame
I have ATSAME MCU and ESP32. I used ready to use esp-idf examples to create tcpip client in eclipse with ESP32(standalone) and its working great. Now, I want to make a tcp_client using ESP32 module together with ATSAME53. ATSAME will be acting as the main MCU and I want to create a client using netconn APIs in lwip which will be in ATSAME. ESP32 uart pins connected to uart pins in ATSAME. I want ESP32 to be just bridge and give data from the router(internet) to ATSAME which will use lwip to process it and create a netconn client. (ESP-->ATSAME) I changed inside wlanif_input(struct netif *netif, void *buffer, u16_t len, void* eb) function in ESPlwip and send the buffer(packet) to ATSAME using uart(instead of tcpip_thread). I want packets to be processed in ATSAMElwip. When I received packets from ESP32 in ATSAME side, I called tcpip_input(p, _STACK_INTERFACE_0_desc) to send it to tcpip_thread to be processed. (ATSAME-->ESP) Coming packets from ATSAMElwip were sent to esp32 using netif->output= etharp_output fn which was modified to send using uart. Received pacets in ESP were sent to wifimodule using low_level_output function and sent using esp_wifi_internal_tx(wifi_if, q->payload, q->len); *But I have problems with creating netif. Shall I have two separate netifs(one in ESP and one in ATSAME), are two netif equally important? *Is it possible to realize whats in my mind? -- Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LwIP RAW - Simultaneous (full-duplex) communication
Nenad Pekez wrote: > > Have you checked the stats if you run out of memory somewhere? > I have checked them, and there is certainly something wrong. After some > time, stats for memory seem to overflow, at least that's my impression. > > At one point I have this: > MEM HEAP > avail: 6 > used: 13C40 > max: 14340 > err: 0 > > And next print (after 1 second): > MEM HEAP > avail: 6 > used: FFFC6480 > max: FFFC6A80 > err: 5 That seems like a threading issue. Have you read this: http://www.nongnu.org/lwip/2_0_x/pitfalls.html > > Actually, I'm too lazy to check out myself what the images contain. > But not too lazy to write out that many sentences. :) Not for every mail that leaves me with questions. For some though... > A picture is worth a thousand words. Well, certainly not this one! Simon ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LwIP RAW - Simultaneous (full-duplex) communication
Hi Simon, But it seems irrelevant? Yes, it's irrelevant. Have you checked the stats if you run out of memory somewhere? I have checked them, and there is certainly something wrong. After some time, stats for memory seem to overflow, at least that's my impression. At one point I have this: MEM HEAP avail: 6 used: 13C40 max: 14340 err: 0 And next print (after 1 second): MEM HEAP avail: 6 used: FFFC6480 max: FFFC6A80 err: 5 Sometimes, there is no error at all, just "used" and "max" seem to overflow or something. Also, I noticed that no matter which connection is made first, side Zynq->PC is the dominant one. I even tried not to call tcp_output() at all, but behavior is the same. When only PC->Zynq side is active, memory stats don't change at all ( used: 240, max: 440), even though high throughput is achieved (>900Mb/s). Only when Zynq->PC side is active memory consumption increases considerably. Actually, I'm too lazy to check out myself what the images contain. But not too lazy to write out that many sentences. :) A picture is worth a thousand words. I understand your point though :) Best regards and thanks for helping me out, Nenad ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
