wifi timeout - E (1871053) wifi: TIMQ_NUL

[imtiaz]

Hi All,

I am sending a file (around 700kbytes) to the ESP32 setup as a TCP server from a PC client. Part way through receiving the file it starts to receive this error message E (1871053) wifi: TIMQ_NUL.

I cant find in the code where or why this is happening .

Can someone tell me why this is happening.

Thanks
imtiaz

[kolban]

What does your ESP32 C code look like? I am assuming you are using sockets APIs. Does one of those API fail? The message you are showing appears to be from an ESP_LOGE() message ... our first puzzle is to determine where that message is being issued. The text of the message isn't that meaningful. Searching the ESP-IDF repository (https://github.com/espressif/esp-idf) for "TIMQ_NUL" returns no hits ... so the first thing I am thinking is to see if the message isn't somehow issued by your application code.

[imtiaz]

Hi Kolban,

The message is not from my application code. The code basically sets up a listening port and retrieves all the data using netconn and netbufs.

However - If I set up the ESP32 as an AP and connect my PC to the ESP32 AP it all works fine. If I connect the ESP32 as a STA to my work network and my PC to my work network and then transfer the file - then the problem occurs.

Attached is the relevant part of the code . Its just a Proof of concept .

Cant seem to attach code says invalid extension. So Ill paste here.

Code: Select all

static void DowloadFile(struct netconn *conn) {
struct netbuf *inbuf;
char *buf;
uint16_t buflen;
uint32_t TotalLen = 0;
err_t err;
char Myreply[10];
size_t Address = MY_FLASH_START;
esp_err_t SpiErr = 0;
struct MD5Context WifiMD5;
MD5Init(&WifiMD5);

netconn_set_recvbufsize(conn,1024);
/* Read the data from the port, blocking if nothing yet there.
We assume the request (the part we care about) is in one netbuf */
TRACE_D("About to read from socket\n");
if( (SpiErr = spi_flash_erase_range(MY_FLASH_START,SPI_FLASH_SEC_SIZE * 200)) == ESP_OK) //819.200 k
{
TRACE_D("819 K of flash erased starting at %lu \n",(unsigned long)MY_FLASH_START);
}
else
{
TRACE_D("Fatal error with flash erase \n");
}


printf("Receiving File \n" );
/* http://lwip.wikia.com/wiki/Receiving_data_with_LWIP
* True that data buf returned is of varying lengths so it makes
* it tricky to always write same amount to flash - have to handle internally
*/

err = netconn_recv(conn, &inbuf); //block until receive first netbuf
if(err == ERR_OK)
{
netbuf_data(inbuf, (void**) &buf, &buflen);
MD5Update(&WifiMD5 , (unsigned char const*)buf , buflen);
if(/*(buflen % 4) == 0*/1) //new spi driver should handled unalligned
{
WriteBinFileToFlash(Address, (uint32_t*)buf, buflen);
}
else
{
TRACE_D("BUFFER NOT WRITTEN TO FLASH - BUFLEN NOT MULTIPLE OF 4 \n");

}
TotalLen+=buflen;
TRACE_D("received : %d \n",buflen);
if(inbuf)
{
netbuf_delete(inbuf);
}
netconn_set_recvtimeout ( conn, 1000);
while(1)
{
err = netconn_recv(conn, &inbuf);
if(err == ERR_OK)
{
netbuf_data(inbuf, (void**) &buf, &buflen);
MD5Update(&WifiMD5 , (unsigned char const*)buf , buflen);
if(/*(buflen % 4) == 0*/1)
{
WriteBinFileToFlash(Address+TotalLen, (uint32_t*)buf, buflen);
}
else
{
TRACE_D("BUFFER NOT WRITTEN TO FLASH - BUFLEN NOT MULTIPLE OF 4 \n");
}
TotalLen+=buflen;
TRACE_D("received : %d , Total : %lu \n",buflen,(unsigned long)TotalLen);
if(inbuf)
{
netbuf_delete(inbuf);
}
}
else if(err != ERR_OK)
{
TRACE_D("netconn returned code %d \n",err);
break;
}

}
}
else
{
TRACE_D("File Downlaod recieve err %d : \n",err);

}
MD5Final(MyDigest , &WifiMD5);
TRACE_D("Total Data Received : %lu \n",(unsigned long)TotalLen );
TRACE_D (Myreply,"%lu",(unsigned long)TotalLen);
printf("Total Data Received : %lu \n",(unsigned long)TotalLen );

for(uint8_t i=0;i<16;i++)
{
printf("WIFI MD5 %x \n",MyDigest);
}


/* Close the connection (server closes in HTTP) */
// netconn_set_recvtimeout ( conn, 0);
netconn_close(conn);

/* Delete the buffer (netconn_recv gives us ownership,
so we have to make sure to deallocate the buffer) */
if(inbuf)
{
netbuf_delete(inbuf);
}

//calculate crc from flash
VerifyBinFileFromFlash(MY_FLASH_START , TotalLen , GetFileHash());
}

/************************************************************
@Func:
@Inputs:
@Outputs:
@Comments: FIXME - only works on first connection - n subsequent connection client fails to connect
*************************************************************/
/** The main function, never returns! */
static void socket_netconn_thread(void *arg) {
struct netconn *conn, *newconn;
err_t err;

uint16_t PortNumber = *((uint16_t*)arg);

/* Create a new TCP connection handle */
conn = netconn_new(NETCONN_TCP);
LWIP_ERROR("invalid conn", (conn != NULL), return;);

/* Bind to specified port with default IP address */
netconn_bind(conn, NULL, PortNumber);

/* Put the connection into LISTEN state */
netconn_listen(conn);
//netconn_set_recvtimeout ( conn, 10000);
TRACE_D("listening on %d for 10 seconds \n", PortNumber); //FIXME - currently permanently listening -
do {
err = netconn_accept(conn, &newconn);

if (err == ERR_OK)
{
TRACE_D("Connection accepted\n");
DowloadFile(newconn);
netconn_delete(newconn);
}
else
{
TRACE_D("Connection err %d : \n",err);
}

} while (err == ERR_OK);


netconn_close(conn);
netconn_delete(conn);

TRACE_D("deleting firmware upload task \n");
vTaskDelete(NULL);
}

/************************************************************
@Func:
@Inputs:
@Outputs:
@Comments:
*************************************************************/

void syrp_download_bin(uint16_t ListeningPort)
{
FirmwareDownloadPort = ListeningPort;
//spawn a temporary thread to recieve bin file

xTaskCreate(&socket_netconn_thread, "socket_netconn_thread", 2048,
&FirmwareDownloadPort, 5, NULL);

}

Code: Select all

[kolban]

If I may suggest, edit your last post and surround it with the "code" tags so that it formats as code. As it stands it is too much to try and decode. In my experience, I haven't had the opportunity to play with the lwip netconn API. I'm currently sticking to the higher level "sockets" API. I'd be curious to hear what benefits (if any) one can get from using netconn vs sockets?

But back to the problem ... I understand diagnostic messages are being issued when your application runs and we can't (yet) seem to find any meaning nor location to where those messages come from. What about your application ... do the messages originate within any particular API call being made by the app? What happens to the app? Does it crash or something else?

If it were me and I didn't know the answer to these, I'd start instrumenting the application with diagnostics or finding a debugger to step through the code. Since it is appearing that we can't understand the message and don't yet know where the messages is being originated from ... the next thing we would want to do is gather new clues ... such as what is being executed when the message appears.

[WiFive]

Since it is appearing that we can't understand the message and don't yet know where the messages is being originated from ... the next thing we would want to do is gather new clues ... such as what is being executed when the message appears.

Grep says it is from libcore.a of WiFi lib

[kolban]

Thank you sir. Since it appears that is one of the Espressif proprietary libraries, there doesn't appear much else we can from an externals perspective. Hopefully someone from Espressif support can shed some light on what that error message may mean with some knowledge of why it is raised internally.

[imtiaz]

Hi Kolban,

Im not sure what the advantages and or differences are of using the netconn api over the socket one is as I havent used the socket API yet.

Possibly someone else can shed some light on this - pros and cons of Netconn Vs Sockets?

If you have any simple examples you can share I can give it a go. My current application is ESP32 as AP , listening on specified port. Client connects and sends raw data.

Thanks
Imtiaz

[imtiaz]

Quick search reveals some pretty useful information:

http://lwip.wikia.com/wiki/Application_API_layers

Some more facts on the APIs to help you to decide which one to use in your application:

netconn- and raw-API are lwIP-only: code written in these APIs isn't portable to be re-used with other stacks
the socket API in contrast is targeted at portability with other posix OSes/stacks at the cost of lower throughput
socket- and netconn-API are sequential APIs that require threading (one thread for the application that uses the API, one thread for the stack to handle timers, incoming packets, etc.)
the raw API uses a callback mechanism (e.g. your application's callback is called when new data arrives). If you are used to program in a sequential way, this may be harder to implement.
the raw API gives the best performance since it does not require thread-changes
raw- and netconn-API support zero-copy both for TX and RX (although DMA-enabled MACs can prevent zero-copy-RX)