I'm using MQX 3.8 and Freescale K60 for a DataLogger application that uploads periodically files to a FTP server.
There is a specific task that calls FTP client functions:
exactly like in the ftpc_cmd shell commands.
The application works fine for days, and weeks and months, if the server answer correctly to all the requests.
But sometimes a wrong/missed answer or a connection lost or a link error leaves the task in the blocked state indefinitely.
- There are no stack or memory overflows.
- RTCS is still running correctly (ping/web server)
- MFS file system is correctly accessible
- sometimes task is blocked in the FTP_open function, before I could get the socket handler
- RTCS is RTCS_MINIMUM_FOOTPRINT except for
_RTCSPCB_init = 6; // 4;
_RTCSPCB_grow = 2;
_RTCSPCB_max = 20;
_RTCS_msgpool_init = 6; // 4;
_RTCS_msgpool_grow = 2;
_RTCS_msgpool_max = 20;
_RTCS_socket_part_init = 6; // 4;
_RTCS_socket_part_grow = 2;
_RTCS_socket_part_max = 20;
The only work around I found is to restart the task:
- blocking socket is "shutdown"
- memory and sockets frees (with no leak, seems)
1) is this the correct way (safe and clean) to build a FTP client? (one socket, one client, one task..)
2) restarting tasks could generate memory leak problems and unpredictable long time RTU crash/reset (a DataLogger must avoid resets) : there is a way to change socket options in ftpc_cmd (OPT_RECEIVE_TIMEOUT) and handle timeouts in blocking mode?
3) why socket "blocks" forever? (OPT_TIMEWAIT_TIMEOUT is 1000)