Question:

1) Intermediate breakpoint is ignored/jumped during runtime execution. (I would think the case is rare and should not occur at all. No explanation.)

2) Emulator is not really stable when communicating with other emulator. (The corresponding emulator is Intel based and customized protocol handshaking is performed while this error occurs. This may be due to the slow switching speed of the hardware or the customized communication protocol not idiot-proof.)

3) When 2 interrupts are set, program will be unstable when run. (If the ISR is not performed properly, this case may happen. However, CET claimed that they are following the correct procedure. No explanation.)

4) The sync comm port cannot effectively transmit data. (The databook listed 2 examples using polling and DMA to perform sync transfer via comm port but CET found both cannot work. Random data loss or periodic data loss occur when using polling. For DMA, there are many 0 in the header before the required data fall in place. Only by using the interrupt method can the transfer be successful. No explanation.)

Answer:

- Breakpoints are set by replacing the opcode with an SWI. This is a special TRAP that signals the XDS510 that the device has stopped and needs to be scanned. I cant think of any instances where this does not work.

- During a single step operation, the emulator software does not allow interrupts to be recognized by the CPU, but they can be latched into the flag registers.

- The DMA counter decrements on READ, not write. For example, if you poll the DMA count register, and halt or reset the DMA before it finishes the write, you could be loosing data.

- Interrupts are also not recognized during times when the CPU is not fetching opcodes, or during a delayed branch or call. Instances where this occur are during RPTS or bus stalls.