| ??? 04/21/05 19:06 Read: times |
#92072 - Thoughts for variety of answers Responding to: ???'s previous message |
Thomas Skyt said:
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. I set Keil up according to the recommendations on the Dallas website, but had to bend them a little (see next answer): http://www.maxim-ic.com/appnotes....umber/3267 That looks great. To the best of my knowledge, the '420 differs from the '450 only in amount of flash (16K vs. 64K, respectively) and IAP ('420 has none, '450 has it). 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. I am running the 7.07 version of the compiler and the 7.08a version of the assembler. The uVision IDE is version 2.39. Ok. I think it would be wise to find out what level of simulation support for the '420/430/440/450 enhancements are provided in this version. That's definitely rather old (well over a year), and it's quite possible that the support didn't exist back then. If you still have technical support, this is definitely worth a call to Keil. Otherwise, perhaps someone else can chime in, because I do not have this information. 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. In that case, I consider myself both fortunate for not having that bug and unfortunate for not having the opportunity to specify this exact device. But then again, I am currently only using an 11.0592 MHz quartz, but I was thinking about exchanging it for a 33 MHz quartz oscillator. If only I could have been so fortunate. Before you jump on that 33 MHz oscillator idea, consider using an 8 MHz oscillator and using the 4x clock multiplication facility. As Kevin Self from Dallas pointed out to me last week, you can realize a nice reduction in EMI this way. Of course, if you have a system that is doing a lot of external bus accesses, much of that benefit disappears. 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 just had a look into at - I hadn't noticed that at first. I wrote that piece of the code when I was already tired and irritated. It has been changed back - http://www.8052.com/forum/read.phtml?id=92059 - to the "original" setup. /Thomas When I am manipulating SFRs and other bit-packed registers, I usually like to use a little macro to (a) force me to think about exactly what bits I want to modify and (b) prevent accidental modification of things I don't want to modify: #define BIT_RECONF(SRC, POS_MASK, NEW_VAL) SRC = (SRC & ~POS_MASK) | (POS_MASK & NEW_VAL) Erik Malund said:
So the interrupt happens, thus forget the timer for now.
There are some strange things here are you sure it is not a watchdog or some such (a typical simulator "oversight") try a toggle pin at main() before the while(1), Ill bet you a beer at FrankA (easy when I am 3000 miles away) that it toggles. Erik That's a very distinct possibility, and Erik's suggestion is excellent here. The watchdog is disabled by default (again, think drop-in compatibility with classic 8051), but accidents happen sometimes. As I recall from looking at the code I commented on earlier, you were also modifying bits in an SFR that had some effect on watchdog functionality. I do not believe that you were turning the watchdog on, but, as I said before, I didn't check in detail. --Sasha Jevtic |
