IPC@CHIP® RTOS – API Documentation

Header image

Main page


Release Notes – SC1x3 @CHIP-RTOS V1.50

The tickets are grouped by component and then sorted by type and ticket number.


RTOS - System
Ticket: #2189
Component: RTOS - System
Type: defect
Summary: RTX_Install_RTI_Hook implementation error
Description: The RTI hook callback relies upon the application's callback to not change the ES register's contents. This violates both the RTX_Install_RTI_Hook() documentation and the C-Language calling convention.
Solution: Correct RTI code where callback is made so that it saves ES register prior to making the callback into the application's RTI hook.



Ticket: #2182
Component: RTOS - System
Type: enhancement
Summary: RTX_Get_Sem() implementation changed
Description: The RTX_Get_Sem() need not be restricted to only counting semaphores. With an small change in implementation, it can also be used for resource type semaphores.
Solution: Implement RTX_Get_Sem() API so that it also works for resource type semaphores.



Ticket: #2222
Component: RTOS - System
Type: enhancement
Summary: Watchdog manager
Description: The RTOS should feature a watchdog manager which is able to supervise several tasks. Each task that has registered with the watchdog manager has to call a refresh function within a period of time which is specified by the task itself. The watchdog manager will refresh the hardware watchdog only if all registered tasks have refreshed within the given period of time.
Solution: Implemented



Ticket: #2228
Component: RTOS - System
Type: enhancement
Summary: API for changing Telnet, FTP, SSH user/password settings required
Description: It should be possible to modify the FTP, Telnet and SSH user name/password settings without requiring a reboot.
Solution: Implemented. CLIB function BIOS_Set_ServerCredentials() provides the wanted functionality.




RTOS - PPP
Ticket: #2190
Component: RTOS - PPP
Type: defect
Summary: PPP server gateway handling
Description: If a gateway entry is defined at CHIP.INI section [PPPSERVER] and a PPP session is closed, the PPP server tries to restore the old gateway always with the parameter "ethernetHandle". This could be false. It could be also the gateway from Ethernet1 or WLAN, or etc.
Solution: Fixed.




RTOS - Web server
Ticket: #2193
Component: RTOS - Web server
Type: defect
Summary: Duplicated free of allocated memory
Description: In rare cases the web server frees an internally allocated buffer twice after execution of CGI function.
Solution: Fixed.



Ticket: #2195
Component: RTOS - Web server
Type: defect
Summary: Potential memory leak
Description: In some cases the web server can leak memory.
Solution: Fixed. Also reduce the TCP FIN-WAIT-2 timeout for web server connections from 600 to 30 seconds to reduce the needed TCP/IP memory amount when the client does not close the connection correctly.



Ticket: #2004
Component: RTOS - Web server
Type: enhancement
Summary: CGI interface should support additional headers, optional chunked encoding and a streaming-like data-interface.
Description: The web server's CGI interface should be extended with the following features: 1) A user application's CGI function should be able to define additional application specific HTTP response header fields. 2) The CGI interface should support a flag to specify whether the response should be sent chunked encoded or not. 3) The CGI interface should be able to be called again to produce asynchronous more data to be sent to the requestor.
Solution: Implemented. New members fResponseHeadersPtr, fFlags and fLongParam added to rpCgi data structure.



Ticket: #2179
Component: RTOS - Web server
Type: enhancement
Summary: Possibility to disable user name and password for upload
Description: It should be possible to disable the user name and the password query for the web server upload feature.
Solution: Password query is disabled if CHIP.INI section looks like this:
[WEB]
USER0=
PASSWORD0=

Anyhow, it's not recommended to operate the web server in this mode, because without user name and password the web server cannot be protected against unauthorized uploads.



Ticket: #2196
Component: RTOS - Web server
Type: enhancement
Summary: Function to change user names and passwords needed
Description: Should add the possibility to change the web server's user names and passwords without requiring a reboot.
Solution: Add API function CGI_SetCredentials() to change web server's user names and passwords.



Ticket: #2197
Component: RTOS - Web server
Type: enhancement
Summary: Response fields in rpCgi structure should be initialized
Description: The response fields fResponseBufferPtr and fResponseBufferLength in the rpCgi structure should be initialized with zero before the CGI callback is executed. This can prevent malfunction e.g. when the user forgets to set these values.
Solution: Implemented.



Ticket: #2200
Component: RTOS - Web server
Type: enhancement
Summary: HTTP header lines for static files
Description: The user should have the possibility to add header lines to the web server response if static files are requested.
Solution: Add functions CGI_Install_Headers_Table()/CGI_Remove_Headers_Table()




RTOS - File system
Ticket: #2192
Component: RTOS - File system
Type: defect
Summary: CHKDSK command /f option weakness
Description: The CHKDSK command's /f option fails to clean up invalid long file name directory nodes when these invalid nodes are at the end of a file system block.
Solution: Flush revised DIR block to disk after correcting LFN nodes.



Ticket: #2207
Component: RTOS - File system
Type: defect
Summary: Excess cluster allocation for directories
Description: When files with long names are added to a directory, the file system in some cases may allocate more clusters than are required for the directory.
Solution: Use the correct DIR node count adjustment when directory is extended by one cluster.



Ticket: #2209
Component: RTOS - File system
Type: defect
Summary: File System memory allocation from user tasks
Description: Memory blocks required by the system can end up assigned to an application program's task when FORMAT command is executed from a program.

This causes file system problems when the application program terminates and this memory is automatically released.
Solution: Assign file system memory blocks to system.



Ticket: #2210
Component: RTOS - File system
Type: defect
Summary: rename() C-Library function implementation incomplete
Description: The standard C-Lib rename() function can be used to move a file within a drive from one directory to another. The @CHIP-RTOS does not support this aspect of the rename() standard library function.

A second problem with rename() (and REN console command) is that path names longer than the 259 character limit could result due to a check for this condition was missing.
Solution: Edit directory nodes to allow both file or directory moves within a given drive. Prevent DIR moves to a subdirectory of the directory being moved.

Also assure that no path name longer than 259 characters could result from rename() or its command line equivalent, REN.



Ticket: #2211
Component: RTOS - File system
Type: defect
Summary: rename() malfunctions
Description: The implementation for the rename() C-library function has the following problems:
1) Rename to no name "" works, leaving the file with white space for a name.
2) The current "." and parent ".." directory entries can be renamed. This must be prevented.
Solution: Correct the REN command and rename() function implementations to prevent these actions.



Ticket: #2212
Component: RTOS - File system
Type: defect
Summary: DOS SWI 0x21 set/get file attribute service 0x43 accepts blank file name.
Description: The C-Library _dos_getfileattr() returns attributes of the current working directory when an empty "" file name is passed in.

This should instead result in a "file not found" type error.
Solution: Return ENOENT error code when empty string "" is passed as the file name.



Ticket: #2223
Component: RTOS - File system
Type: defect
Summary: Correct semaphore handling at File System flash block erase
Description: A semaphore access was missing where the flash block erase verify action was taken.

This semaphore handling error would normally cause no problem due to that sufficient protection for most cases is provided by another semaphore over the A: drive up stream from this one. However, a problem could result when A: drive write activity and Chip-Tool download of an @CHIP-RTOS update are run concurrently.


Solution: Add semaphore access before verifying block erase.



Ticket: #2178
Component: RTOS - File system
Type: enhancement
Summary: Strengthen the flash modify methods
Description: When flash memory ages, eventually the flash reaches a stage where a write or block erase might fail but on repeated attempts the action can be achieved. Consequently a retry attempt would be worthwhile.

To further assure that the flash drive integrity, it would be helpful for the flash driver to verify that writes and block erase actions are successful.

Finally, some trace information available to the user under the ERRORS console command would be useful so that user's get some indication that flash memory is perhaps nearing the end of its life cycle.
Solution: Add flash write/erase verify and report errors.



Ticket: #2187
Component: RTOS - File system
Type: enhancement
Summary: Add Power Loss Protection option to File System
Description: When power is lost during file system write activity, in some cases the drive can be left in a corrupt state.

Therefore it would be desirable to have the file system optionally provide Power Loss Protection (PLP) to drives. This drive feature is made optional due to that PLP will slow down a drive's write speeds, somewhat.
Solution: Add /PLP option to format command.



Ticket: #2205
Component: RTOS - File system
Type: enhancement
Summary: FTL mapping change for better flash load leveling
Description: The mapping between A: flash drive logical sectors and the physical "Flash Translation Layer" in the flash devices' tend to place all of the FAT blocks in the same area. Since the file system's FAT blocks tend to be written often, this concentration of write activity in a particular section of the flash could lead to the device wearing out with under utilized sections of the flash device still fresh.

With a change in Flash Translation Layer mapping method, the flash devices' load leveling can be improved so that FAT activity is smeared throughout the device and not localized to a particular area of the device, and thus increasing the expected lifetime of the flash drive.
Solution: Change File Translation Layer method when A: drive is reformatted. Provide an /O option at the FORMAT command to force use of old translation method when compatibility with old @Chip-RTOS versions is required.

Show current FTL method at the FTLSTAT report as either "Legacy" or "Modulo" (new method).



Ticket: #2221
Component: RTOS - File system
Type: enhancement
Summary: FORMAT command should preserve existing cluster size by default
Description: SD card performance will be less likely to degrade after a FORMAT operation if the drive's existing sectors per cluster count is reused upon reformatting.
Solution: Use existing cluster size when an open external drive is formatted, and no explicit cluster size or change between FAT16 and FAT32 has been specified.



Ticket: #2225
Component: RTOS - File system
Type: enhancement
Summary: Add timeout to low level flash erase/program functions
Description: Should avoid endless loops if the flash memory does not signal the end of the erase/program operation correctly.
Solution: Implemented.




RTOS - CAN
Ticket: #2213
Component: RTOS - CAN
Type: defect
Summary: CAN Bus-off error indications inadequate
Description: The CAN_Status() API reports the BUS-OFF error condition on a one-shot bases. This error must be reported on every call until the condition is no longer present.

Also, it would be helpful if the CAN_Send() and CAN_Recv() API reported this BUS OFF error condition since this is central to both of these API's operation.
Solution: Add new error code CAN_EC_BUS_OFF returned by CAN_Send(), CAN_Recv() and CAN_Peek() API when the Bus Off error condition is present.

Revise CAN_Status() so that the CAN_BUS_OFF error flag in the CAN_STATUS Errors bit field is always set when the Bus Off condition is true.



Ticket: #2203
Component: RTOS - CAN
Type: enhancement
Summary: Allow CAN Receiver callback to filter out CAN messages
Description: The RTOS-x86 CAN driver should allow users to filter out received CAN messages before they are put into the receive queue.

The RTOS-PPC CAN driver implements this with a return value from the CAN Rx callback function. For compatibility with existing RTOS-x86 CAN driver API, the RTOS-x86 will need to use some other "discard message" signalling scheme from the callback, since the existing API's callback function prototype specifies a void return type.
Solution: For compatibility with existing RTOS-x86 CAN driver API, the RTOS-x86 will filter out CAN messages by setting the MS bit of the Len_Ctrl member of the CAN_MSG passed to the receiver callback.




RTOS - IPsec/IKE/Crypt
Ticket: #2217
Component: RTOS - IPsec/IKE/Crypt
Type: defect
Summary: Cryptographic API big number size limit check not correct.
Description: On API such as the Crypt_BN_Mod_Exp(), the check for too large a big number is not correct. The intended 512 byte limit check was actually checking for less than 2048 bytes.
Solution: Correct the digit limit check.




RTOS - USB
Ticket: #2219
Component: RTOS - USB
Type: defect
Summary: Bug in enumeration
Description: Enumeration of a USB device may fail if one of the device's descriptors is sent in several packets and one of the packets accidentally starts with a special byte sequence.
Solution: Fixed



Ticket: #2218
Component: RTOS - USB
Type: enhancement
Summary: Perform enumeration similar to PC host
Description: Some USB devices rely on the host to enumerate them the way Microsoft Windows does rather than relying on the USB specification. To support these devices the @CHIP-RTOS' USB stack should behave similar to a PC host.
Solution: Implemented




RTOS - TCP/IP
Ticket: #2198
Component: RTOS - TCP/IP
Type: defect
Summary: DNS client doesn't accept answers from authoritative servers that do not provide recursion
Description: The DNS client of the @CHIP-RTOS expects the DNS server to perform recursion if it cannot answer a query itself. Answers from servers that deny recursion are discarded. However if the server is the authority for the queried domain, its answer should be accepted although recursion is denied.
Solution: Fixed



Ticket: #2226
Component: RTOS - TCP/IP
Type: defect
Summary: DNS client fails to query other servers if first server had no resolution
Description: The RTOS' DNS client queries several DNS servers until one of them can provide a resolution. However if the first server sends a reply, but the reply does not contain the resolution, the DNS client will send invalid queries to the other servers.
Solution: Fixed



Ticket: #2216
Component: RTOS - TCP/IP
Type: enhancement
Summary: Add recvfromto_iface() API call
Description: In some cases it is required to know on which interface the packet arrived. So a function which delivers the interface handle in addition to the packet is needed.
Solution: Add recvfromto_iface() to TCP/IP API.




RTOS - FTP server
Ticket: #2202
Component: RTOS - FTP server
Type: defect
Summary: Wrong working directory
Description: When the DRIVE entry is present and e.g. set to B: and no ROOTDIR is given and the drive B: does not exist, the FTP server starts in drive A:, but the current working directory shows B:.
Solution: Fixed. If no ROOTDIR is specified and the drive does not exist, the FTP server should fall back to the virtual root directory. If a sub directory is specified at the ROOTDIR entry and the drive does not exist, the connection should be refused.




RTOS - Command shell
Ticket: #2204
Component: RTOS - Command shell
Type: defect
Summary: memdmp command can spin forever
Description: If the size that should be dumped is near 65536 the memdmp command can get into an endless loop.
Solution: Fixed.



Ticket: #2206
Component: RTOS - Command shell
Type: enhancement
Summary: CHKDSK improvements
Description: The CHKDSK command should do some additional checks on disk integrity.

Also the "Lost sectors" statement when actually it is disk "Clusters" which have been lost, should be corrected.
Solution: 1) Detect differences between FAT0 and FAT1 for drives with more than one FAT.
2) Report count of clusters found to be in use which, according to the FAT, were not allocated.
3) Detect/fix directory cluster chain problems.
4) State "Lost clusters" instead of "sectors".
5) Report cluster size and FAT12/FAT16 root directory capacity.




RTOS - Ethernet
Ticket: #2194
Component: RTOS - Ethernet
Type: enhancement
Summary: Allow reception of IP and ARP packets via the ethernet packet driver interface
Description: The RTOS Ethernet packet API should allow the installation of receiver handles for incoming ARP and IP packets. ARP and IP packets are still handled by TCP/IP, but these packets shall be also available, if a handler for these packet types is installed. The SC243 RTOS already supports this feature.
Solution: Implemented.



Ticket: #2215
Component: RTOS - Ethernet
Type: enhancement
Summary: Ethernet send() with active wait loop
Description: The internal Ethernet driver_send() function waits active a max. time of 0.5 seconds, until a packet can be send on the wire. In case of high network traffic, this can block lower prioritized tasks. The driver_send() function should be modified. After an active wait of approx. 1 ms, it should wait passive with a sleep call.
Solution: Implemented.




RTOS - Config server
Ticket: #2220
Component: RTOS - Config server
Type: enhancement
Summary: Program flash with Hello replies disabled
Description: Since RTOS 1.40: When a program flash procedure has started, the UDP config server doesn't reply to Hello requests. This should speed up the image transfer. This method has a disadvantage: In case of an aborted transfer the UDP config server still doesn't reply to Hello requests and cannot be found at the network. In that case a new program flash transfer must be started with the non-local option. This behavior should be modified.
Solution: Send hello replies also when flash update was started.




RTOS - Serial ports
Ticket: #2214
Component: RTOS - Serial ports
Type: enhancement
Summary: Add fossil_output_done() and fossil_data_avail() functions
Description: These functions are already implemented at the RTOS-PPC, should support them also at the RTOS-x86.

If the RTS/CTS mode is used at the serial RS232 port, fossil_flush_output() can wait forever, when the #RTS-Signal (connected to CTS) is not cleared by the remote peer. Therefor the Fossil-API should provide an additional function fossil_output_done() to poll for the transmitter to become empty.
Solution: Implemented new fossil functions fossil_output_done() and fossil_data_avail(). Also add a fossil_register_external_port_ext() function to support the new functions also at an external port.








Top of page | Main page

Copyright © Beck IPC GmbH