Hi,
I opened this E2E for my customer, following up a previous E2E: https://e2e.ti.com/support/processors/f/791/p/901985/3335774, please help.
Regards, Eric
Below from customer:
Background: A simple http server is initialized using the following parameters:
static void ServiceReport( uint32_t Item, uint32_t Status, uint32_t Report, HANDLE h );
CI_SERVICE_HTTP http;
http.cisargs.pCbSrv = &ServiceReport;
CfgAddEntry( hCfg, CFGTAG_SERVICE, CFGITEM_SERVICE_HTTP, 0, sizeof(http), (uint8_t *)&http, 0 );
Webpage is established as follows:
efs_createfile("index.html", DEFAULT_SIZE, DEFAULT);
Contents of index.html include the following relevant lines:
<form method="post" action="loader_multi.cgi" enctype="multipart/form-data">
<input id="appfile" class="file" type="file" name="appfile">
<input id="sbt" value="Submit" type="submit">
Files smaller than 50 bytes are successful in calling back ServiceReport(), however, larger files are met with an abort. The limit appears to be related to the following in the NDK code:
http.h #define MAXREQUEST 512 /* Max bytes in request[] */
httpclie.c typedef struct _http_msg
char RequestedFile[MAXREQUEST+16];/
What configurations are required within the NDK to increase the accepted filesize on the POST operation as described in the webpage above? Simply increasing the bios heap and MAXREQUEST are met with limitations in the memory allocation itself. Additional settings appear to be required for reception of a file of size 32 megabytes.
Versions used
ti-processor-sdk-rtos-c665x-evm-06.01.00.08
ndk_3_61_01_01
After recompiling the NDK without optimization, and debugging my issue yesterday it became clear my initial take on the webserver (not accepting POST operations of files larger than 50 bytes) was not in httpClientProcess() where pMsg is allocated.
I find that the server does decode the URI POST request and dispatches our callback function. Once the callback calls PostFunction() inside of httpClientProcess we allocate successfully using the bulk mmBulkAlloc() function (based on the incoming length from the URI header.
I do find that the NDK_recv( htmlSock, buffer, ContentLength, MSG_WAITALL ) is returning -1, and SockRecv() does MSG_PEEK/SBRead() the first chunk (17570 bytes) of the incoming file but then blocks until timing out FdWaitEvent().
My debugging report regarding the timeout is preliminary, of course there is a chance my debugging is causing the timeout but what I have reported above is in line with not being able to receive over a trivial sized file.
Do you have any ideas on what might be disabled which would result in a background load of more file data? I have not looked at the interaction of the browser and target to see if there is more transfer of the file at the TCP level or if it may be a disabled interrupt or other setting causing this issue?
Thanks so much for following up.
