WARE

• 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.

• 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.

• 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

• 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);

• 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.  Note that the workaround is to use the command line version of mtdt, mtdt_cl.exe.

• 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.

• Symbolic debugging of ByteCraft .cod files lacks structure/tag type support.

• 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)

• 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.

​