If I do an integer division using the 167 CPU simulator it works fine. However, if I use my Kitcon-167 evaluation board and the MON166 monitor (simulated serial mode) with uVision2, I get the wrong result for the division. Stepping through the assembler code generated by the compiler it seems to go wrong when the code attempts to load the MDL register. The same code is fine when I step through it using the CPU simulator. Can anyone offer any idea why this might be, and what I might be able to do to work around it?
I have done some more investigation of this. I have now found that the division works fine on the target CPU as well, providing I use either the BOOTSTRAP or ASC0 mode for the debugger. If I use Simulated Serial mode, the result of the division is incorrect. If anyone can offer any advice as to what is going on it would be greatly appreciated. I'm wondering if the Simulated Serial version of the monitor is upsetting the DPP registers or something like that?
More information: This problem only occurs when the program is single-stepped using the Simulated Serial version of the debug monitor. The code appears to be unable to load a value into the MDL register. Even if I put the line MDL = 0; in my C code, the value 0 does not get into MDL. MDL actually gets the value 27h.
I think it must be reasonable to assume that the simulated serial routines are using the MDL register without saving it. Can anyone confirm if this is the case?
I have just discovered that I have a newer version of the monitor which came with our Keil CD. I had been using a version of the monitor which came with our Kitcon-167 evaluation board. The newer version saves the MDL register in the relevant place, so all is now well! I hope this may help someone else with the same problem, though if they are using the latest stuff they'll be okay anyway. Perhaps Keil could put a version history of MON166 on their website, and make the latest version available for download?