Constant variables placed on an absolute address are not accessible in the default memory model. Use the option --place_const_in_code to make them accessible.
The calling convention has changed in version 2.30 to allow for more efficient code generation. More information can be found in the IAR C Compiler Reference Guide for MAXQ.
Constant data placed in the applications CODE segment must be placed in the 0x0-0x7FFF address range. The compiler generates calls to utility ROM functions to access constant data efficiently, and these calls cannot access addresses beyond 0x7FFF.
EW23014: Only 8- and 16-bit accesses to volatile variables are atomic.
This dependency on the state of the 17th bit means that when servicing an interrupt, the pointer must be saved in both byte and word format to be restored correctly in all 17 bits. The problem is that the integrated debug engine in the MAXQ core does not restore all bits of the pointer registers it uses. The debug engine can change the invisible bit, as it only saves the pointer register values in the current pointer mode in the interrupt context save. This can cause unexpected behavior because the compiler runtime model relies on the contents of the invisible bit.
The corrections below refer to the PDF version of the user guide MAXQ IAR C Compiler Reference Guide. The information in the PDF file is, in the event of any differences, more accurate than the printed reference guide and the online help files.
When generating code for devices using the MAXQ68 core, the compiler will always assume that DP[0] is a byte pointer, and that DP[1] is a word pointer. It is important for developers using assembly code to follow this convention, as interrupt service routines can otherwise accidentally use incorrect addressing modes to access pointers.
Page 88 of the IAR C Compiler Reference Guide for MAXQ erroneously lists DPC as a scratch register. The DPC register must be preserved across function calls.
EW16713: The #pragma pack (1) directive is not supported by the compiler.
The intrinsic functions __get_interrupt_state() and __set_interrupt_state() now operate on the IC register GIE bit instead of the IMR register, which is only available on MAXQ20 cores. The __get_interrupt_state() function will return the contents of the IC register. Only the least significant bit is used by the __set_interrupt_state() function, so only the GIE bit is affected.
EW25465: Absolute address placed constant data with 2-alignment would not be accessed correctly on the MAXQ68 core.
EW24567:When the HW multiplier was used the compiler did not preserve the value of the DPC register. This has been corrected.
There was a problem with stack frames larger than 510 bytes when the MAXQ68 core was used. This has been corrected.
EW23092: The compiler could crash during high level optimizations.
EW23093: Bit definitions for the MAXQ7667 Analog Power Enable Register has been corrected.
EW23016, EW23015: Interrupt exit code generated for MAXQ20 device no longer result in stack imbalance.
EW22516: The files intrinsics.h and iomacro.h are no longer missing from the evaluation and Kickstart version of the product.
An issue that could cause stack corruption when calling functions from ISRs has been corrected.
On high and medium optimization levels, the compiler would sometimes generate bad code for variable increments inside of do-while loops. This has been corrected.
EW18865: The watch window in C-SPY could sometimes display incorrect const values. This has been corrected.
EW19123: The compiler now issues a warning when an explicit cast of a pointer from a byte-type to a word-type can cause unexpected side effects due to word alignment issues.
Code size optimizations for MAXQ61x devices has been improved.
The routines for ISR context save/restore handling for MAXQ61x devices has been corrected.
The device support headers and linker configuration files for MAXQ61x devices has been updated.
The stack pointer (SP) now gets initialized properly when compiling code for MAXQ61x devices.
EW20716: The compiler will now issue a warning if an unaligned read to __io space is attempted, as well as an error if an unaligned write is attempted to the __io space.
EW20717: The prototype of the fabs() function has been corrected in the intrinsics.h file.
Atomic bit access to registers is implemented via the bitop instruction. [EW19124]
Interrupts are now disabled during hardware multiplier operations. [EW17834]
Access to the upper 8 bits in a 16-bit bitfield would generate a Tool Internal Error message. A proper error message has been created. [EW18539]
If available for the selected device, the hardware multiplier is now enabled by default when setting up a new project.
The default linker configuration files have been updated to include missing Utility-ROM functions.
The Override inherited settings option in the editor now works as expected. [EW19414]
The value of __SUBVERSION__ has been corrected. [EW19412]
Handling of un-handled interrupts has been improved. [EW19125]
Corrected a problem when a jump table was placed in the upper half ( 32k x 16 ) of code space. [EW19410]
Corrected a problem with va_arg returning the wrong value. [EW19122]
Corrected a problem with bad list file output. The compiler generated bad code for bit tests in SFRs for bit numbers 8-15. In code such as if(SFR&0x1000), bit 4 would be tested instead of bit 12. [EW19413]
2.11F
User guide corrections
The correction below refers to the PDF versions of the reference guide MAXQ IAR C Compiler Reference Guide, CMAXQ-4. The information in the PDF files is, in the event of any differences, more accurate than the printed user guides and the online help files.
2.12
asm("Loop: MOV A, @R0 \n" "
DEC R1 \n" "
DJNZ R1,Loop ");
Note that the instruction separator is '\n' and that the definition and the
reference of a local label do not necessarily need to be in one asm().
Not all combinations of memory models are recommended. The best choises depends on the available data memory. If there is enough RAM, the default combination large code model, large data model and constants in data is the most profitable. If the const data area is too large to fit in RAM, try the --code_model=s and --place_const_in_code.