List of Resolved Bugs
Bug ID: #060119301
Submitted by: Joakim Tysseng
Severity: Major (5.0.0.0, 5.0.0.1, 5.0.0.2 )
Status: Resolved, since version 5.0.0.3
Description:
Defintion of local constant causes wrong address assigments for
local variables located in same function as local constant. In most cases
it will produce strange program behaviour.
Workaround:
Don't use local constants. Use global constants or
#define to avoide this bug.
-
Submitted by: Joakim Tysseng
Severity: Major (5.0.0.0, 5.0.0.1, 5.0.0.2 )
Status: Resolved, since version 5.0.0.3
Description:
Defintion of local constant causes wrong address assigments for
local variables located in same function as local constant. In most cases
it will produce strange program behaviour.
Workaround:
Don't use local constants. Use global constants or
#define to avoide this bug.
-
Last edited by pizon on 14 Feb 2006 10:02, edited 1 time in total.
Bug 070528010: float compare in complex expression
Bug ID: #070528010
Submitted by: Rainer
Severity: Mayor, pic16/18 family, mikroC 6.2.1.0 and older
Status: Solved (from version 7.0.0.3)
Description:
Routines for floating point comparing (<, >, >=, <=, ==, !=) used in complex expressions such as
will not return expected values.
Note: In this case, complex expression are considered to be expression in which there is more than one function call (either system (implicitly called by compiler) or other explicit function calls made by user). All floating point operators are implemented as system functions. Only floating point compare operators are affected by this bug, all other operators will work. So, do not use them in complex expressions such as above.
Workaround:
Brake complex expressions in a number of simple expressions which do not have more than one function call as described above. Also, compare result variables, if there are any, should be declared as volatile. Here is an example:
Submitted by: Rainer
Severity: Mayor, pic16/18 family, mikroC 6.2.1.0 and older
Status: Solved (from version 7.0.0.3)
Description:
Routines for floating point comparing (<, >, >=, <=, ==, !=) used in complex expressions such as
Code: Select all
float __value;
char res;
...
res = __value < 1.00001 | __value > 10.00001;
...
Note: In this case, complex expression are considered to be expression in which there is more than one function call (either system (implicitly called by compiler) or other explicit function calls made by user). All floating point operators are implemented as system functions. Only floating point compare operators are affected by this bug, all other operators will work. So, do not use them in complex expressions such as above.
Workaround:
Brake complex expressions in a number of simple expressions which do not have more than one function call as described above. Also, compare result variables, if there are any, should be declared as volatile. Here is an example:
Code: Select all
float __value;
volatile char res;
...
res = __value < 1.00001;
res |= __value > 10.00001;
...
Bug 070523100: Changing from BANK 1 to BANK 3 (P16 familly)
Bug ID: #060402000
Submitted by: JPayne
Severity: Mayor, pic16 family, mikroC 6.2.1.0 and older
Status: Solved (from version 7.0.0.3)
Description:
Bug is related to changing from BANK 1 to BANK 3 all other cases works.
Workaround:
is to either access some variable that is located in another bank than bank 1 before accessing vars from bank 3 or
simply add
infront of use of vars in bank3 which will force setting correct bank like this
Submitted by: JPayne
Severity: Mayor, pic16 family, mikroC 6.2.1.0 and older
Status: Solved (from version 7.0.0.3)
Description:
Bug is related to changing from BANK 1 to BANK 3 all other cases works.
Workaround:
is to either access some variable that is located in another bank than bank 1 before accessing vars from bank 3 or
simply add
Code: Select all
asm nop;
Code: Select all
asm nop;
ANSEL = 0;
Bug 060402000: Optimizing if of type: if(0x80 & y)
Bug ID: #060402000
Submitted by: dcanoi
Severity: Minor, pic16/18 family, mikroC 6.2.1.0
Status: Solved
Description:
Bug is related to optimizing if :
bug will manifest only in case
x is literal constant and x is power of 2 i.e. ( x = 0x80)
and x must be first operand of & operation
Bug is located and fixed. This fix will be included in next release
workaround:
use constant that is power of two as second operand in relation expressions.
-
Submitted by: dcanoi
Severity: Minor, pic16/18 family, mikroC 6.2.1.0
Status: Solved
Description:
Bug is related to optimizing if :
Code: Select all
if(x & y)
x is literal constant and x is power of 2 i.e. ( x = 0x80)
and x must be first operand of & operation
Bug is located and fixed. This fix will be included in next release
workaround:
use constant that is power of two as second operand in relation expressions.
-
Bug 060306300: pic16 interrupt problem
Bug ID: #060306300
Submitted by: Zristic
Severity: Mayor, pic16 family only, mikroC 5.0.0.0 to 5.0.0.3
Status: Solved
Description:
In some cases for pic16 family, saving and restoring PCLATH in the interrupt, can be corrupted. This happens if complex expression causes extending local frame for interrupt. It can be seen in assembly by finding instruction that saves PCLATH, which will not have argument (i.e. MOVWF <empty string> ). Programs that have this kind of problem will most probably freeze on hardware so it will be easy to identify.
Workaround:
Find in assembly which instructions need extension of the local frame (search for appearence of string FLOC_interrupt) and simplify (brake in several steps) them in your C code. To verify that PCLATH is properly saved search for MOVWF ?savePCLATH in your interrupt routine assembly.
-
Submitted by: Zristic
Severity: Mayor, pic16 family only, mikroC 5.0.0.0 to 5.0.0.3
Status: Solved
Description:
In some cases for pic16 family, saving and restoring PCLATH in the interrupt, can be corrupted. This happens if complex expression causes extending local frame for interrupt. It can be seen in assembly by finding instruction that saves PCLATH, which will not have argument (i.e. MOVWF <empty string> ). Programs that have this kind of problem will most probably freeze on hardware so it will be easy to identify.
Workaround:
Find in assembly which instructions need extension of the local frame (search for appearence of string FLOC_interrupt) and simplify (brake in several steps) them in your C code. To verify that PCLATH is properly saved search for MOVWF ?savePCLATH in your interrupt routine assembly.
-
Bug 060216302: Violation on removing file from project
Bug ID: #060216302
Submitted by: Strannik
Severity: Minor
Status: Waiting
Description:
If you try to remove the single file from project (with right click on the file from the list located in the "Project Summary" tab) and then change your mind (click "No" on confirm dialog box), the IDE throws Access Violation Exception. The application continues to work normally after that.
This is an IDE bug that is annoying, but does not cause any damage.
Workaround:
None.
-
Submitted by: Strannik
Severity: Minor
Status: Waiting
Description:
If you try to remove the single file from project (with right click on the file from the list located in the "Project Summary" tab) and then change your mind (click "No" on confirm dialog box), the IDE throws Access Violation Exception. The application continues to work normally after that.
This is an IDE bug that is annoying, but does not cause any damage.
Workaround:
None.
-
Bug 060216301: incorrect handling of signed's in structures
Bug ID: #060216301
Submitted by: bruno
Severity: Moderate
Status: solved
Description:
In some situations, signed variables in structures and unions are treated as unsigned, which can affect the results of arithmetic operations.
Workaround:
Declare all such variables explicitly as signed, in order to force the signed operation execution. For example:
-
Submitted by: bruno
Severity: Moderate
Status: solved
Description:
In some situations, signed variables in structures and unions are treated as unsigned, which can affect the results of arithmetic operations.
Workaround:
Declare all such variables explicitly as signed, in order to force the signed operation execution. For example:
Code: Select all
struct TestStruct {
signed int sInt1;
signed short sShort1;
unsigned uInt1;
...
};
Bug 060214301: Faulty negative integer division
Bug ID: #060214301
Submitted by: bruno
Severity: Moderate (5.0.0.0 - 5.0.0.3)
Status: Waiting
Description:
Division of an integer by second integer which is the power of two, results in rounding down the result for negative values (towards -infinity), instead of doing it upwards (towards zero). E.g. -5/2 will give the result -3, instead of -2.
Workaround:
Declare divisor as volatile variable, this will prevent the compiler to perform optimisations on it and impose proper division results.
-
Submitted by: bruno
Severity: Moderate (5.0.0.0 - 5.0.0.3)
Status: Waiting
Description:
Division of an integer by second integer which is the power of two, results in rounding down the result for negative values (towards -infinity), instead of doing it upwards (towards zero). E.g. -5/2 will give the result -3, instead of -2.
Workaround:
Declare divisor as volatile variable, this will prevent the compiler to perform optimisations on it and impose proper division results.
-
Bug 050610301: Terminal tool - incorrect >=57600 bps
Bug ID: #050610301
Submitted by: T. Kuroki
Severity: Moderate
Status: Solved
Description:
The (serial port) Terminal tool generates incorrect baud rates >= 57600 bps:
Workaround:
Use some third-party tool for the effected baudrates until the problem gets solved.
Note:
This is a tool bug, and is therefore present in all mikroe's compilers
-
Submitted by: T. Kuroki
Severity: Moderate
Status: Solved
Description:
The (serial port) Terminal tool generates incorrect baud rates >= 57600 bps:
Code: Select all
selected actual
----------|--------------|
57600 | 115200 |
115200 | 128000 |
128000 | 256000 |
256000 | 256000 |
Use some third-party tool for the effected baudrates until the problem gets solved.
Note:
This is a tool bug, and is therefore present in all mikroe's compilers
-
Bug 050526301: debugger crashes when manipulating the PCL
Bug ID: #050526301
Submitted by: gambrose
Severity: Moderate
Status: solved
Description:
Manipulating the PCL (Program Control) register directly from code results in faulty debugger behaviour.
This bug is related to the Debugger tool, both for PIC16 and PIC18 families.
Workaround:
None.
-
Submitted by: gambrose
Severity: Moderate
Status: solved
Description:
Manipulating the PCL (Program Control) register directly from code results in faulty debugger behaviour.
This bug is related to the Debugger tool, both for PIC16 and PIC18 families.
Workaround:
None.
-
Bug ID: #07003008
Submitted by: Grezco
Severity: Minor(affects mikroC v7.0.0.3 )
Status: solved from v8.0.0.0
Description:
Configuration flag PBADEN was not updated correctly.
Workaround:
Download new definition file from the link below:
new 18F2553 def
Submitted by: Grezco
Severity: Minor(affects mikroC v7.0.0.3 )
Status: solved from v8.0.0.0
Description:
Configuration flag PBADEN was not updated correctly.
Workaround:
Download new definition file from the link below:
new 18F2553 def
Bug ID: #07003007
Submitted by: bruno
Severity: Mayor (affects mikroC v7.0.0.3, pic18 family )
Status: solved from v.8.0.0.0
Description:
Using table read/write PIC18 operations may cause malfunction when used from main loop and from interrupt at the same time
The reason is the registers TBLPTR[U:H:L] and TABLAT are not saved during ISR.
Workaround:
Save these registers yourself in interrupt. See the example code below.
Submitted by: bruno
Severity: Mayor (affects mikroC v7.0.0.3, pic18 family )
Status: solved from v.8.0.0.0
Description:
Using table read/write PIC18 operations may cause malfunction when used from main loop and from interrupt at the same time
The reason is the registers TBLPTR[U:H:L] and TABLAT are not saved during ISR.
Workaround:
Save these registers yourself in interrupt. See the example code below.
Code: Select all
void interrupt()
{
unsigned char a, b, c, d ;
a = TBLPTRL ;
b = TBLPTRH ;
c = TBLPTRU ;
d = TABLAT ;
// your code here...
TBLPTRL = a ;
TBLPTRH = b ;
TBLPTRU = c ;
TABLAT = d ;
}
Bug ID: #07003006 Configuration flag XINT_OFF
Bug ID: #07003006
Submitted by: yo2lio
Severity: Minor(affects mikroC v7.0.0.3 )
Status: solved from v.8.0.0.0
Description:
Configuration flag for disabling extended instruction set (XINT_OFF), in pic18f1230 and pic18f1330 definition files, had a wrong value.
Workaround:
Download new definition files at the link below.
http://mikroe.com/srdjan/p18f1230_1330_Cdefs.rar
Submitted by: yo2lio
Severity: Minor(affects mikroC v7.0.0.3 )
Status: solved from v.8.0.0.0
Description:
Configuration flag for disabling extended instruction set (XINT_OFF), in pic18f1230 and pic18f1330 definition files, had a wrong value.
Workaround:
Download new definition files at the link below.
http://mikroe.com/srdjan/p18f1230_1330_Cdefs.rar
Bug ID: #07003005 Initialization of structures
Bug ID: #07003005
Submitted by: Pierre
Severity: Minor(affects mikroC v7.0.0.3 )
Status: solved from v.8.0.0.0
Description:
Initialization of structures with incomplete list of initializers
can cause that larger part of RAM will be filled with zeros.
Workaround: Specify full list of initializers for structure
-
Submitted by: Pierre
Severity: Minor(affects mikroC v7.0.0.3 )
Status: solved from v.8.0.0.0
Description:
Initialization of structures with incomplete list of initializers
can cause that larger part of RAM will be filled with zeros.
Workaround: Specify full list of initializers for structure
-