Defects Fixed: Id
Headline SDOCM00057038
CLK_gethtime() can return incorrect value (too small by one internal
timer period) on faster 28x devices SDOCM00056832 enable timer should be set to true for evm6747 SDOCM00056786 BIOS 55x configuration files should use LARGE model as default SDOCM00056725 BIOS should use a separate lock for MEM and RTS to avoid deadlock in filesystem/USB app SDOCM00056575 enable RTA/RTDX channels to simpify CCSv4-based RTA SDOCM00056484 validate 28x BIOS with latest 5.2.0 codegen tools SDOCM00056305 add support for 28x Piccolo (2802x/2803x) and Delfino (2834x) devices SDOCM00053866 add BIOS support for 6748 and OMAPL138 device families SDOCM00053801 add BIOS support for DRA457 and DRA459 devices SDOCM00053517 SYS_printf() should support %f for the 28x floating point libraries (.a28FP)
DSP/BIOS is binary compatible with DSP/BIOS 5.32 (and all the way
back to DSP/BIOS 5.21). Users do not need to recompile your source
files or libraries when updating to BIOS 5.33. However users *must*
rebuild their configuration since the generated linker .cmd file
(<prog>cfg.cmd) is different.
Solaris host is no longer supported in this release.
Customer-critical bug
fixes to earlier releases will be available to Solaris users if
required.
DSP/BIOS 5.33 does not support TMS320C54xx devices. Users of
such devices
should continue use DSP/BIOS 5.31.xx earlier releases. For
customer-critical
54xx-related issues, TI will continue to provide fixes to earlier
versions when
needed.
Compatibility Key Definitions
Compatibility keys are intentionally independent of Marketing
product
numbers and are intended to:
Enable tooling to
identify incompatibilities between components, and
Convey a level of
compatibility between different releases to set end user expectations.
Compatibility keys are composed of 3 comma-delimited numbers -
M,S,R -
where:
M = Major.
A difference in M indicates a break in compatibility.
S = Source.
A difference in S indicates source compability.
That is, the user's source doesn't require change, but does
require rebuilding.
R = Radix.
A difference in R indicates an introduction of new features, but
compatibility with previous interfaces has not broken. If libraries are
provided by the package, an application must re-link with the new
libraries, but not rebuild from source.
Problems with 6.1.x Codegen Tools and older c6x devices -- Cleanup
of generated .cmd files to be compatible with new and legacy linkers
(5.1.x/28x, 4.2.x/55x, and 6.1.x/6x). The generated *cfg.cmd files have
been updated to use RUN_START/RUN_END syntax (instead of '.=') to
generate symbols where necessary. Prior to this change, there were some
comaptibility problems with old/new linkers for 28x and 55x. Note that
the 6.1.x linker will still generate a warning for 62x, 64x, and 67x
applications. This warning does not occur for 64x+, 67x+ or 674x
targets. Until this issue is resolved we recommend using 6.0.x tools
when using DSP/BIOS 5.33 for 62x, 64x, or 67x. This issue is tracked by
SDSCM00027852.
Davinci
1.x IDMA0 problem workaround -- A custom version of
the HWI dispatcher was created to work around an IDMA0/MMR
problem in rev 1.x DM644x devices (see SPRZ241 - "TMS320DM6446 Digital
Media System-on-chip Silicon Errata" for more information about this
errata). This errata is only present in Rev 1.x DM644x
devices and is not present on other 64x+ devices.
The
HWI dispatcher has been updated to poll the IDMA0 status register and
wait for IDMA0 transfer to complete before calling the actual
ISR. This will ensure that the ISR will not reference an MMR
register while the IDMA0 is active. This will also ensure
that an asynchronous task switch will not occur while the IDMA0 is
active. This may affect interrupt response time, but should
not be a problem in most applications since IDMA0 jobs are usually
fairly short. This workaround is only supported by the HWI
dispatcher (the
HWI_enter/exit macros do not contain the workaround).
A
hidden configuration parameter (bios.GBL.USEIDMA0DISPATCHER) is used to select
this alternate version of the dispatcher. This parameter has
default value 'true' for DM644x and DM42x configurations.
This parameter has default value 'false' for all other 64x+
configurations. The user can set this parameter to 'false' if
they do not want this workaround used in their Davinci applications
(e.g., if their application is not using IDMA0 and/or they know that
that their ISRs do not reference MMR registers).
Memory
heap issue when updating existing configuration files --
Prior versions of the configuration tool allowed for an inconsistent
memory heap configuration. The tool allowed users
to enable heaps when no heaps were actually configured and the default
for bios.MEM.MALLOCSEG and bios.MEM.SEGZERO were still set to
'MEM_NULL'. This was causing problems in applications since
malloc() and MEM_alloc() were failing even when user thought they had
configured BIOS for dynamic memory allocation. The
configuration tool is now checking to make sure that configurations
that have heaps also have bios.MEM.MALLOCSEG and bios.MEM.SEGZERO set
to a valid heap. Update from existing projects might yield an
error message. The work around is to either remove the
'bios.enableMemoryHeaps(prog);' line from your configuration, or to add
a heap and set bios.MEM.MALLOCSEG and bios.MEM.SEGZERO
accordingly. See the
ti/bios/examples/common/evmDM6446_common.tci file (or others) for an
example of how to do this.
Gconf
uses wrong parameters when more than one pjt is opened and they share
the same .tcf file -- When
more than one CCS project
(.pjt file) share the same .tcf file, and two or more of the projects
are opened in CCS, opening a .tcf from one of the projects will launch
GConf using the DspBiosBuilder builder parameters defined for the most
recently opened project. This may result in incorrect base seed
properties and import file paths in the .tcf file being edited. To
workaround, do not share .tcf files between projects. This is tracked
by SDSCM00003834
BIOS
RTA has problems
reading data in stop mode for some 64x+ devices
-- Currently,
stop mode reads will only work for DaVinci. This is tracked by
SDSCM00010400
DSP/BIOS
examples
that are using RTA halt when run every other time on
DSK5510/DSK5509A via XDS560 -- This is tracked by
SDSCM00005820.
CCS
window closes on
refreshing KOV Window when it receives illegal
values -- KOV will crash if Module Objects have illegal
values. For e.g if a dynamic task has a bad name, KOV will try to print
the illegal name and crash. This is tracked by
SDSCM00006694.
KOV
window shows wrong names for dynamic objects --
This
is tracked by
SDSCM00007151.
KOV
displays wrong names for memory sections --
This is tracked by SDSCM00004917.
Incorrect
platform name in Tconf User's Guide in
"Create New Platform"
section --
The spru0007h.pdf
document contains the correct instructions for creating a new platform
using the Tconf's User's Guide, the help files were not updated to
reflect the same naming convention. This is tracked by SDSCM00003471.
RTDX
tutorial examples do not all execute as
expected when
run on TCI6482 simulator little endian --
This is tracked by SDSCM00010736.
RTDX
Hot-Connect does not work for C64P -- This is tracked by
SDSSCM00011954
RTDX size_t problem with 55 Huge -- dsk5505 hostio example RTA problems when using huge model. This is tracked bySDSCM00027957.
DSP/BIOS
RTA Control Panel does not update values correctly when using comma
decimal separator in Windows -- The RTA Control Panel
does not work as expected when using Windows Regional
Settings where ',' is used instead of '.' for the decimal
separator. Only workaround is to use Regional Settings where
'.' is the decimal separator, or use default 1 second update
rate.This is tracked by SDSCM00017755.
HWI_isHwi()
documentation has
contradictory statement -- In
previous versions of DSP/BIOS, " calling HWI_isHWI() from main()
resulted in TRUE. This is no longer the case;" main() is
identified as part of the TSK context.This is tracked by
SDSCM00020436.
Some
of the help files in BIOS
5.32 refers to BIOS 5.31 -- This
is tracked by SDSCM00020437.
This product's version follows a version format,M.mm.pp.bb,
whereMis a single digit Major number,mm
is 2 digit minor number,ppis a 2 digit patch
number, andbis an unrestricted set of digits used
as an incrementing build counter.
To support multiple side-by-side installations of the
product,
the product version is encoded in the top level directory, ex.bios_5_33.
Subsequent releases of patch upgrades will be
identified by
the patch number, ex. BIOS 5.33.03 with directorybios_5_33_03.
Typically, these patches only include critical bug fixes.
Please note that version numbers and compatibility
keys are
NOT the same. For an explanation of compatibility keys, please refer to
the 'Upgrade and Compatibility Information' section.
