14 March 2006
Run setup.exe
From one of our customers we received a sample case that asserts with S003. The assert seems to have a sensitive nature meaning that it may assert when executed from a make file but when executing this same dependency from the command line it may not. Another sensitive aspect is that the concerning module can very difficult be reduced to a smaller example. As soon as you start stripping it vanishes. Even when moving around functions within the same module it disappears.
EXAMPLE:
To large to show here
WORKAROUND:
Because of its sensitive nature moving around functions appears to do the trick. But also disabling mixed C/assembly sometimes works or disabling debug information.
The sample source when compiled with:
c563 -Cc a.c
Asserts with:
c563 F039: a.c: line 1: unknown error number: 573
EXAMPLE:
_callee_save void g(void)
{
}
WORKAROUND:
Error message 573 is not recognised but what it means is that there are conflicting parameter passing protocols for 'g'; (1) -Cc on the command line and (2) _callee_save on the command line. As it can either be one or the other you must make a choice and the error will go away.
Referring to the sample source the currently generated assembly can be reduced to the following:
move x:Fu,y0 move x:Fi,x0 mpysu x0,y0,b asr b move b10,l:Fl
EXAMPLE:
int i;
unsigned u;
_L long l;
void f(void)
{
l = (long)u*i;
}
WORKAROUND:
None.
The sample source locks in the inner loop. Within this loop 'a' is never incremented. The runtime error is in a sense forwarned by the following warning from the command line:
c563 W132: a.c: line 11: value of variable "a" is undefined
EXAMPLE:
char c;
void main (void)
{
char *a;
char *b;
b=&c;
while (b)
{
a = b++;
for (;a<b;a++)
{
_nop();
}
}
}
WORKAROUND:
Disable hardware do-loop optimization.
The peephole optimizer fails. The following assembly code
move a,b cmpm y0,b b,a
is incorrectly optimized to
cmpm y0,b a,b
Correct output should be:
move a,b cmpm y0,b
or even better:
cmpm y0,a b,a
EXAMPLE:
Too large to reproduce here.
WORKAROUND:
Disable peephole optimizer:
(1) #pragma optimize Y (source level)
(2) -OY (command line level)
Our USB execution environments (SB-USB,USB-EMU) are comparatively slow to other execution environments. This can be visually observed by single stepping an example program using first SB-USB and next either EVM (or Parallel) as the execution environment. EVM will be visually faster. Another thing that may be observed is that using "run to cursor" between consecutive lines is visually faster than a single step. This suggests that it should be possible to increase the speed of single stepping while using the USB execution environments.
EXAMPLE:
None.
WORKAROUND:
None.
The debug instruction can only be stepped while using the parallel or simulator execution environment. All other environments lock in endless loop.
EXAMPLE:
None.
WORKAROUND:
None.
Command:
xfw56x -RegServerdoes not properly register CrossView Pro is a COM server. This is confirmed by the python examples of m_xvw68.pdf. They will throw an exception:
Is the xfw56x COM object installed, using xfw56x.exe -RegServer?Since the answer is 'yes' the registration must be incomplete.
EXAMPLE:
None.
WORKAROUND:
CrossView Pro is correctly registered as a COM server, but it uses an incorrect Application Id to register itself. As a workaround, the Application Id "Unknown" can be used.
The sample source when compiled as below:
cp563 a.cpp
Will not pre-process the given #error directive because the predefined macro _CP56 does not exist. It used to exist in older versions.
EXAMPLE:
#ifdef _CP56 #error "_CP56 has been predefined!" #endif
WORKAROUND:
Use:
cp563 --define=_CP56 a.cpp
Copyright 2004-2006 Altium BV