I am experiencing something which is kind of a bug with file system API. The firmware version I am using for the Quectel EC200U FS application does not support reading a file by just its filename. A file handle number must be extracted.
This brings up another issue, for instance, if I want to open a file that was previously opened but the file handle number was not captured during the running of the program, I am forced to reboot the module. Consequently, I cannot close the file because I don’t have the file number.
It would be more intuitive to open and close files by their file names. For example, If I attempt to open a file but receive a CME ERROR 426 ( File already opened ), I should should be able to close the file and re-attempt to open it again. Alternatively, if there was a feature to query the file handle number of a file, then it would make it easier for closing the file rather than rebooting the modem.
Capturing file handle numbers in your program is extra overhead.
Hi Gideon,
Thank you for the question.
This behavior is expected on EC200U modules using the QuecOpen file system API and is not a firmware bug.
Below is a structured explanation and the recommended solution, for clarity.
- File System Design Limitation (By Design)
On EC200U modules using the QuecOpen solution, all core file operations are handle-based, not filename-based.
Key Points:
ql_fopen() must return a file handle (QFILE)- All subsequent operations require this handle:
ql_fread()
ql_fwrite()
ql_fclose()
ql_fsync()
There is no API to:
- Close a file by filename
- Query an active file handle using a filename
- Force-close an already opened file
So if the file handle is lost during runtime, the system has no method to recover it.
- CME ERROR 426 – “File already opened”
When you encounter:
CME ERROR 426 (File already opened)
This indicates:
- The file is still held open by the filesystem
- The file handle exists internally but is no longer accessible to the application
- There is no documented API to retrieve or release that handle
Best Practices:
-Always store the returned QFILE fd immediately after ql_fopen()
-Maintain a global or centralized file-handle table (array / struct / map)
-Never overwrite or discard a handle before calling ql_fclose()
-Ensure error paths (timeouts, exceptions, task exits) also close files
This is the only safe and supported method to avoid file lock issues.
Solution 2: Software Reset as Recovery (Fallback)
-If a file handle is lost and the system reports “file already opened”:
-There is no API to recover or force-close the file
-A module reset is the only recovery mechanism
-You can programmatically trigger this using:
ql_power_reset()
This clears all open file descriptors by restarting the OS and filesystem.
Hope this helps!
Have a great day!
Best Regards,
Ananthan
Thanks for clearing this up @Ananthan