DarkElvenAngel
Posts: 2910
Joined: Tue Mar 20, 2018 9:53 pm

Pico W generates error after using TCP for a while

Wed Dec 06, 2023 7:58 pm

Hello everyone,

Not sure why this is happening but after some time my Pico W will panic with this error

Code: Select all

*** PANIC ***

pcb->snd_queuelen >= pbuf_clen(next->p)
I'm using the Pico W in pico_cyw43_arch_lwip_threadsafe_background mode. Am I sending data to quickly or is there something I need to do to flush the queue? Should I be buffer my transmits? I've not really done much with TCP so it's very likely I'm doing something wrong.

Any thought or suggestions?

I would post code but the project is massive. The TCP stuff is basically the TCP Demo with tcp_send and tcp_output calls when my project wants to send data. And the data could be one char or strings.

ronter
Posts: 485
Joined: Thu Nov 12, 2015 3:11 am

Re: Pico W generates error after using TCP for a while

Wed Dec 06, 2023 10:30 pm

I didn't hit any panic, but when my Telnet server was sending verbose logging information over TCP, it would sometimes lose chunks.

I fixed this by monitoring the amount of outstanding pending bytes, and stalling the send function until it caught up.

Code: Select all

// define the callback for acknowledged data
tcp_sent(telnetConnection.ptcp_pcb, tcpSentCallback);
...
...
// when ack is received this will decrease the outstanding byte count
static err_t tcpSentCallback (void *arg, struct tcp_pcb *tpcb, u16_t len)
{
	if ( telnetConnection.pendingSent >= len ) telnetConnection.pendingSent -= len;
	else telnetConnection.pendingSent = 0;

#if defined (__USB_LOG)
	printf ("lwIP: tcpSentCallback, len=%u, pend=%lu\r\n", len, telnetConnection.pendingSent);
#endif

	return ERR_OK;
}
	
...
...
// generic function to send TCP data for Telnet server
static bool telnetSend ( uint8_t *_pMsgOut, uint16_t _size)
{
	err_t				_err;
    uint8_t 			_count = 0;
	uint16_t			_avail = tcp_sndbuf(telnetConnection.ptcp_pcb);

	// if too much is already pending, wait for the callback to whittle this to 0
	if ( (telnetConnection.pendingSent + _size) > _avail )
	{
#if defined (__USB_LOG)
		printf("telnet: TCP wait for pending %lu of %u\r\n",  telnetConnection.pendingSent, _avail );
#endif
		while ( telnetConnection.pendingSent > 0 )
		{
			vTaskDelay( pdMS_TO_TICKS(100));
			if ( ++_count >= 30 ) 	// 3 seconds ?
			{
#if defined (__USB_LOG)
	            printf("telnetSend() timeout wait for pending %lu bytes\r\n", telnetConnection.pendingSent );
#endif
				return false;
			}
		}
	}

	cyw43_arch_lwip_begin();
	if ( (_err = tcp_write(telnetConnection.ptcp_pcb, _pMsgOut, _size, TCP_WRITE_FLAG_COPY ) ) == ERR_OK   )
	{
		telnetConnection.pendingSent += _size;
		_err = tcp_output(telnetConnection.ptcp_pcb);
	}
	cyw43_arch_lwip_end();

#if defined (__USB_LOG)
	printf("telnet: TCP write %u bytes, err:%d\r\n", _size, _err );
#endif

	return ( _err == ERR_OK );
}

I don't know if this is necessary, or if it helps your situation - just another "what if I try this" that seemed to work. ;)

BTW, It's using FreeRTOS, + threadsafe_background mode, so you wouldn't use vTaskDelay();

DarkElvenAngel
Posts: 2910
Joined: Tue Mar 20, 2018 9:53 pm

Re: Pico W generates error after using TCP for a while

Thu Dec 07, 2023 12:19 am

Okay so now I've lost my reply type this again.

So I added this while loop in the sender code

Code: Select all

    err_t err = tcp_write(telnet_pcb,buffer,length,TCP_WRITE_FLAG_COPY);
    while (telnet_pcb->snd_queuelen > 100) sleep_us(100);
Tried with 0 but that just stalled and it was game over so I guessed at 100 might be too big. Thought It was all sorted ran my tests and then I thought maybe 10 loops isn't enough so I went to write a new test and then ...

Code: Select all

*** PANIC ***                                                                   
                                                                                
tcp_receive: valid queue length                                                 
                                   
Not sure this one isn't as helpful as the last.

And a new one when I did the big test 1 to 100000

Code: Select all

*** PANIC ***                                                                   
                                                                                
unsent_oversize mismatch (pcb->unse
It's cut off so I'm not sure what it should be
Last edited by DarkElvenAngel on Thu Dec 07, 2023 12:49 am, edited 1 time in total.

ronter
Posts: 485
Joined: Thu Nov 12, 2015 3:11 am

Re: Pico W generates error after using TCP for a while

Thu Dec 07, 2023 12:48 am

You still need the tcp_output() call after tcp_write(); you didn't remove it, did you?

I'm really not sure what is the proper field in the tcp_pcb we should be looking at. I used snd_buf because it claims to be "available buffer space for sending", so I figured I should stall any write that would exceed that. I didn't try monitoring snd_queuelen; it says "number of pbufs". :?:

DarkElvenAngel
Posts: 2910
Joined: Tue Mar 20, 2018 9:53 pm

Re: Pico W generates error after using TCP for a while

Thu Dec 07, 2023 12:52 am

ronter wrote:
Thu Dec 07, 2023 12:48 am
You still need the tcp_output() call after tcp_write(); you didn't remove it, did you?

I'm really not sure what is the proper field in the tcp_pcb we should be looking at. I used snd_buf because it claims to be "available buffer space for sending", so I figured I should stall any write that would exceed that. I didn't try monitoring snd_queuelen; it says "number of pbufs". :?:
No tcp_output() call happens after the while loop. I know I need that without it the transmits are dependent on other traffic.

I change my code again this might be better now.

Code: Select all


    while (telnet_pcb->snd_buf < length) sleep_us(100);
    err_t err = tcp_write(telnet_pcb,buffer,length,TCP_WRITE_FLAG_COPY);
    tcp_output(telnet_pcb);

I just had a new error

Code: Select all

 *** PANIC ***                                                                   
                                                                                
unsent_oversize mismatch (pcb->unsent is NULL)
I got the whole message.

ronter
Posts: 485
Joined: Thu Nov 12, 2015 3:11 am

Re: Pico W generates error after using TCP for a while

Thu Dec 07, 2023 1:54 am

The code looks good, but the LWIP_ASSERT looks like the pcb pointer has be de-referenced, or corrupted. You're using the new pcb pointer provided by the accept callback, right?

DarkElvenAngel
Posts: 2910
Joined: Tue Mar 20, 2018 9:53 pm

Re: Pico W generates error after using TCP for a while

Thu Dec 07, 2023 2:39 am

ronter wrote: The code looks good, but the LWIP_ASSERT looks like the pcb pointer has be de-referenced, or corrupted. You're using the new pcb pointer provided by the accept callback, right?
Yes I am it's basically the TCP server example code with my stuff crammed in for good measure.

Code: Select all

static err_t tcp_server_accept(void *arg, struct tcp_pcb *client_pcb, err_t err) {
    TCP_SERVER_T *state = (TCP_SERVER_T*)arg;
    if (err != ERR_OK || client_pcb == NULL) {
        DEBUG_printf("Failure in accept\n");
        tcp_server_result(arg, err);
        return ERR_VAL;
    }
    DEBUG_printf("Client connected\n");

    telnet_pcb = client_pcb;
    state->client_pcb = client_pcb;
    tcp_arg(client_pcb, state);
    tcp_sent(client_pcb, tcp_server_sent);
    tcp_recv(client_pcb, tcp_server_recv);
    tcp_poll(client_pcb, tcp_server_poll, POLL_TIME_S * 2);
    tcp_err(client_pcb, tcp_server_err);

    if (state->auto_flip)
    {
        errno = 0;
        fclose(stdin);
        if (errno) perror("fclose stdin");
        stdin = fopen("/dev/ttytelnet","r");
        if (errno) perror("fopen stdin");
        fclose(stdout);
        if (errno) perror("fopen stdout");
        stdout = fopen("/dev/ttytelnet","w");
        if (errno) perror("fopen stdout");
    }
    return tcp_server_send_data(arg, state->client_pcb);
}
I've done some tweaking, and turned up the power.

Code: Select all

int WiFi_init(){
    cyw43_arch_gpio_put(1, 1);
    cyw43_arch_enable_sta_mode();
    printf("Connecting to Wi-Fi...\n");
    if (cyw43_arch_wifi_connect_timeout_ms(WIFI_SSID, WIFI_PASSWORD, CYW43_AUTH_WPA2_AES_PSK, 30000)) {
        printf("failed to connect.\n");
        return 1;
    } 
    cyw43_wifi_pm(&cyw43_state, CYW43_PERFORMANCE_PM & ~0xf);
    printf("Connected {%s}.\n", ip4addr_ntoa(netif_ip4_addr(netif_list)));
    return 0;
}
This has worked to stop the errors and I was able to run my test without an assert

Code: Select all

do 
 print("\x1b[H\x1b[2J")
 for I= 1, 10000 do
  io.write(string.format("%04X ", I)) 
 end
 print("test complete")
end
There are some glitches in the output I'm driving it very hard

Code: Select all

--- SNIP ---
0D81 0D82 0D83 0D84 0D85 0D86 0D87 0D88 0D89 0D8A 0D8B 0D8C 0D8D 0D8E 0D8F 0D90 0D91 0D92 0D93 0D94 0D95 0D96 0D97 0D98 0D99  0E67 0E68 0E69 0E6A 0E6B 0E6C 0E6D 0E6E 0E6F 0E70 0E71 0E72 0E73 0E74 0E75 0E76 0E77 0E78 0E79 0E7A 0E7B 0E7C 0E7D 0E7E 0E7F 0E80 0E81 0E82 0E83 0E84 0E85 0E86 0E87 0E88 0E89 0E8A 0E8B 0E8C 0E8D
--- SNIP ---
1256 1257 1258 1259 125A 125B 125C 125D 125E 125F 1260 1261 1262 1263 1264 1265 12663 1334 1335 1336 1337 1338 1339 133A 133B 133C 133D 133E 133F 1340 1341 1342 1343
--- SNIP ---
There are more examples of missing number but that gets the point across.

And then I got confident and this happens while entering a new test code into REPL

Code: Select all

*** PANIC ***

pcb->snd_queuelen >= pbuf_clen(next->p)
I'm also noticing the pico is warm I'm going to turn the temperate sensor on and see if I can get a reading. It's not hot just warm.

DarkElvenAngel
Posts: 2910
Joined: Tue Mar 20, 2018 9:53 pm

Re: Pico W generates error after using TCP for a while

Thu Dec 07, 2023 7:47 pm

Just thinking out loud here. Right now the output written to telnet TCP is unbuffered. I just have that wait if the buffer to full for the next message. I could buffer all the data and send larger packets. Problem is how to I make sure the send buffer is empty if no more data is being sent? I have a FIFO on the input but it's not really suited for output since that's more than one byte at a time.

trejan
Posts: 7107
Joined: Tue Jul 02, 2019 2:28 pm

Re: Pico W generates error after using TCP for a while

Thu Dec 07, 2023 7:59 pm

DarkElvenAngel wrote:
Thu Dec 07, 2023 7:47 pm
Just thinking out loud here. Right now the output written to telnet TCP is unbuffered. I just have that wait if the buffer to full for the next message. I could buffer all the data and send larger packets. Problem is how to I make sure the send buffer is empty if no more data is being sent? I have a FIFO on the input but it's not really suited for output since that's more than one byte at a time.
I've not noticed any of these issues with TCP. It sounds more like something in your code is going out of bounds and overwriting LWIP state which is making it blow up. Fix that before coming up with elaborate workarounds to mask the problem.

DarkElvenAngel
Posts: 2910
Joined: Tue Mar 20, 2018 9:53 pm

Re: Pico W generates error after using TCP for a while

Fri Dec 08, 2023 3:39 am

trejan wrote:
Thu Dec 07, 2023 7:59 pm
DarkElvenAngel wrote:
Thu Dec 07, 2023 7:47 pm
Just thinking out loud here. Right now the output written to telnet TCP is unbuffered. I just have that wait if the buffer to full for the next message. I could buffer all the data and send larger packets. Problem is how to I make sure the send buffer is empty if no more data is being sent? I have a FIFO on the input but it's not really suited for output since that's more than one byte at a time.
I've not noticed any of these issues with TCP. It sounds more like something in your code is going out of bounds and overwriting LWIP state which is making it blow up. Fix that before coming up with elaborate workarounds to mask the problem.
See this is why I posted about this I hadn't considered that something else is doing something to corrupt the stacks and memory. I'm not sure how to find out where that would be I will have to go and check if everything is using the same memory manager the stock pico malloc and friends isn't good in my use case.

hippy
Posts: 15879
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Pico W generates error after using TCP for a while

Fri Dec 08, 2023 12:35 pm

DarkElvenAngel wrote:
Fri Dec 08, 2023 3:39 am
I will have to go and check if everything is using the same memory manager the stock pico malloc and friends isn't good in my use case.
It seems to me you need to implement some mechanism to stop code building if it is using memory management which is incompatible with your own. Maybe something which makes the system 'malloc' and friends unavailable or non-linkable, or at least identify cases when they have been included in a build - A simple 'grep' for "malloc" in the '.dis' file may be enough.

Or drop use of your own memory management and just use what is provided, what other things will be using.

DarkElvenAngel
Posts: 2910
Joined: Tue Mar 20, 2018 9:53 pm

Re: Pico W generates error after using TCP for a while

Fri Dec 08, 2023 3:11 pm

hippy wrote:
DarkElvenAngel wrote:
Fri Dec 08, 2023 3:39 am
I will have to go and check if everything is using the same memory manager the stock pico malloc and friends isn't good in my use case.
It seems to me you need to implement some mechanism to stop code building if it is using memory management which is incompatible with your own. Maybe something which makes the system 'malloc' and friends unavailable or non-linkable, or at least identify cases when they have been included in a build - A simple 'grep' for "malloc" in the '.dis' file may be enough.

Or drop use of your own memory management and just use what is provided, what other things will be using.

Good suggestion. I'm using a memory pool manager umm_malloc, I previously was using my own implementation of memory pool manager but it fragmented to quickly. The problem is memory fragmentation that's reason to use a memory pool over the stock system, it's easy to reset memory when it's time to start something new. Since I'm using Lua the garbage collection can fragment memory quite quickly.

I could be that all libraries are not using the memory pool. This gives me a good direction to look in, since I haven't used the memory pool with the WiFi libraries before.

I should remove this -DPICO_MALLOC_PANIC=0 from my CMakeLists.txt then I'll know for sure Pico-SDK mallocs are happening.

Is it possible to replace the default malloc's at the SDK level? maybe I need a new thread for that.

hippy
Posts: 15879
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Pico W generates error after using TCP for a while

Fri Dec 08, 2023 5:41 pm

DarkElvenAngel wrote:
Fri Dec 08, 2023 3:11 pm
Is it possible to replace the default malloc's at the SDK level? maybe I need a new thread for that.
I believe what you need to adjust or exclude is ...

.../pico-sdk/src/rp2_common/pico_malloc/pico_malloc.c


No idea how to so a new thread would seem to be in order.

DarkElvenAngel
Posts: 2910
Joined: Tue Mar 20, 2018 9:53 pm

Re: Pico W generates error after using TCP for a while

Sat Dec 09, 2023 12:57 am

Memory pool is WIP I tried with it and I ended up with the same issues so I'm doing a debug build where I can see all the memory requests.

The memory pool would be useful if I could work out how to just give it the heap. but not there yet.

I'm going to run my tests again and see what happens leading up to this crash.

I don't think this is a memory issue at all I'm running a 1,000,000 loop through the telnet socket results were no issues on run one run two I could see obvious signs of drift in the output. the only difference now is I'm using the pico malloc debug thus adding delay to each cycle of the loop.

It must be too much data too fast down the pipe. the debug is only spitting out the realloc messages that Lua is generating for garbage cleanup.

I this the wrong conclusion?

The PANIC message is incomplete

Code: Select all

*** PANIC ***                                                                   
                                                                                
unsent_oversize mismatch (pcb->un

trejan
Posts: 7107
Joined: Tue Jul 02, 2019 2:28 pm

Re: Pico W generates error after using TCP for a while

Sat Dec 09, 2023 1:20 am

DarkElvenAngel wrote:
Sat Dec 09, 2023 12:57 am
I don't think this is a memory issue at all I'm running a 1,000,000 loop through the telnet socket results were no issues on run one run two I could see obvious signs of drift in the output. the only difference now is I'm using the pico malloc debug thus adding delay to each cycle of the loop.
Welcome to the nightmare of Heisenbugs. Enabling the debug code will move things around in memory so it may be overwriting something else less obvious now. Sometimes just rearranging code is enough to change the behaviour.

If you've got a Picoprobe then a watchpoint should show what is accessing that memory.

Is telnet_pcb on the stack or heap?

hippy
Posts: 15879
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Pico W generates error after using TCP for a while

Sat Dec 09, 2023 12:35 pm

DarkElvenAngel wrote:
Sat Dec 09, 2023 12:57 am
The PANIC message is incomplete
In my experience because the Pico shuts itself down before what's being reported has been sent.

Maybe using UART for monitoring debug and panic reports would help ? Never looked into that myself.

DarkElvenAngel
Posts: 2910
Joined: Tue Mar 20, 2018 9:53 pm

Re: Pico W generates error after using TCP for a while

Sat Dec 09, 2023 3:54 pm

does the WiFi library use heap memory to work? I don't see and messages about it trying to grab memory.

It might be I'm looking at stack overflow in to heap memory however I'm not sure how to check for that.

ronter
Posts: 485
Joined: Thu Nov 12, 2015 3:11 am

Re: Pico W generates error after using TCP for a while

Sat Dec 09, 2023 4:37 pm

LWIP uses its own memory allocation. The size of the MEM HEAP is determined by the option in lwipopts.h...

I use 8K. I believe the pbufs are allocated from this heap.

Code: Select all

#define MEM_SIZE                    8192
During a Telnet session, when I beat it up by entering a command to
dump 32 pages (256 byte ea) of flash

Code: Select all

flash dump 0 32

  00000000:
   0000: 00 b5  32  4b  21  20  58  60  98  68  02  21  88  43  98  60 ..2K! X`.h.!.C.`
   0010: d8 60  18  61  58  61  2e  4b  00  21  99  60  02  21  59  61 .`.aXa.K.!.`.!Ya
   0020: 01 21  f0  22  99  50  2b  49  19  60  01  21  99  60  35  20 .!.".P+I.`.!.`5 
   0030: 00 f0  44  f8  02  22  90  42  14  d0  06  21  19  66  00  f0 ..D..".B...!.f..
   0040: 34 f8  19  6e  01  21  19  66  00  20  18  66  1a  66  00  f0 4..n.!.f. .f.f..
   0050: 2c f8  19  6e  19  6e  19  6e  05  20  00  f0  2f  f8  01  21 ,..n.n.n. ../..!
   0060: 08 42  f9  d1  00  21  99  60  1b  49  19  60  00  21  59  60 .B...!.`.I.`.!Y`
   0070: 1a 49  1b  48  01  60  01  21  99  60  eb  21  19  66  a0  21 .I.H.`.!.`.!.f.!
   0080: 19 66  00  f0  12  f8  00  21  99  60  16  49  14  48  01  60 .f.....!.`.I.H.`
   0090: 01 21  99  60  01  bc  00  28  00  d0  00  47  12  48  13  49 .!.`...(...G.H.I
   00A0: 08 60  03  c8  80  f3  08  88  08  47  03  b5  99  6a  04  20 .`.......G...j. 
   00B0: 01 42  fb  d0  01  20  01  42  f8  d1  03  bd  02  b5  18  66 .B... .B.......f
   00C0: 18 66  ff  f7  f2  ff  18  6e  18  6e  02  bd  00  00  02  40 .f.....n.n.....@
   00D0: 00 00  00  18  00  00  07  00  00  03  5f  00  21  22  00  00 .........._.!"..
   00E0: f4 00  00  18  22  20  00  a0  00  01  00  10  08  ed  00  e0 ...." ..........
   00F0: 00 00  00  00  00  00  00  00  00  00  00  00  74  b2  4e  7a ............t.Nz
   
.....etc.....
Not a single character is missed over the entire output. When it's done, the next lwIP status report shows...

Code: Select all

MEM HEAP
	avail: 8192
	used: 0
	max: 6160
	err: 0
So, it gets as high as ~6K used, then returns to 0 when the session goes quiet again.

I don't believe that lwIP will panic if it runs out of its heap, just probably returns an error and carries on.

**edit: I just tried the same test after setting the mem_size to 4096. The client side disconnected, but the picoW didn't crash.

DarkElvenAngel
Posts: 2910
Joined: Tue Mar 20, 2018 9:53 pm

Re: Pico W generates error after using TCP for a while

Sat Dec 09, 2023 8:17 pm

I've upped the limit and will try again I also noticed MEM_LIBC_MALLOC is set to 0

Code: Select all

// MEM_LIBC_MALLOC is incompatible with non polling versions
#define MEM_LIBC_MALLOC             0
#define MEM_ALIGNMENT               4
#define MEM_SIZE                    8192 // 4000

Code: Select all

*** PANIC ***                                                                   
                                                                                
tcp_receive: valid queue length  
Blast! same thing.

EDIT:: I've change the Heap memory and since I can see what addresses of memory are in use. I'm no where near maxing out the heap memory.

The heap is running around 0x2001576C with the stack limit is 0x20040000 the heap limit is 0x200106f0 I use the heap limit to set the heap start address. these would need to be one heck of a stack overflow

What to do next.

DarkElvenAngel
Posts: 2910
Joined: Tue Mar 20, 2018 9:53 pm

Re: Pico W generates error after using TCP for a while

Sat Dec 09, 2023 9:49 pm

I have a thought are you guys using the pico_cyw43_arch_lwip_threadsafe_background ?? Maybe there is a race condition in the background driver or in my code.

Is there an example of how you've implemented telnet?

ronter
Posts: 485
Joined: Thu Nov 12, 2015 3:11 am

Re: Pico W generates error after using TCP for a while

Sun Dec 10, 2023 4:33 pm

DarkElvenAngel wrote:
Sat Dec 09, 2023 9:49 pm
I have a thought are you guys using the pico_cyw43_arch_lwip_threadsafe_background ?? Maybe there is a race condition in the background driver or in my code.

Is there an example of how you've implemented telnet?
I am using pico_cyw43_arch_lwip_threadsafe_background within a FreeRTOS environment. I think it's pretty safe to assume that lwIP is mature and stable enough to not be the cause of your problems. If you follow the simple rules for callbacks, there should be no race conditions. More likely is that the control structures being used by lwIP are being overwritten, or the pointers to them corrupted. The type of lwIP asserts you're getting look like that's what is happening.

lwIP is pretty resilient; it asserts when there's no hope of recovery. I've purposely made it run out of its pbuf memory heap; what happened was the client side aborts the connection, but the Telnet server recovers. The ERR_ABRT error is passed in the tcp_err callback, and the code reacts to that by cleaning up, and going back to listen.

Have you used the SWD debugger? If I were faced with an issue like this, I would inspect the lwIP structures and see if they make sense, or if they have obviously been clobbered. Otherwise, you can go line-by-line through the code making sure that there's no pointers resident on a stack from a function that has already returned, or buffers that could overflow, stuff like that, etc.

I don't know exactly where there's any Telnet examples using lwIP raw; I never looked. My own code would not be helpful to anyone else because it's FreeRTOS centric and passes queue messages between the callbacks and mainline.

DarkElvenAngel
Posts: 2910
Joined: Tue Mar 20, 2018 9:53 pm

Re: Pico W generates error after using TCP for a while

Mon Dec 11, 2023 2:58 am

I haven't got any header pins for my Pico W so I can't use the debugger. What I have done is turn on the poison checking for the heap although not exactly helpful in finding out what is over writing memory I can see that something is and it looks like it's very early in start up.

The only thing that early is a library I haven't used in the past so I think I know where to concentrate my efforts.
There is no way to be sure at this point I need to get headers.

DarkElvenAngel
Posts: 2910
Joined: Tue Mar 20, 2018 9:53 pm

Re: Pico W generates error after using TCP for a while

Mon Dec 11, 2023 7:17 pm

I had a thought (dangerous maybe...) in over to determine if there was memory issues I did a little check

Code: Select all

*** PANIC ***

STACK OVERFLOW  [-7576 bytes]
However did I do this?

Code: Select all

static void stackoverflow_check() {
    register char *sp asm("sp");
    int r = &__StackLimit - sp;
    if (r < 0) panic ("STACK OVERFLOW  [%d bytes]", r);
}
This function will be called during any heap memory requests operation since I've tied it into the check_alloc function this is defined in the Pico malloc Library I've written my own version of this library and add stack checking.

I was thinking to expand the stack without messing with the linker script.

DarkElvenAngel
Posts: 2910
Joined: Tue Mar 20, 2018 9:53 pm

Re: Pico W generates error after using TCP for a while

Mon Dec 11, 2023 10:12 pm

Okay having sorted out the stack overflow issue I'm now getting this panic to trigger and I'm not sure what to do if tcp_write fails

Code: Select all

err_t err = tcp_write(telnet_pcb,buffer,length,TCP_WRITE_FLAG_COPY);
    if (err != ERR_OK) {
        panic("Fail to write data");
    }    
Do you wait and try again the example code just gives up and ends.

Now the only error I keep seeing is this

Code: Select all

 *** PANIC ***                                                                                                                        
                                                                                                                                     
tcp_receive: valid queue length 

ronter
Posts: 485
Joined: Thu Nov 12, 2015 3:11 am

Re: Pico W generates error after using TCP for a while

Tue Dec 12, 2023 2:59 am

DarkElvenAngel wrote:
Mon Dec 11, 2023 10:12 pm
Okay having sorted out the stack overflow issue I'm now getting this panic to trigger and I'm not sure what to do if tcp_write fails

Code: Select all

err_t err = tcp_write(telnet_pcb,buffer,length,TCP_WRITE_FLAG_COPY);
    if (err != ERR_OK) {
        panic("Fail to write data");
    }    
Do you wait and try again the example code just gives up and ends.

Now the only error I keep seeing is this

Code: Select all

 *** PANIC ***                                                                                                                        
                                                                                                                                     
tcp_receive: valid queue length 

Maybe print out what the err code is. All we know is it's not ERR_OK.

Return to “SDK”