Problem with interrupt detection in Full Chip Simulation in HiWave

[robswan]

HiWave V6.1, packaged with the demo version of CodeWarrior 5.2.  Target processor is MC9S12C128.  Working in assembly language.

I have timer interrupts scheduled for output compare on T0, T6 and T7 and have set breakpoints at the start of each interrupt handler but the simulator sometimes "misses" interrupts.

What appears to be happening is that, if the simulator is already running inside one interrupt handler when the timer counter clicks over to match another compare register, the appropriate bit of TFLG1 doesn't get set, so it won't know to simulate an interrupt after RTI.

The simulator works correctly if I single-step to and through the RTI (*).  Needless to say, this gets pretty tedious.

I hope that makes sense.  Is this a known problem?  Is there a workaround?  I tried setting breakpoints at every RTI instruction, hoping that a single-step from there might sort it out, but that didn't seem to help.  I guess that the simulator needs to be single-stepping right at the moment the timer clicks over to match.

I'd welcome any suggestions.

(*) on reflection, it'd probably work if I just single-stepped until the bit got set in TFLG1.  Still no fun.

[ZhangJennie]

Hi Robert.

CW hiwave full chip simulator is a good tool to simulate code instructions. But it is not good to simulate on chip peripheral registers.

It happens that some peripheral registers can not change as expected in simulator, when it need on chip MCU module support background.

Thus we suggest you connect board to test on chip peripheral resources functions to guarantee all function working correctly.

Have a great day,
Jennie Zhang

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[robswan]

Thank you for your response Jennie, disappointing though it is.  I certainly understand a simulation environment is a poor substitute for the real world, but both environments are valuable for testing.  Each can be used for some tests that are impractical in the other and I really do want to test my code on a simulator as well as the physical hardware.

I find it incredible that the "Full Chip Simulation" environment is only intended to simulate the CPU core and not the peripherals.  If that is true then the manual needs to be updated.

Online manual HC(S)12(X)Full Chip Simulation Connection->Technical Considerations:

The Full Chip Simulation (FCS) connection runs a complete simulation of all processor peripherals and I/O on the user's Personal Computer. No development board is required. Each derivative has a unique simulation engine to accurately simulate the memory ranges, I/O, and peripherals for a given derivative.

Rather than change the manual though, I  would prefer this problem to be recognised as a bug.  Since this is termed "legacy" software, I don't hope for a fix, but I would greatly appreciate suggestions for a workaround.

FWIW, I have now reproduced similar wrong behaviour with a simpler program.  The extra factor seems to be something to do with wraparound of TCNT.  I suspect there is an incorrect comparison of counter values going on inside the hiwave simulator.  I can post here if I nail down a really simple case.

Thanks again,

Robert.

[robswan]

Brief follow-up

I tried the simple test-case of  the above situation -- compare register matching while within another timer's ISR.  It behaved correctly, so the problem is not so simple.  Building up from scratch didn't work, I'll now try trimming down my application to see if that gives any clues.