IPC@CHIP® RTOS – API Documentation
IPC@CHIP® RTOS – API Documentation |
|
The tickets are grouped by component and then sorted by type and ticket number.
| Ticket: | #2301 |
| Component: | RTOS - File system |
| Type: | defect |
| Summary: | DEL command malfunction with '*' wildcard |
| Description: | When file name is 8 characters, like 12345678.123, and the console command DEL 12345678*.123 is used, this system gives a "File not found" error message. The file 12345678.123 is not deleted. |
| Solution: | Allow short name match with wild card '*' in 9th position (or 4th position of extension name). |
| Ticket: | #2303 |
| Component: | RTOS - File system |
| Type: | defect |
| Summary: | Implicit file close at DOS SWI 0x21 service 0x40 on write failure is dangerous |
| Description: | The RTOS had in the past closed files when a read or write to that file fails. This was done to cope with fact that fclose() will not reach the close() action if a file flush fails, thus otherwise leaving that file open and potentially leaking RTOS file objects should that program then close. This logic can leave a program's FILE database out of sync with the RTOS. Consequently this logic leaves open the possiblity that a program could write to a different file than was associated with a given FILE object. Since that would cause the user extreme confusion, this close() logic should be removed from the DOS SWI 0x21 services 0x3F and 0x40. A possible resource leak resulting when a program does not react to a failure indication from fclose() is considered a less serious problem than would writing to or reading from a wrong file when a program's file handle database becomes out of sync with the RTOS. |
| Solution: | Removed the file close from DOS SWI 0x21 services 0x3F/0x40. |
| Ticket: | #2304 |
| Component: | RTOS - File system |
| Type: | defect |
| Summary: | "No file sharing" and "file sharing" modes not implemented correctly |
| Description: | When file sharing is not enabled, the open() file method fails to prevent an open for read when that file is already opened for write. |
| Solution: | Corrected file sharing implementation. |
| Ticket: | #2305 |
| Component: | RTOS - File system |
| Type: | defect |
| Summary: | BIOS_LFN_Findfirst() node lock problems |
| Description: | 1) Documentation states that this is a "write" lock. Actually it inhibits only a directory remove or rename operation. (Files within the directory can be added or deleted during this lock period.) 2) The node lock is not working at all when the search does not include the *.* after the directory name. 3) When file list editing is done during a directory scan, the scan may report non-sense on drives formatted with the PLP option. |
| Solution: | Problems corrected inside @Chip-RTOS. Also the previous limitation on PLP drives which allowed for only 6 concurrent directory scans has been eliminated. Now any number of directory scans can be done concurrently on a PLP drive (same file system resource limitations as for a normal drive). The PLP directory scan redesign required the enforcement of the 65536 node directory size limit specified by Microsoft's FAT specification. So now this limit is checked when nodes are added to a directory. (Before this was not checked.) |
| Ticket: | #2306 |
| Component: | RTOS - File system |
| Type: | defect |
| Summary: | File System PLP mode was not thread safe |
| Description: | On drives formatted with the PLP (Power Loss Protection) option, the drive can become corrupt due to concurrent write access by multiple tasks. For example, one task deleting files while another is creating files. |
| Solution: | Make all accesses to PLP type drives exclusive, so that all actions taken on the drive are executed sequentially rather than potentially concurrent. |
| Ticket: | #2309 |
| Component: | RTOS - File system |
| Type: | defect |
| Summary: | DOS SWI 0x21 service 0x44 may report wrong drive number |
| Description: | When file is opened with DOS 0x21 service 0x3D (open file), the file number reported by fstat() via service 0x44 will be that left over for the respective file handle from last call to service 0x3C (create file). In some cases, this will be the false drive number. |
| Solution: | Have file system record file's drive number at a more centralized location so no matter how file was opened the correct number will be there. |
| Ticket: | #2310 |
| Component: | RTOS - File system |
| Type: | defect |
| Summary: | BIOS_Fast_Findnext() does not release lock on completion |
| Description: | It was intended that BIOS_Fast_Findnext() would release the directory node lock when ever this function returns a 0 indicating "No file found", as is stated in this function's documentation. This automatic lock release does not occur, forcing the user to always call BIOS_Fast_Find_Done() in order to not leak file system resources. |
| Solution: | Implementation corrected so that lock and resources are released when "No file found" return value condition is true. |
| Ticket: | #2307 |
| Component: | RTOS - TCP/IP |
| Type: | defect |
| Summary: | Invalid parameters in IP outgoing callback |
| Description: | With ticket #2263 the IP outgoing callback has been moved to an earlier stage in order to be able to change the destination IP inside the callback. It seems that due to this change not all input parameters, e.g. the totalLength inside the IP header, are valid on entry to the callback. |
| Solution: | Fixed. |
| Ticket: | #2308 |
| Component: | RTOS - I2C |
| Type: | defect |
| Summary: | Wrong I2C divider initialization |
| Description: | The I2C divider/speed setting is not setup correctly. This bug was introduced with RTOS V1.60 and ticket #2294. |
| Solution: | Fixed. |
| Ticket: | #2311 |
| Component: | RTOS - Web server |
| Type: | defect |
| Summary: | Web server overwrites interrupt vector address 0 |
| Description: | The interrupt vector address 0 (divide error exception handler) can get overwritten by the web server on some operations like incoming POST requests or multipart messages. |
| Solution: | Fixed. |