Known Bugs and Limitations

- The integrated timers are not working when the target is free running. The workaround (when you want to get a code traversal time) is to single step across the code sections of interest.

- In script command files, if a save_trace_buffer(); script commmand is followed by an exit(); script command then the save_trace_buffer(); is ignored. The work-around is to place a wait_time(); script command in between.

- In script files, strings are not handled correctly in all cases. For instance, this works print_to_trace("simple string"); but this does not work print_to_trace("three " "piece " "string");

- In the trace window and trace files there are a number of issues, as follows:

- If "continuous trace to file" is on, and everything is selected, the simulation progresses so slowly that the application appears to be frozen (update is way too slow.)

- A phantom READ appears on 24 and 8 bit Writes.

- All writes (24/8/32) appear as 32-bit.

- Enabling/Disabling of saving PRINT_TO_FILE(); scripts is neither supported, nor documented in the user manual.

- The trace-parcer is not yet available on our website.

- Probably other stuff wrong with the TRACE stuff. Smoke-->Usually-->Fire.

- When generating and testing using Behavior Verification, the number the buffer that holds the pin transition data can hold duplicate data, and duplicate data can cause tests that might otherwise pass to fail, resulting in false failures (but not false passes, phew.) The problem is that the pin transition data buffer is also holding thread transition, match transition, and other data. When these events occur, extra data is saved to the buffer. The fix is to disable all extraneous data from getting saved to the buffer. This is done by going into the Logic Analyser Settings dialog box and de-selecting pretty much everything. Close and open the simualtor and this new setting will then be saved.

- If the target is running, and a breakpoint is toggled, the breakpoint will never be able to be properly removed. Also known as the "mother-in-law" bug.

- In the watch window, if a floating point number is editted (for instance 1.5) with an integer (for instance 1 ... not having a decimal point in the edit) then the edit results in a bizarre number being written into that variable

- If the eTPU is free-running, and a source code window is closed (because the user does not want to view that source code window) and a screen update occurs when the PC is in an address inside that file's source code, then the source code window is automatically openned, even thought the user probably did not want it to be open (because the user had it closed) Source code windows should only be automatically openned as a result of a single step, thread-step, etc, where there is clear intent by the user to view that file.

- Use of the the following #define in a script command closes the simulator.

#define TRANSMISSION_ADDR ETPU_DATA_SPACE, TRANSMISSION_ADDR, 0xffffff

- Source code breakpoints are disabled following a "load_executable" script command
are are not re-enabled unless the simulator is halted, then restarted.

- Breakpoints in ISR script command files are not working.

- Test vector files with multiple "Wave" commands will sometimes ignore the
_SECOND_ wave command. E.G. in the following two-wave command the second
one (the one that drives the input pin) is ignored. (N:\ETpuCode\BugsSim\VectorDither)

// Set up the tcrclk input waveform
wave tcrclk (ONE 10 ZERO 20) 3
end

// Set up the input Pin waveform
wave InputPin ZERO 5000 (ONE 1000 ZERO 10000) *
end

WORKAROUND: Reload the vector file at the _BEGINNING_
of your script command, as per the following example.
vector("Lab6.vector");

- Test vector files sometimes generate waveforms that are off by instruction step
(20 ns at 100 MHZ)
(N:\ETpuCode\BugsSim\VectorDither)

- In certain cases, a script command file parse error
(due to a problem in the script command file) gives an errant "Diagnostic"
error message instead of the correct message
[ASH WARE: See: [BugsSim]\\ScriptParseErrorCausesDiagnosticError

- Cannot initialize the 'initialized global variables' using the values
defined in the .C file. So you have to fake it by using the address
only and duplicate in the script command the initialized value.

- When TRR==0, angle ticks are very fast (It should be very slow) ref=GRH,2004-08-25

- Negative numbers extend to 32-bits (instead of 24-bits) in eTPU Scripting language!
e.g.:
verify_chan_data24(QD_PHASE_A_CHAN, ETPU_QD_DIRECTION_OFFSET, -1);
The '-1' extends to 0xffffffff,
instead of 0xffffff.
and since 0xffffff is out of range for a 24-bit number this gives a warning.

WORKAROUND:
Mask the top bits, as follows
verify_chan_data24(QD_PHASE_A_CHAN, ETPU_QD_DIRECTION_OFFSET, (-1) & 0xffffff );

- Need variable width script command for accessing channel data ... as follows
write_channel_data(Chan, ByteOffset, numBits, width);
verify_channel_data(Chan, ByteOffset, numBits, width);

- WEIRDNESS: There are many "extra" data points in the .BV file.
This is because data is saved on transitions of things like, "HALT MODE".
But since "HALT MODE" is not a pin, it is not being saved to the file.
[Eventually we will fix this weirdness, but probably not too soon.]

- When running a Behavior Verification test, the "Log Options" specified
in the "Logic Analyzer Options ..." dialog must MATCH EXACTLY the options
specified when the .BV file was generated. When run with mis-matched options
than an errant pin transition verification error will be reported and the test
which otherwise might have passed will fail.

- Currently when running a series of regression tests from a batch file
the eTPU simulator expands to cover the full screen every time it is launched.
This prevents the tester from playing meteors while the tests are running.
Instead, when run in auto-run mode, it should retain its
minimized/maximized/normal from the last time auto-run was run.

- Hit count for ALL conditionals in a breakpoint must be IDENTICAl for the
complex breakpoint to work. Otherwise it will never trigger.

- Complex breakpoint conditional dialog box is not complete.

- Coming out of "IDLE' the "TST" appears to be 4-clocks, which is wrong,
when it should be 6.
Note that going immediatly from one thread to another (with no idle) the
TST appears to be 6-clocks which is correct.

- Structure support not working in almost all cases.
Symbol support missing from compiler-generated symbol table.

- Symbol write and symbol verify script commands are not working.

- Parts of the Source Code File are not visible in the source code
window in some cases. This relates to a limitation of the simulation
framework in which only 2000 lines can be visible. The specific
problem occurs when the total number of lines in a mixed-mode view
(source + asm) exceeds 2000. The simulator is supposed to keep visible
all the source, and as many of the dis-asm lines as possible.
Instead, the window is truncating both source and dis-asm.

- A "relative" path to the compiler's path can result in a simulator bug.
For instance, the following path may give an error:
..\Lib\
WORKAROUND:
Use "absolute" fully specified path, as follows:
L:\BaseDir\Lib\

- The Coherent Dual-Parameter Controller (CDC) is not implemented

- Red Line bus is not working correctly (Metrowerks platform only)

- Code Coverage is not working properly.
-> GUI is not differentiating between branch & non-branch
-> Probably more (smoke-->fire)

- <Ctrl-V> (used for reloading vector files)
and <Ctrl-X> (used for reloading source code
conflict with standard windows hot-keys for cut & paste.

- User manual section on Complex Breakpoints is not complete

- User Manual section on logic analyzer is wrong and does not include
discussion on thread groups or new button graphics.

- The "@nodename" syntax for defining the referenced
channel in a channel frame symbolic reference is failing when
the nodename references an output channel/pin on the eTPU.