Hi,
I am trying to use large memory model" with AT89C51RD2. I have written a simple UART code and trying to debug the code with the simulator. Once, the code enter into the ISR the following error message comes up "Clock is not working"
And when using small memory model the error didn't pop up. Could anyone pleas let me know what is the reason behind this error message when using the large memory model.
// CKCON0 = 0x00; CKRL = 0xFF; SCON = 0x50; /* uart in mode 1 (8 bit), REN=1 */ BDRCON &=0xEE; /* BRR=0; SRC=0; */
I cant/wont try to figure out what this mix of C99 and C89 commenting produces.
you finally managed to read the posting instructions but what you post is such a mess it does not even qualify as code
Hope this helps???
After you have broken the code by posting using the wrong tags, you can't reuse the old post and add in the tags. You need to retrieve the code directly from the editor.
Or does your code in the editor really contain lines that looks like below???
*/ while(1) /* endless */ { #if 0 if (TI) { <===== #if after { on the same line??? TI = 0; SBUF = 0xAA; } #endif }
If this is how careful you are about making sure your code is easy to read in your posts, I can guess how careful you are reading datasheets or when you originally wrote the code or how careful you are when debugging.
Maybe it's time you either switch to some other task - like maybe bending bananas? If you want some progress doing coding, you just have to realize that computers are very hard. They care about every little comma. So you need to care about every little detail - in your code, and in the requirements specifications and in the datasheets. Sloppiness doesn't take you very far.
Sorry for the mess and confusion. There was some mistake done by me while posting the code. In the preview window it appears fine but while posting it gets mess up. Sorry for the confusion. Here is the correct code.
#include <AT89C51XD2.H> #include <math.h> #include <string.h> main() { unsigned char xr = 0; // CKCON0 = 0x00; CKRL = 0xFF; SCON = 0x50; /* uart in mode 1 (8 bit), REN=1 */ BDRCON &=0xEE; /* BRR=0; SRC=0; */ BDRCON |=0x0E; /* TBCK=1;RBCK=1; SPD=1 */ BRL=0xE2; /* 9600 Bds at 11.059MHz */ xr = AUXR; AUXR = xr | 0x02; ES = 1; /* Enable serial interrupt*/ EA = 1; /* Enable global interrupt */ TI = 1; BDRCON |=0x10; /* Baud rate generator run*/ while(1) /* endless */ { #if 0 if (TI) { TI = 0; SBUF = 0xAA; } #endif } } void Serial_IT(void) interrupt 4 // using 1 (can't) { unsigned char ch; if (RI == 1) { /* if reception occur */ RI = 0; /* clear reception flag for next reception */ ch = SBUF; /* Read receive data */ //SBUF = uart_data; /* Send back same data on uart*/ } else { if(TI) { TI = 0; SBUF = 0xAA; } } }
I am trying to use large memory model" with AT89C51RD2..... And when using small memory model the error didn't pop up.
first do not use the large model it is deterimental to the processor second, you need in startup.a51 to enable the 'XDATA"
Using large memory model with AT89C51RD2 works well. But the issue occurs when I include MODDP2 along with large memory model.
When I am trying to include MODDP2 along with large memory model the above mentioned issue occurs. The issue occurs only when I add the following line in the code.
#pragma moddp2
Hence, I suspect that there is some issues in using MODDP2. Please help me to find the issue.
Using large memory model with AT89C51RD2 works well. If you consider a considerable waste of code space and CPU cycles "working well", maybe.
Oh, and the actual cause of your problem is precisely that #pragma moddp2. That's the wrong switch for the CPU you're working with. For this one it should be "modp2" (only one 'd'). And generally you shouldn't put that option into the source anyway, but rather set the global switch in the project settings' "Target" page: "Use multiple DPTR registers", instead.
The reason this failed so interestingly is that enabling the wrong switch along with large model caused the compiler to generate extended interrupt entry code for that other CPU, which needs preconditions that your code, being for a different processor, doesn't establish.
Thank you very for pointing the mistake and detailed explanation.
This solution fixed the issue