
Release Notes for StellarisWare Revision 5727 (March 2, 2010)
14.7.2 USB Control requests can hang on error (Reference 11326)
If an error state occurs on USB control request to endpoint 0, it could cause the USB library to hang
while attempting to enumerate a USB device. The control requests to endpoint 0 will now terminate
in the event of an error and allow the USB library and an application to respond to the error. This
issue could affect any USB device during enumeration, however it was having a more obvious effect
on some USB Mass Storage devices.
14.7.3 Host enumeration was incorrectly requesting a zero byte packet (Ref-
erence 11517)
The USB library host enumeration code was incorrectly requesting an extra zero length packet
when reading descriptors from a USB device. This could cause the device to Stall the transaction
and the USB library would then fail to enumerate the device. This only happened when a USB
device had any 64 byte aligned descriptors.
14.8 New Features in Stellaris Utility Librar y
14.8.1 Added features to bdc-comm (Reference 11321)
Several new features have been added to the bdc-comm GUI. There is now a mechanism for
recovering a MDL-BDC or MDL-BDC24 that has had the incorrect firmware programmed into it
(accessed via the File->Recover Device menu item). It is now possible to assign device IDs to a
MDL-BDC or MDL-BDC24 even if bdc-comm can not find any devices on the network (they may be
there without an assigned ID and therefore do not enumerate). The Help->About menu item was
added, which brings up a dialog that shows the version of the bdc-comm applcation. The numeric
entry fields within the GUI have been modified to behave in the expected manner (click and drag
will now select portions of the value instead of changing the value). And the firmware filename field
in the fir mware update dialog is now pre-populated with the previous firmware filename so that it
can be used multiple times to update more than one MDL-BDC or MDL-BDC24.
14.9 Bug Fixes in Stellaris Utility Library
14.9.1 Correct leap day handling in ulocaltime (Reference 11049)
Leap days were not properly handled in ulocaltime, causing it to incorrectly report Feb 29 of a leap
year as Mar 1, and Mar 1 of a leap year as Mar 2 (with all other days being reported correctly). It
now properly handles leap days.
122 September 16, 2011
Komentarze do niniejszej Instrukcji