Re: [lwip-users] invalid recvmbox in UDP recv() function

2017-05-11 Thread goldsi...@gmx.de
gussabina wrote: I'm using the Atmel port for ATSAM4E which comes from ASF (Atmel Software Framework) integrated with FreeRTOS. In that case, have you asked Atmel? Tell them the lwIP guys said it's not an lwIP bug ;-) If it is, I'll pay you a beer next time I see you :-) Simon

Re: [lwip-users] lwip 2.0.2 + freertos + ARM7

2017-05-11 Thread goldsi...@gmx.de
Werner Motz wrote: tcpip_callback(tcp_write(pcb,ucrecBuff,supersize,TCP_WRITE_FLAG_COPY),NULL); tcpip_callback(tcp_output(pcb), NULL); Ouch! tcpip_callback() takes a void pointer as first argument. You are *first* calling tcp_write with the parameters supplied, then passing the return

[lwip-users] How to find out if I can send out more UDP packets?

2017-05-11 Thread Xun Chen
Hi there, I use udp_sendto to output packets, if I space them in time to make sure the packets are sent, everything is fine, but if I call udp_sendto too frequently, I will run into error code -1, out of memory. Which lwip raw API can I call to find out if I have the resource before I

Re: [lwip-users] invalid recvmbox in UDP recv() function

2017-05-11 Thread goldsi...@gmx.de
gussabina wrote: Ok. But TCP sockets works fine... Honestly, that doesn't mean anything :-) There can well be other bugs and TCP just happens to work... Where do you have your lwIP port from? Who set up your interrupts and thread configuration? Actually, in below code I'm using select()

Re: [lwip-users] invalid recvmbox in UDP recv() function

2017-05-11 Thread gussabina
Ok. But TCP sockets works fine...Below is the code I'm using for TCP receive. Actually, in below code I'm using select() to wait for receive data...Now I'm confused...Should I use same approach for UDP? Thanks; Gus /int SocketRead(void *context, byte* buf, int buf_len, int timeout_ms) {

Re: [lwip-users] invalid recvmbox in UDP recv() function

2017-05-11 Thread goldsi...@gmx.de
gussabina wrote: Is the recvmbox supposed to be created by bind() function? It's supposed to be allocated in socket() (that function fails if mbox allocation fails) and removed in close() only. That's what makes me think your port's mbox alloc/dealloc/check functions don't work correctly...

Re: [lwip-users] PPPoS: Question regarding reconnect after connection lost

2017-05-11 Thread Sylvain Rochet
Hi Axel, On Thu, May 11, 2017 at 07:55:44PM +0800, Axel Lin wrote: > > Hi Sylvain, > > In practice, it usually has application code sending data while PPP > disconnect. I use netconn API + FreeRTOS, so I have a thread keep > sending data to internet. > > While PPP re-connect there is a

Re: [lwip-users] lwip 2.0.2 + freertos + ARM7

2017-05-11 Thread Dirk Ziegelmeier
The two APIs can coexist. regarding your code: Sorry, this code is so horribly wrong :-( I am sorry for being rude - you also need a LOT of education in C code. And, if your compiler compiles this, the warning settings are way too relaxed or you really should read and fix all compiler warnings.

Re: [lwip-users] invalid recvmbox in UDP recv() function

2017-05-11 Thread gussabina
Thanks, Simon. I will update and also try to debug it... Is the recvmbox supposed to be created by bind() function? According to the error message, this is not valid/existing when checked by the the recv() function.. Thanks Gus -- View this message in context:

Re: [lwip-users] invalid recvmbox in UDP recv() function

2017-05-11 Thread gussabina
Thank you, Simon. Where can I download v .2? Gus -- View this message in context: http://lwip.100.n7.nabble.com/invalid-recvmbox-in-UDP-recv-function-tp29602p29618.html Sent from the lwip-users mailing list archive at Nabble.com. ___ lwip-users

Re: [lwip-users] lwip 2.0.2 + freertos + ARM7

2017-05-11 Thread Werner Motz
I cannot because my webserver is already running with raw api. In my Send task I try now… tcpip_callback(tcp_write(pcb, ucrecBuff, supersize, TCP_WRITE_FLAG_COPY),NULL); tcpip_callback(tcp_output(pcb), NULL); but without success. After the first message sent the system crashed. I

Re: [lwip-users] PPPoS: Question regarding reconnect after connection lost

2017-05-11 Thread Axel Lin
2017-04-07 23:35 GMT+08:00 Axel Lin : > 2017-04-06 21:18 GMT+08:00 Sylvain Rochet : >> Hi Axel, >> >> On Thu, Apr 06, 2017 at 08:58:10PM +0800, Axel Lin wrote: >>> >>> Below is what I do to start PPP: >>> >>> Send "AT+CGDCONT=,," >>> Send "AT+CGAUTH=[,

Re: [lwip-users] lwip 2.0.2 + freertos + ARM7

2017-05-11 Thread Dirk Ziegelmeier
Use socket API and you can use threads without problems. Possible alternative: http://www.nongnu.org/lwip/2_0_x/group__tcp__raw.html#gafba47015098ed7ce523dcf7bdf70f7e5 Dirk ___ lwip-users mailing list lwip-users@nongnu.org

Re: [lwip-users] lwip 2.0.2 + freertos + ARM7

2017-05-11 Thread Werner Motz
I admit my understanding of threads is not the best. I understand the use of a callback API, but I don’t want to send data back in a callback only in order of receiving a TCP/IP message. I want to send independently from receiving. I am aware that there is only one tcpip thread which is

Re: [lwip-users] lwip 2.0.2 + freertos + ARM7

2017-05-11 Thread Dirk Ziegelmeier
Hello Werner, the following sentences are NOT meant in a harsh way, but as a good and polite advice to you: You really need to get educated in threading, locking and interrupt issues when you develop for a multithreaded system. Without understanding these, you will quite surely end up with a

Re: [lwip-users] invalid recvmbox in UDP recv() function

2017-05-11 Thread Simon Goldschmidt
gussabina wrote: > I'm using lwIP with FreeRTOS and I need to receive data via UDP. I'm testing > the following code which goes through until recv() function where it stucks > in the following line; > > LWIP_ERROR("netconn_accept: invalid recvmbox", > sys_mbox_valid(>recvmbox), return ERR_CONN;);

Re: [lwip-users] lwip 2.0.2 + freertos + ARM7

2017-05-11 Thread Werner Motz
Thank u for your answer. But what is the proper way to use tcp_write() and tcp_output()? Where can I use them? Would it be correct to do: LOCK_TCPIP_CORE(); tcp_write(); tcp_output(); UNLOCK_TCPIP_CORE(); If I do so, how can I ensure, that I can still receiving data? Don’t I block