I’m sorry to answer so late, I didn’t recognise your post as a FreeRTOS+TCP problem because I saw several times MQTT.
I assume there is some sort of buffer queue somewhere that
is scanned for events to be processed but i can’t find it
The TCP/IP stack is run from a task called prvIPTask(). It receives messages from a queue called xNetworkEventQueue. It is recommended to give the IP-task a priority that is higher than the tasks that make use of the +TCP library. So when an API returns, the IP-stack will have handled the message already.
But you solved your problem, great! You’re not the first person running out of heap space.
I hoped that these things can be detected earlier since PR #2164: “FreeRTOS+TCP : print resource statistics routine”.
i assumed what wasn’t stack was heap
Often that is a good assumption. But for ease of use, most demo applications use heap_4.c, which has a fixed size determined at compile-time.
I always like to use heap_5.c, which allows a dynamic configuration at runtime. Once running you know where the (initial) stack ends, and you also know the size of data/bss.
Here is a description: FreeRTOS +TCP on SAME70 - #7 by htibosch
About FreeRTOS_sendto() and FreeRTOS_send(): in FreeRTOS+TCP the former is used for UDP sockets, and the latter (send()) is only used for TCP.
There are two independent ranges of port numbers: one for UDP and one for TCP. Normally there is no relation between these ports.
Under TCP, 80 and 8080 are typically HTTP port numbers. Under UDP they may have a totally different function.
The port numbers 0 to 1023 are reserved for the system, other port numbers are free to use, although there will be quite a few reserved numbers as well. See also socketAUTO_PORT_ALLOCATION_START_NUMBER which defaults to 1024.