IPC@CHIP® RTOS-PPC – API Documentation

Header image

Main page


Release Notes – SC2x3 @CHIP-RTOS-PPC V1.08

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


RTOS - Command shell
Ticket: #253
Component: RTOS - Command shell
Type: defect
Summary: REN console command error message misleading.
Description: When the new name is invalid, the error message states that the file was not found. This is not the case.
Solution: Revised error message text to indicate that the new name might also be the problem.




RTOS - Ethernet
Ticket: #236
Component: RTOS - Ethernet
Type: defect
Summary: Fault, when starting ethernet at runtime
Description: It is not possible to start ethernet at runtime, when it was disabled by chip.ini entry [IP] ETH_ENABLE=0
Solution: Fixed



Ticket: #250
Component: RTOS - Ethernet
Type: defect
Summary: Packet transmission and reception
Description: In rare cases (if large IP packets are fragmented), Ethernet packets are not send on the wire. In rare cases the Ethernet driver could also emit wrong packets.
Solution: Fixed.



Ticket: #235
Component: RTOS - Ethernet
Type: enhancement
Summary: Ethernet shutdown procedure
Description: In case of a power-fail handling it can be required to close the Ethernet device immediately to reduce the power consumption of the system.
Solution: Added, a power-down of the PHY will be executed, if API function Dev_Notify_Ioctl is called with flag DEV_IOCTL_EXTENDED and sub-option DEV_SUBIOCTL_KILL.




RTOS - File system
Ticket: #254
Component: RTOS - File system
Type: defect
Summary: REN command can result in disk corruption
Description: When power is lost after a REN command extends the length of a file name, this can result in the contents of the FAT not being correct.
Solution: Flush the FAT cache to disk following REN action.



Ticket: #255
Component: RTOS - File system
Type: defect
Summary: CHKDSK weakness
Description: If files are open for write at time CHKDSK executes, the disk's actual FAT contents may not be accessed by the CHKDSK, resulting in wrong conclusions.
Solution: Flush the internal FAT cache to disk, prior to initiating the CHKDSK action.



Ticket: #265
Component: RTOS - File system
Type: defect
Summary: FTLRECL command can loop forever
Description: When concurrent write activity is occurring on the A: drive, the FTLRECL shell command can hang forever. This can happen, for example, when a program pipes the console output to a log file on the A: drive.
Solution: Maintain map of blocks which have been erased and skip over these blocks if they become dirty again before the FTLRECL command cycle completes. Clean each block at most once per execution of FTLRECL.



Ticket: #266
Component: RTOS - File system
Type: defect
Summary: Switch shell task default drive if current drive is closed.
Description: When a disk drive is closed, the MTSK shell task's current default drive should not be left set to the drive which is closing. Otherwise a prompt such as "B:$>" may appear, if for example B: drive was removed while it was the current drive.
Solution: Switch MTSK task's default drive to A: if this task's current drive is closed.



Ticket: #280
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: #229
Component: RTOS - File system
Type: enhancement
Summary: Flash erase function should use RTX_Sleep_Time()
Description: The flash erase operation requires between 0,5 and 3,5 seconds to finish. Lower priority tasks should have a chance to execute during the flash erase procedure.
Solution: Use RTX_Sleep_Time() API inside internal flash erase loop.



Ticket: #256
Component: RTOS - File system
Type: enhancement
Summary: Avoid the slow flash erase cycles when they are not necessary.
Description: The FORMAT A: flash drive action is slower than it needs to be for cases where some of the flash memory is already in its required erase state. This can be improved.
Solution: Inspect flash memory blocks before erasing them, to determine if an erase action is necessary.



Ticket: #260
Component: RTOS - File system
Type: enhancement
Summary: Add status return value to BIOS_Disk_Close()
Description: Some feedback that an action was taken should be added to the BIOS_Disk_Close() API.
Solution: Add return value for BIOS_Disk_Close(). Test that drive path specifier contains the colon (no default drive accepted).




RTOS - Hardware
Ticket: #232
Component: RTOS - Hardware
Type: defect
Summary: gptGetStatus() delivers only the lower 8 bits of the capture value
Description: The function gptGetStatus(), that can be used to read the General Purpose Timer status, delivers only the lower 8 Bits of the capture register. The GPT status register holds a 16 Bit capture value.
Solution: Fixed.




RTOS - IPsec/IKE
Ticket: #248
Component: RTOS - IPsec/IKE
Type: defect
Summary: Big number divide overflow protection
Description: Cryptographic big number divide requires better protection against an overflow condition.
Solution: Improved overflow protection in big number divide function.



Ticket: #249
Component: RTOS - IPsec/IKE
Type: defect
Summary: IKE command console listing needs clean up
Description: The IKE comand's SA listing to the console is difficult to read when Blow Fish cipher has been selected.
Solution: IKE command console output format adjusted to make the columns of SA orderly.



Ticket: #251
Component: RTOS - IPsec/IKE
Type: defect
Summary: IPsec IKE not working with Windows Vista
Description: When the Beck target is the IKE initiator and the peer is Windows Vista, the Beck target does not accept the selected IKE proposal from the peer.
Solution: Ignore missing "life kBytes" field in IKE SA reply from peer.



Ticket: #264
Component: RTOS - IPsec/IKE
Type: defect
Summary: Miscellaneous IPSEC / IKE problems
Description: 1) Each use of the IPsec_Restore_Policy() API results in heap memory loss equivalent to the size of the IPsec policy file used.
2) IKE task can consume 100% of the CPU in the event that some socket problem occurs.
3) IKE task's UDP socket is closed when application task which called IPsec_Start() terminates. The IKE requires that this socket persists past the application closing.
Solution: Fix these various problems in the IKE and IPsec implementation.



Ticket: #268
Component: RTOS - IPsec/IKE
Type: enhancement
Summary: IKE use of FQDN for ID
Description: In some cases it is necessary to use the FQDN form of ID in the IKE ID payloads.
Solution: Add IKE_FQDN item to IPSEC section of CHIP.INI.




RTOS - PPP
Ticket: #231
Component: RTOS - PPP
Type: defect
Summary: Problem when configuring modem control messages
Description: When using the internal PPP client or PPP server, the user is able to specify modem messages at CHIP.INI or at the PPP client API to initialize and control the connected modem device. He can define string pairs for modem commands and expected answers. At the current implementation it not possible to specify modem answers, which contain one of the following strings:
"NO CARRIER"
"ERROR"
"NO DIALTONE"
"BUSY"
"NO ANSWER"

This is caused by the internal parsing method of the modem messages. It should be possible to specify these strings as valid expected modem answers.
Solution: Changed internal parsing method, so that these strings can be specified.



Ticket: #274
Component: RTOS - PPP
Type: defect
Summary: PPP server netmask setting
Description: The PPP server IPv4 net mask setting is wrongly always set to 255.255.255.255. The Chip.ini entry [PPPSERVER] NETMASK has no effect.
Solution: Fixed.



Ticket: #278
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.



Ticket: #233
Component: RTOS - PPP
Type: enhancement
Summary: PPP server start after RTOS boot
Description: At the current RTOS implementation the PPP server must be started inside the RTOS boot process. It should be possible to start this service later, even if it is disabled at chip.ini.
Solution: Implemented. It is now possible to start the PPP server with API PPP_Server_Activate().



Ticket: #273
Component: RTOS - PPP
Type: enhancement
Summary: Clearing internal PPP Pause state at PPP close/startup
Description: In case, that the user forgot to resume the PPP client (or server) task after stopping it with PPP_Client_Pause() it is not possible to open a new PPP session.
To avoid such a situation, the PPP drivers shall clear the internal PPP pause state, when closing/opening a PPP session.
Solution: Done.




RTOS - System
Ticket: #220
Component: RTOS - System
Type: defect
Summary: Application Program argument list is not NULL terminated
Description: The argument vector list passed to main() at argv[] must be NULL terminated. (Otherwise functions such as getopt() hit an exception.)
Solution: At program launch, set argv[argc] vector to NULL.



Ticket: #227
Component: RTOS - System
Type: defect
Summary: Application program "heap grow" operation defective
Description: The MMU page table handling around the heap grow action is not handled properly. This can result in more than one effective address reaching the same physical memory location.
Solution: Correct the arithmetic done when calculating the various addresses used in the page table entries.



Ticket: #228
Component: RTOS - System
Type: defect
Summary: No BIOS_Set_Error_Handler() callback at malloc() failures.
Description: When a program's heap grow action fails due to lack of virtual address space available to expand that program's image, no system error callback occurs.
Solution: Add BERR_LOWSPACE system error code and callback to cover this error condition.



Ticket: #234
Component: RTOS - System
Type: defect
Summary: Time/date cannot be set to a date after January 19, 2038
Description: The RTOS internal time/date cannot be set to a date after January 19, 2038.
Solution: The mktime() function has been corrected to take advantage of the full unsigned 32 bit range of the time_t type. This allows dates up to year 2106 to be represented and set.



Ticket: #257
Component: RTOS - System
Type: defect
Summary: CHIP.INI not closed correctly
Description: The CHIP.INI file is not closed correctly after system start. If the CHIP.INI is deleted and new entries are written (e.g. by IP configuration or with BIOS_Set_Ini_String) this could lead to that some entries are missing inside the file afterwards.
Solution: Fixed.



Ticket: #275
Component: RTOS - System
Type: defect
Summary: Correct limit on number of command line arguments
Description: The intended limit on number of command line arguments was 12, but the system is limiting this to 11.
Solution: Correct limit logic.



Ticket: #243
Component: RTOS - System
Type: enhancement
Summary: Allow usage of character '[' in CHIP.INI values
Description: It should be possible to use the character '[' in CHIP.INI values.
The '[' character should only start a section if it appears at the start of the line.
Solution: Implemented.



Ticket: #285
Component: RTOS - System
Type: enhancement
Summary: RTX_Wait_Queue() API adjustments
Description: 1) The RTX_DETAIL_TASK object reported by RTX_Count_Resources() and RTX_Wait_Queue() API should include the task's stack pointer base address so that callers can know what heap memory to release when a task is deleted.

2) When the RTX_FILT_TASK filter value use used with the RTX_Wait_Queue() API, the calling tree information appended after the RTX_DETAIL_TASK object should include the stack frame pointers.
Solution: Changed these aspect of this API to include the stack frame pointers and the task's stack base address.




RTOS - TCP/IP
Ticket: #224
Component: RTOS - TCP/IP
Type: defect
Summary: accept() and accept_bsd() must handle NULL addressPtr argument
Description: The accept() implementation does not accept a NULL for the addressPtr argument. The standard definition for this function allows this. This also goes for the addressLen pointer passed to accept_bsd().
Solution: Adjust the parameter checking at entry to accept() function.



Ticket: #244
Component: RTOS - TCP/IP
Type: defect
Summary: Parameters of Dev_Get_IP
Description: TCP/IP API function Dev_Get_IP() returns with error code -1, if net mask parameter is a NULL pointer.
Solution: Fixed.



Ticket: #245
Component: RTOS - TCP/IP
Type: defect
Summary: IP forwarding is not working
Description: The IP forwarding option is not working correctly. No packets are forwarded between the interfaces.
Solution: Fixed.



Ticket: #262
Component: RTOS - TCP/IP
Type: defect
Summary: SSL client does not accept server hello messages without a session ID
Description: The server may send a SSL session ID in his server hello message, but this must not be the case. Should also accept server hello messages that do not contain a session ID.
Solution: Fixed.



Ticket: #289
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: #242
Component: RTOS - TCP/IP
Type: enhancement
Summary: Multiple IP addresses for Ethernet interface in CHIP.INI
Description: It should be possible to configure more than one IP address for the standard Ethernet interface (multi homes) in the CHIP.INI. Currently this can only be done over API functions.

The addresses should be defined as described below (where the keywords "ADDRESS0" and "NETMASK0" are not used for downward compatibility).

[IP]
ADDRESS=192.168.100.5
NETMASK=255.255.255.0
ADDRESS1=192.168.200.10
NETMASK1=255.255.255.0
ADDRESS2=172.10.0.100
NETMASK2=255.255.0.0
Solution: Implemented. Also fixed an issue that the netmask does not default to 255.255.255.0, when the NETMASK tag is not given in CHIP.INI.



Ticket: #267
Component: RTOS - TCP/IP
Type: enhancement
Summary: TCP/IP Timer tick interval
Description: The current TCP/IP timer tick interval is 100 ms. Should increase the resolution of this timer to improve the accuracy of e.g. the TCP retransmission timeout.
Solution: Set TCP/IP timer interval to 10 ms.



Ticket: #271
Component: RTOS - TCP/IP
Type: enhancement
Summary: Configuration of IP forwarding per network device
Description: It should be possible to enable/disable IP forwarding and broadcast packet forwarding for each network device.
Solution: Implemented. CLIB API function Dev_SetSpecificFlags_IPv4() provides this feature.




RTOS - Web server
Ticket: #247
Component: RTOS - Web server
Type: defect
Summary: Memory leak on malformed Content-Length header
Description: A memory leak can occur, if the browser sends a malformed content-length header field in his request. The web server should also tolerate that the whitespace after a header field is missing, e.g. "Content-Length:73" should be accepted, same as "Content-Length: 73".
Solution: Fixed.



Ticket: #281
Component: RTOS - Web server
Type: defect
Summary: Duplicated free of allocated memory
Description: In rare cases the webserver frees an internally allocated buffer twice after execution of CGI function. In that case the RTOS heap management prints a warning at stdout.
Solution: Fixed



Ticket: #282
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: #272
Component: RTOS - Web server
Type: enhancement
Summary: Number of SEC_URLx entries
Description: We should increase the number of possible secure URL locations, users and passwords from 2 to 10.
Solution: Implemented.



Ticket: #277
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: #283
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: #287
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.




RTOS - CAN
Ticket: #288
Component: RTOS - CAN
Type: enhancement
Summary: Function to get number of messages in CAN receive queue
Description: The CAN API should feature a function to determine the number of messages waiting in the software receive queue of a CAN port.
Solution: Implemented




RTOS - Config server
Ticket: #269
Component: RTOS - Config server
Type: enhancement
Summary: Hello replies should be send with a random delay
Description: Added a random 5-20ms sleep delay before sending hello replies to avoid simultaneous network traffic and possible collisions.
Solution: Added random delay.




RTOS - Serial ports
Ticket: #222
Component: RTOS - Serial ports
Type: enhancement
Summary: Should increase number of possible external fossil ports
Description: Currently only up to 5 external/virtual UART ports can be installed with fossil_register_external_port(). Should support up to 20 ports.
Solution: Implemented.




RTOS - USB
Ticket: #240
Component: RTOS - USB
Type: enhancement
Summary: Switch on/off port power
Description: The USB API should feature a function to explicitly switch on/off the power of a port.
Solution: Implemented








Top of page | Main page

Copyright © 2009 Beck IPC GmbH