Using the I/O View with Simulator

The I/O view generally works in the same manner as with other tools. However, due to the way I/O addresses are mapped to internal signals in the simulator model, there are a few peculiarities. These occur with registers or bitfields within registers that are read-only, write-only, read and write from different hardware registers, or have peculiar write modes. In general, different bitfields within the same register may behave differently because they are mapped to different hardware locations.

When a register is changed in the I/O view, the new value of the register is written to the target and then read back, and the read-back value is shown in the I/O view. For this reason, the value shown may be different from the value written, for various reasons.

• In a regular register/bitfield with read/write access, when changing its value the new value is shown immediately.

• In some cases, read and write access go to different hardware locations. The effect of this may be that attempting to change a register/bitfield has no visible effect even if the register is actually written (like the USART UDR register in many devices), or that the effect is delayed by one or more cycles (like registers with double buffering).

• If a register/bitfield is read-only, attempting to change it will have no effect.

• If a register/bitifeld is write-only, it will normally always show zero.

• Some registers/bitfields (particularly in XMEGA and UC3 devices) have special write modes like set, clear, or toggle. This means that writing a value of one to a bit will perform one of these operations on the bit, while writing zero has no effect (This to eliminate the need for read-modify-write sequences to change single bits in a register). Often such registers are mirrored as a regular register at a different address, in these cases the simulator normally will allow write to this regular register even if it is documented as read-only. Using the regular register when making changes from the I/O view is much easier.

• When possible, the simulator will often allow full read/write access to registers/bitfields even though they are documented as read-only or write-only. One particularly important example of this is interrupt flags. These are often intended to be read-only, but allowing to write them from the simulator allows triggering the interrupt if the hardware is designed such that the interrupt flag is the cause of the interrupt, which is often the case. This feature is important for stimuli generation, e.g., ADC interrupts can be stimulated by means of writing the converted value to the ADC data register and then trigger the ADC interrupt by means of setting the ADC interrupt flag, (both the ADC data register and the ADC interrupt flag are typically described as read-only in data sheets)

• In some 32-bit (ARM and UC3) models, some of the peripheral module I/O register access use the on-chip bus instead of accessing internal signals directly. In these cases the simulator will be subject to the same restrictions as the OCD-based emulators. For example, read-only registers remain read-only, some registers require a protection pattern to be written to a different register before the actual register can be written, some peripherals must have their clock explicitly enabled before they can be accessed, etc. Per-device details can be found in Device and Family Specific Issues.

• Sometimes hardware design makes it impossible to map a bitifield properly with reasonable effort. This most frequently affects write access, but sometimes even read. Such deficiencies are documented in Device and Family Specific Issues.

• Finally, unresponsive or otherwise faulty registers in the I/O view can be caused by bugs in the I/O mapping in the simulator model. This is the most common type of bug in the simulator.