Generating code from a model containing the Autocorrelation block with constant sample time and the Inline parameters check box selected in the Simulation Parameters dialog box might cause a segmentation violation.
The Data type override parameter of the Fixed-Point Settings interface does not currently work for fixed-point DSP Blockset blocks in subsystems.
The DSP Fixed-Point Attributes (DFPA) block does not function inside a masked subsystem or a library-linked subsystem. No error is thrown, but after the model is saved and reloaded, or after any names are changed in the DFPA path, the blocks will have no effect and will not show up in the DFPA GUI.
The Rounding mode and Overflow mode popups in the DFPA GUI do not show the correct values when the GUI is first launched. The two modes are 'Unset,' but 'Floor' and 'Wrap' are shown in the popups. Regardless of what is shown, these two modes are treated as 'Unset' when the GUI is first launched. If you select and then unselect the relevant check box, these popups will show the correct values. You only need to do this once per MATLAB session.
The DSP Gain block will only work with discrete-time signals.
When you apply optimizations for 1, -1, and 0 gains on fixed-point realizations of lattice structures in the Filter Realization Wizard, some Convert blocks are removed. The optimized model then produces significantly different results when compared to the results from the non-optimized model.
The ANC demo overruns on Windows 98 when it displays RTDX data in MATLAB. There is no workaround at this time.
You cannot create a Simulink model that has the same name as any of the
functions in the C62x DSP Library. For example, while using the Vector
Maximum Value block, you get an error if you name your model
maxval.mdl.
When you try to open an old model, such as one you created with the Developer's Kit for Texas Instruments DSP, with the Embedded Target for C6000 DSP 1.0 or 1.1, you may have a problem with Reset blocks. The names of these blocks have changed, and the result is a red outline on the block and the text "Bad link."To fix the broken library link, double-click on the block and change the "Source block" parameter from
c6701evmlib/Reset C6701 EVMto
c6701evmlib/Reset
(replacing C6701 EVM with C6711 DSK if applicable).
The C62x DSP Library block Real Forward Lattice All-Pole IIR (IIRLAT) may not handle initial conditions correctly. There is no workaround for this problem. Always check your results when you use this block.
To run the demo model C6711 DSK-Echo Cancellation you must
have the Fixed-Point Blockset. The model uses the convert block from the
blockset. Note that the Embedded Target for TI C6000 DSP product does not
require the fixed point blockset.
You cannot build models with Embedded Target for TI C6000 DSP if you have the Update Advisor enabled in CCS.
Version 1.1 of this product does not work with Code Composer Studio(r) 2.12.07.You encounter this problem only when
- You have a combined installation of C5000 and C6000 Code Composer Studio Version 2.12.01.
- You own the DSP Starter Kit for TMS320VC5510 and install the patch that upgrades Code Composer Studio 2 ('C5000) Version 2.12.01 to Version 2.12.07.
After you install the patch, your Embedded Target for TI C6000 DSP software does not run properly. Uninstalling the patch usually fixes the problem.
Installing the C6000 and C5000 versions of CCS 2 separately (not combined) should let you upgrade your C5000 installation to support your DSP Starter Kit for TMS320VC5510.
You can generate code, compile, link, and download to a C62x or C67x simulator. However, the code will not execute properly; interrupts are not handled properly.
For some models with atomic subsystems, you may encounter the erroridentifier "STS_Obj" is undefinedwhen you compile the model during code generation. The error comes from a problem in the DSP/BIOS header file inclusion at the top of the source filemodel.h. Preprocessor conditionals prevent the inclusion of sts.h in this file.To fix the problem, move the inclusion of
math.h,string.h,std.h,clk.h, andsts.hdown below the subsequent#endifstatement. You will have to re-do this task each time you generate code for a model. The underlying bug in Real-Time Workshop is planned to be fixed in Release 14.
In Tools -> Real-time Workshop -> Options, under the Target Configuration category, there is a checkbox labeled Generate code only. For the embedded targets, this checkbox is always disabled and cannot be changed. Please disregard the checkbox.To use the Generate code only feature, change the Build action selection as follows:
- Change the RTW Options category to
TI C6000 Runtime.- Change the Build action to
Generate_code_only.This causes the Real-Time Workshop build to place generated code into the project directory without opening Code Composer Studio, and disables target-specific and Code Composer Studio specific options.
In some cases, having a C6701 EVM LED block in your model can cause the codec on the board to fail. This is not a problem in little endian operation. There is no workaround for this problem.
The C6701 EVM LED block provides the option to light only the external LED on the board. When your board is in big-endian mode and you select the external LED, the block lights both the internal and external LEDs.
Some of the demonstration models for the Embedded Target for TI C6000 DSP do not have descriptions available. When you select a demo on the Demo tab in the Help browser, you see only the name of the demo and a link to open the demo. This includes
- Wavelet Denoising demos
- Reverberation demos
- Quick Test demos
- DIP Switch Control demos
When you profile models that contain triggered or constant subsystems, you may encounter an error during TLC. Subsystem timing is not handled properly by the code generation engine in Embedded Target for TI C6000 DSP.
In detail, when you create an atomic subsystem that is contained within a larger atomic subsystem, and the larger subsystem is driven by a FOR iterator, the smaller included subssystem causes an error during code generation. Similarly, when you create a subsystem that is driven by a constant signal, the subsystem causes an error.
To fix the bug, obtain and install the revised filec6000_prof.tlcfrom The MathWorks Web site following the instructions in Solutions, Tips, and Workarounds (SWAT) number 33781 available from the following location: SWAT 33781
Certain vector blocks in the C62x DSP Library, such as Float-to-Q15, do not enforce limits on vector size. Behavior is undefined for vectors larger than 32767 elements. Although there is no known problem with vector sizes up to 2^32, the function prototypes for these functions cite "short" as the data type for the vector-size parameter. The Simulink blocks do not enforce this constraint.
Output oflist(cc,'function')does not include library functions.
Runninglist(cc,'function',libfunc)on the same project returns information about the function specified bylibfunc.
Clicking Inspect Properties to view the
properties of an object in the demonstration program
ccsinspect no longer hangs MATLAB.
The first time you create a link to a C2800 target with CCS V2.12 , you may see one of the following error messages in CCS:"Cannot find ..\cc\gel\f2812_peripherals.gel" "Cannot find ..\cc\gel\f2810_peripherals.gel"To fix this problem, do the following:
- Go to
TI_DIR\cc\geland openf2812.gelorf2810.gel(depending on your target). (TI_DIR is the directory where you installed CCS on your machine.)
- On Line 21 of the
f2812.gelfile for example, find the code:
GEL_LoadGel("..\\cc\\gel\\f2812_peripheral.gel");
Change the relative path to the absolute path. For example:
GEL_LoadGel("TI_DIR\\ti28\\cc\\gel\\f2812_peripheral.gel");
When you run ("Run Program") the ccsfirdemo on a C55x, the filter response does not converge on the first iteration of run (see the plot). However, on the succeeding clicks of "Run Program," expected convergence is observed.In the CCS project, some buffers may not be clean before the filter is run.
When you modify a source file such that you change the line position of a function, creating an object to access the function can causecreateobjto fetch an incorrect string as the function declaration.
This happens because MATLAB, in the process of creating a function object, goes to the source file and extracts the declaration string from the line where the function definition was before your changes. CCS only updates the function line location when you compile and load your program on the target. Therefore, changing the file without recompiling and reloading can result increateobjreturning an incorrect function declaration string.
To avoid getting the wrong declaration string, recompile and reload your project after you make changes to your source code.
To avoid recompiling and reloading, you can pass the correct function declaration to MATLAB using thedeclaremethod.
If you halt the execution of your DSP and modify a local variable's value, the new value may not be acknowledged by the compiler. If you continue to run your DSP, the compiler uses the original value of the variable. This problem happens only with local variables. When you write to the local variable via the Code Composer Studio Watch Window or via a MATLAB object, you are writing into the variable's absolute location (register or address in memory). However, within the function, the compiler sometimes saves the local variable's values in an intermediate location, such as another register or to the stack. That intermediate location cannot be determined or changed/updated with a new value during execution. Thus the compiler uses the old, unchanged variable value.
When creating a MATLAB object for a C28x register variable, an error is thrown:CCS: register float rl_float = -1.234 MATLAB: >> cc = ccsdsp('boardnum',1,'procnum',0); >> x = createobj(cc,'rl_float') Cannot create an object for a C28x register variable. This feature is currently disabled.This feature is currently disabled due to a bug in TI's SDK 2.2. The fix is anticipated in SDK 3.0.
You cannot export cascade or parallel filters to Code Composer Studio. When your current filter in FDATool is either a cascade or parallel filter, the Export to Code Composer Studio menu item is disabled.
For some functions that have a breakpoint at the beginning or starting address, doing
run(ff,...)
or
goto(ff,...)
or
execute(ff,...)
does not execute the function. Instead, the program counter (PC) stays at the breakpoint at the beginning of the function.
MATLAB usually issues a warning that it encountered a breakpoint. You can resume function execution by doing
resume(ff)
If MATLAB does not issue a warning and the PC still points to the function starting address, remove the breakpoint to run the function.
For the C5400, MATLAB Link for Code Composer Studio supports only
None for the compiler Opt Level and compiler
Program Level Opt build options.
On the C6000 family of processors, MATLAB Link for Code Composer Studio supports only theFull DebugandFunction Profile Debugoptions for Generate Debug Info when you build a project. TheDwarf Debug Infooption for Generate Debug Info is not supported.
MATLAB Link for Code Composer Studio supports only theFull DebugorFunction Profile Debugoptions when you use hardware-in-the-loop (HIL) features for the C5400. You cannot build projects that use theDWARF Debug Infoselection for the Generate Debug Info compiler build option and use the HIL features with your C5400.
MATLAB Link for Code Composer Studio hardware-in-the-loop features support only theFull DebugandFunction Profile Debugcompiler build options when you build projects for your C5400 hardware.
You cannot build projects for your C5400 hardware using theNo Debugcompiler option.
On C6000 processors, MATLAB Link for Code Composer Studio hardware-in-the- loop features support only theFull DebugandFunction Profile Debugoptions for building projects on the C6000. TheNo Debugoption is not supported.
On C6000 processors, MATLAB Link for Code Composer Studio supports the default build optionspeed most criticalfor the opt. speed vs. size option. The following selections for opt. speed vs. size are not supported:
speed more critical
speed critical
size critical
size most critical
Using list for getting information about local variables fails when the variable is a static local variable.
When you definefooin Code Composer Studio as:
void foo(void) {
int i_arr;
double r_ccstatus;
static int x_static; /* Static local variable */
...
}
The syntax for querying information about a specific local variable x is as follows:
Create an object in MATLAB to accessfoo:
cc = ccsdsp;
ff = createobj(cc,'foo'); % Function containing static variable x
Now uselistto get information aboutfoo:
info = list(ff,'x_static');
This errors out whenx_staticis a static local variable offoobecause
However, getting information on the global variable
A) Function foodoes not have a record ofx_static. Check through ff.variables (names of all local variables)--you see thatfoodoes not containx_static.
For example:
ff.variables
ans =
'i_arr' 'r_ccstatus'
B) All local static variables are treated by the compiler as globals. x_static, as follows :
list(cc,'globalvar','x_static')
is not recommended because there can be more than onex_staticin the symbol table (x_staticmay be defined in some other functions). Distinguishing thex_staticof interest from the rest is not possible through the interface.
Methodscastandconvertreturn incorrect objects when casting/converting to/from a pointer to a pointer(s).
Example: >> x = createobj(cc,'g_vptr') POINTER Object stored in memory: Symbol name : g_vptr Address : [ 2147501804 0] Word size : 32 bits Address units per value : 4 au Representation : unsigned Size : [ 1 ] Total address units : 4 au Array ordering : row-major Endianness : little Pointer data type : void * >> convert(x,'int **') POINTER Object stored in memory: Symbol name : g_vptr Address : [ 2147501804 0] Word size : 32 bits Address units per value : 4 au Representation : unsigned Size : [ 1 ] Total address units : 4 au Array ordering : row-major Endianness : little Pointer data type : int * >> x_new = cast(x,'int **') POINTER Object stored in memory: Symbol name : g_vptr Address : [ 2147501804 0] Word size : 32 bits Address units per value : 4 au Representation : unsigned Size : [ 1 ] Total address units : 4 au Array ordering : row-major Endianness : little Pointer data type : int *
The 'multiproctutorial' demo errors out due to timing issues when used with CCS 2.2. This is due to a bug in CCS 2.2 for OMAP. This problem occurs only when using the OMAP simulator.Reproduction steps through the CCS IDE:
- Configure your OMAP CCS 2.2 to set up the OMAP simulator.
- Open CCS and load a program on either C55x or R2x processors. Go to Debug->Go Main. (This action takes a very long time)
For
- CCS version: 2.2
- Processor: C55x simulator
- Registers: RSA0, RSA1, REA0, REA1
reading from and writing to the above-listed registers, gives incorrect results. This is a bug in CCS 2.2.
Register variables are often hard to figure out because the registers that hold the variables are not dedicated to storing just the variable value. Digital signal processors use registers as temporary storage locations anytime during execution. When this occurs, the executing program stores the value of the variable somewhere in the stack and returns it to the register later.
Hence, getting the values of register variables during intermediate times may give unexpected values. Likewise, values that you write to register variables during intermediate times may not get reflected.
Note--This is true for any local variable.
One way to test this is to write a line of code that uses the variable and see if the result remains consistent.
Example:
register int a = 100;
int b;
...
b = a + 2;
Reading the register assigned toaprobably returns the correct result but ifbgives the expected 102 sum, nothing is wrong with your code or the link. In this case the register is behaving as it should.
Before you run demonstration models on ARM/TMS470Rxx processors, your Code Composer Studio (CCS) configuration must meet two requirements:
- The CCS memory mapping must be correct
- The CCS settings must match the memory mapping of the demonstration project
Before running any demo on the TI TMS470Rx CPU, do the following in CCS:
- Start Code Composer Studio.
- Select Option->Memory Map... on the CCS menu bar. The Memory Map dialog opens with the Memory Map tab active.
- For Starting Address, enter
0x20.- For Length, enter
0x7FFE0.- From the Attributes list, select
RAM - Read and Write.- Check the Enable Memory Mapping option.
- Click Add.
- Click Done to close the dialog.
Close CCS and you are ready to run the demos on your TMS470xx target.
The time-out value for therunmethod in the function class can be modified only by changing the function objecttimeoutproperty value.
To demonstrate changing the timeout property value:
cc = ccsdsp;
ff = createobj(cc,'foo') % Object for functionfoo
run(ff) % timeout defaults to 10 secs
To makerunstop after 20 secs, set thetimeoutproperty value to 20:
set(ff,'timeout',20); % This time-out value now applies to all methods
run(ff);
ff.timeout = 10; % Restore default timeout value
For some C55x register non-16-bit variables (float, double, long, long long),createobjis unable to create a valid Register object and throws an error. This is due to the fact that the compiler sometimes assigns these variables to 16-bit registers. Since the wordsize and the register size are inconsistent, the object cannot be created.For example:
CCS: register float rl_float; MATLAB: >> x = createobj(cc,'rl_float') ??? Error using ==> ccsdsp/createobj (C55xBugCheck) Unable to create a valid register object for variable 'rl_float'.
Once a table has been added to a Tradeoff Calibration study, changing its properties from elsewhere, for example by changing the table size in the Calibration Manager, may cause an error in CAGE. To avoid the error first delete the Tradeoff, then edit the table and then construct a new Tradeoff using the changed table.
If you create a new function model that contains a power or multiply operator, it may incorrectly return an error telling you that it cannot parse the function. As a workaround, enter the function using MATLAB's element-wise operators (for example ".*" instead of "*").
When you edit values in the Output column of a Normalizer table, the table will constrain the value you type to be displayed as an integer. However it does not correctly constrain the value that is saved internally, so the accompanying graph is updated to show the typed value. Normalizer outputs should be constrained to be integers, so typing in a non- integer value may lead to errors in CAGE. The Normalizer graph, which can also be used to edit the breakpoints, correctly constrains the saved value to be an integer.
When you view a normalizer from within a feature that is being filled using a "Feature Model", MBC will error if the normalizer comparison pane is open. To prevent errors, keep the normalizer comparison pane closed while looking at these normalizers.
Printing and copying from the Surface Viewer does not work correctly if you have used the table view. You can use this workaround: shut down and restart CAGE and then reopen the surface viewer.
In Version 5.x, when Building a Subsystem (right-click command) that has continuous sample time and inherited sample time, any Step Size set by the user in the Simulation Parameter Solver dialog will fail to be honored. Instead, the default step size (stop time / 50) is used. This problem does not occur when building the entire model.
If you attempt to close a model during while Real-Time Workshop is generating code or the code is beig compiled, unpredictable things may happen, up to and including segmentation violations. We plan on addressing this issue for the next release, but when using the current release and all prior releases, please do not close a model while a build is in process.
The Real-Time Workshop User’s Guide section “DSP Processor Support” on p. 14-107 contains obsolete information, and should instead read as follows:DSP targets may use registers with sizes other than 32 bits and vary in their saturation and overflow behavior. These characteristics are specified by target-specific hookfiles, which are provided for all targets supplied by The MathWorks. Users may create their own hookfiles for custom targets. The contents and naming of hook files are described in "Targeting Real-Time Systems: Components of a Custom Target Configuration: Control Files: Hook Files for Communicating Target-specific Word Characteristics" on page 14-7 of the Real-Time Workshop User's Guide. The
%assign DSP32=1command to the system target makefile and the- DDSP32=1command to the template makefile that formerly handled DSP targets have been deprecated and no longer have any effect.
The Rapid Simulation (RSIM) Real-Time Workshop target now has a timeout execution option. Use this option to enable the RSIM executable to abort if it is taking excessive time. This can happen, for example, in some models when zero crossings are frequent and minor step size is small.To cause an executing RSIM to timeout after
nseconds, use the-Lcommand line option followed byn. For example, suppose you created an RSIM executable for the vdp demo; you can run the executable as follows:vdp -L 20After vdp (or vdp.exe) executes for 20 seconds the following will happen.On PC platforms, the program will terminate with the message:
Exiting program, time limit exceeded Logging available data ...On Unix platforms the message will be** Received SIGALRM (Alarm) signal @ Fri Jul 25 15:43:23 2003 ** Exiting model 'vdp' @ Fri Jul 25 15:43:23 2003You do not need to do anything to your model or its Real-Time Workshop configuration to use this feature. However, you must generate the RSIM executable using Version 6.0 or later of Real-Time Workshop for the-Lflag to be recognized.
Page 9 of the shipped version of Real-Time Workshop 5.0 Release Notes indicates that in generated code,model_private.his sub- included bymodel.h. This is incorrect;model.hdoes not includemodel_private.h.The section "Application Modules for Application Components" on page 7- 33 of the Program Architecture chapter of the Real-Time Workshop documentation also incorrectly states that
model_private.his sub-included bymodel.h.On page 2-9 of “Getting Started with Real-Time Workshop” the section “Building an Application: Summary of Files Created by the Build Procedure” also incorrectly states that
model.hincludesmodel_private.h. The diagram of file inclusions in Figure 2- 12 on page 2-50 is correct, however.
When code is generated for the Look-Up Table 2-D or Look-Up Table 1-D block for floating-point parameters with binary search, extrapolation, and linear interpolation selected, the number and position of repeated zeros is generated explicitly into the generated code. If the breakpoint parameters are then tuned in the real-time code during execution and the number or position of repeated zeros changes, the generated code will in most cases get an incorrect answer when the input for that breakpoint set is near zero.The workaround is to avoid this problem, do not change the number or position of reapated zeros in breakpoint parameters for the Look-Up Table 1-D and Look-Up Table 2-D blocks.
Under Compiler Options on page 9-45 of the Real-Time Workshop Users Guide for Version 5, the following tip is given: "If you do not require double precision for your application, definereal_Tas float in your template make file, or you can simply specify-DREAL_T=floatafter make_rtw in the Make command field."This documentation is not correct. Various circumstances (such as the presence of literal constants) can cause this strategy to fail to remove all doubles from the generated code. The only reliable way to be sure that doubles are absent is to formally propagate single-precision signals in the Simulink model.
Change in tlc invocation, providing full path to model file rather than relative path, creates backwards incompatibility in some custom targets. When migrating Release 13 targets to Release 14, their use of TLC's TLCFILES to determine context, such as the path to the model file, may be affected by this change.