A variety of comments follow on the numerous posts in this thread.


First, have you made sure that you have your project in Keil set up as a project that is built around a DS89C450, and not another chip, such as a generic 8051? You seem to be including a legitimate startup file, which suggests you have this right, but if you included that manually, and do not have the project set up properly, the simulator will almost certainly not know that it is supposed to simulate the DS89C450's enhanced timers, and instead, will most likely be simulating ordinary 8051 timers. That could explain why what you see in the simulator is not what you see in hardware.

Also, I am wondering what version of Keil you have. I do not know at what version simulation support for the enhanced DS89C450 peripherals was added. However, I should note that 7.50a should have you including START4XX.A51 for a DS89C450, which leads me to believe you might not have the latest version. And, for your information, in this version, if you enable the startup file's manipulation of PMR, you can find yourself in a problematic situation: a bug in that code will put your device in 2x clock frequency multiplication mode. This can easily pass unnoticed if your oscillator is less than 16 MHz or so, but if it is much above that frequency, the device will be internally overclocked as a result and is likely to hang. Keil acknowledged this problem, and said they will fix it in a future release.


I have not thoroughly looked through your SFR initializations, but you might want to double check them; during a quick run through, I noticed you were manipulating, among other things, the number of stretch cycles used for external memory accesses. I suspect that was not intentional; it certainly is not part of the comments.


I have never looked into this in detail, but given that you can single step through the generated assembly, the simulation should be accurate down to the instruction of the generated code.

Also, I doubt that volatile is going to make a difference here. Although volatile will prevent variable accesses from being optimized away by the compiler, in code like this, the compiler cannot prove that the incrementing timer0_tick has no effect, and thus, should not optimize it out.


I assume that the confusion here has to do with crystals versus true external oscillators. The DS89C450 can operate from either crystal or external oscillator, and I believe that the timer control illustrations on pages 102 - 106 of the device's manual refers to. This is most likely used as a reference in contrast to the completely internal ring oscillator, which can also serve as a clock source for the device.


See the comments immediately above. Also, I think that the divide-by-12 feature here is intended to make the timer behave identically to the classic 8051 timer by default. Dallas markets this part as an accelerated but otherwise drop-in replacement for classic 8051 devices. They pretty much want your 8051 application to get a 10x or so speed boost out of the box without even recompiling. It's a good thing to keep that idea in the back of your mind when working with these devices, as otherwise many of the defaults seem counterintuitive (default stretch cycle setting nonzero, internal XRAM disabled, etc.)


A true external oscillator may be connected to the XTAL1 pin, as illustrated in figure 5-2 on page 42 of the device's manual. I use Epson SG-531 series oscillators with these devices regularly.

--Sasha Jevtic