This patch updates the C166/ST10 v8.5r1 product. It includes all fixes and updates released in previous patches for v8.5r1.
Overview of changes:
v8.5r1 patch 5:2005-03-10
To install the patch run the setup.exe
The simulator crashes when the DIVL R14 instruction from the example is executed.
int foo ( long l, int x )When CPU.21 bypass is enabled and at least two BUSCON registers are included in the startup code, the file start.asm shows a missing parenthesis at the BUSCON initialization:
AND BUSCON0, #(~0xD6FF)|0As a result, the following assembler error is issued:
E 252: expression syntax error
At the dialog 'Project Options | Assembler | Miscellaneous' one can specify a user defined sfr file (*.def). However, this file does not show up in the *.cfg file. As a result, CrossView uses the wrong one.
When debuging with OCDS on a XC167CI derivative you could change the CC1_T01CON SFR register content without any problems. But when debuging the same program via the ROM monitor debugger you cannot change the content of this SFR register.
After building the example (selected CPU = ST10X269), CrossView Simulator does not continue after the assembly instruction, but keeps on executing the same line over and over again.
int main()Faulty MAC unit Simulation result, see example:
/*After starting CrossView from EDE, CrossView crashes. Strange enough, this behaviour cannot be reproduced from the command line. Deleting xvw.ini solves the problem.
When an application writes to ROM or a read-only register, the Simulator should not modify the memory locations. Besides, it should be possible to change the register in the register or command window.
When defining a register in the sfr file (*.def) it is not possible to pass a default initialization value to the Simulator
When debugging with CrossView the source lines sometimes disappears when the source and disassembly window is active.
When RTS/CTS handshake is selected while the hardware does not support this, XVW hangs when connecting to the target.
After flashing by CrossView, there is no verification. When e.g. the serial baud rate is too high, flash programming may fail now and then. Please add a check box at the dialog 'Project options | CrossView Pro | Initialization' to execute a 'compare application' after flashing. This check box should be enabled by default.
CrossView doesn't show register names defined by DEFA in the disassembly window:
MOV R12,#0xaa
MOV 0xfce0,R12
instead of:
MOV R12,#0AAh
MOV SRCP0,R12
as listed in the *.src file.
According to Infineon's latest C166S V1 User's Manual from 08.2001, bit0 of SYSCON is not defined. Therefore it must not be showed as XPERSHARE at the dialog 'Project Options | Startup | SYSCON'.
Also there seem to be more errors in the .def and .h files for the C166S V1. A review and update of these files is required.
The SFR definitions for the fast external interrupt registers FEI2IC-FEI7IC and their corresponding bits are missing in the C161U SFR register files.
The following registers cannot be programmed in the startup code, and therefore they are not listed in EDE:
FCONCS5, TCONCS5, ADDRSEL5, TCONBURST5, FCONCS7, TCONCS7, ADDRSEL7, TCONBURST7
However, they should be defined in the corresponding register header and definition files.
Please add the following register definitions to ST10F397.h and ST10F397.def:
- OTR (0xEA10) Ownership Trace Register:
- DAC (0xEA0E) Data Acquisition Control Register
- DQM0/DQM1 (0xEA0C/0xEA0A) Data Acquisition Channel Register 0/1.
These registers only support word access.
Following the CPU manual, when pin EA is low during reset, BUSACT0 and ALECTL0 are set to "1" and BTYP is loaded with the bus configuration via PORT0. So when "Preserve bits set externally on reset" is activated and CPU.21 is checked, BUSACT0 and ALECTL0 must not be cleared by the AND instruction in the startup code:
0010 6686C029 42 AND BUSCON0, #(~0xD6FF)|0x00C0
Because this AND instruction will deactivate BUSCON0 (BUSACT0 is cleared) and subsequently the program ceashes. So for this configuration the mask 0x00C0 must be changed into 0x06C0.
WDTCON is write protected after the execution of EINIT by the register security mechanism for the ext2 arichitecture. Therefore, WDTCON must be initialized before EINIT in the startup code, and not after it, as it is now.
When debugging first with the simulator and you left some breakpoints set within your application this could influence the flashing with a next CrossView startup.
With a new CrossView startup while the application should be flashed CrossView also tries to set the breakpoints saved within the xvw.ini file. When these breakpoints where set within the ROM range these breakpoint couldn't be set and you will get the message:
Placing code breakpoint at 0x.. failed: BreakpointSet(): Write access at SW breakpoint address failed
Finally the flashing will not succeed and you will get the message:
Closing download failure
When debugging using the ROM/RAM Monitor, CrossView may crash easily when switching to another windows application.
The simulator has problems to simulate CAPCOM interrupts. The example uses the timer T7 in Compare Mode 0 and does not generate a CC16 interrupt.