Hi, all. I seem to have a problem with C51 (DOS) v5.50 and the Atmel AT89S53. The program is all C (no assembler) and accesses different parts of XDATA memory from both the normal main program and also from an interrupt function. It appears that main's xdata addresses are corrupted. The problem goes away if the pragma is removed. The v5.5 release notes say that the MODA2 pragma is only for the AT89S8252, but as I understand it all the Atmel AT89 cores implement the dual pointers in the same way. The problem also goes away if I don't use strcpy, which may point to a library issue. Has anyone else seen this problem? Would a subtle error in the header file for the processor have any bearing on the problem? Your thoughts would be appreciated. Richard
I believe that it's only library functions like strcopy which make any use of the 2nd DPTR. Is your interrupt function also compiled with the 2nd DPTR enabled? Could that be leaving your DPTRs in a mess?
Make sure that your interrupts are saving both data pointers as well as the datapointer selector register. To make sure this happens, make sure that the #pragma MODA2 is specified before the ISR. That's what causes the C compiler to generate code that saves the DPTRs. Jon
"make sure that the #pragma MODA2 is specified before the ISR" Could you square that advice (which seems sensible) with the following from p120 of the C51 User's Guide 03.2000 (which sounds dubious): "To conserve stack space, you may compile interrupt functions with the NOMODP2 directive. The C51 compiler does not use the second data pointer when this directive is used."
Sure... :-) Make sure that your interrupts are saving both data pointers as well as the datapointer selector register but only if your interrupt service routine (or one of the routines it calls) changes the second data pointer. If your interrupt service routines have no effect on the second data pointer, it is not necessary (of course) to save it. Jon
When you say, "second data pointer," does that actually mean, "the currently non-selected data pointer?"
When you say, "second data pointer," does that actually mean, "the currently non-selected data pointer?" Yep, that's right. Note that if an interrupt uses DPTR (whichever one is currently selected) it saves it. The only problem is when you call a routine inside an ISR that was compiled with MODA2 that subsequently calls strcpy or strcmp. In that case, the ISR is compiled without dual data pointer support, however, it calls another function that was compiled WITH dual data pointer support. Jon
When you push dpl and dph at the begin of interrupt routine, altough dps is set to use dptr1, problems will occur. For ex. INC DPTR will do it. Roman