We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
We're using AT89C51ED2, and now are busy with a problem, witch was caused by reading back the content of XRAM. As it is officially published in datasheet, this MC has 1792 bytes of internal XRAM. We have set the XRS's bits for selecting the full size of XRAM, and cleared the EXTRAM bit, and EEE bit, mapping the XRAM segment. After that, we are writing data to XRAM using MOVX @DPTR, A procedure. After we have reashed the last adress we are trying to readback the data from XRAM and it is not correct at all.
"After we have reashed the last adress we are trying to readback the data from XRAM and it is not correct at all." Are you talking about your code reading it back, or the debugger? Does it work in the simulator?
I've been talking about reading back the data, sent to XRAM a few seconds before. But nowdays i've successfully solved the problem. The only thing that is now troubling me is the doudble DPTR register. I'm thinking now that it was the reason of the first problem, now i'm using R0 and R! register for adressing the XRAM? and the only DPTR register and the reading bck becomes stable. Maybe it works not stable?
the double DPTR register. ....... Maybe it works not stable? Even with Atmel I would doubt that the DPTR select is not stable. Most likely is is related to a use in an interrupt or an "accidental" (re)set of the select bit. When working with double DPTRs I always do a project scan for the SFR that select them and double check that all subroutines and ISRs save and restore. As an example (instead of me downloading the datasheet and finding them) let me call the SFR DPSEL and the bit that select the dptr DPBIT. I ALWAYS delete the definition of DPBIT and rename it DPSEL_DPBIT so that a scan to see if there is an accidental change of the DPTR select it can be found on one search. I do assume you use an editor that can scan for a phrase in all files related to the project. Erik
Hi Alexander, We use a similar Atmel chip and I think the data sheet says you should NOT use 'MOVX @R0' instructions to access the chips onchip XRAM as this only works for the 1st page (0x00..0xFF) of XRAM but should always use DPTR for both reading and writing. Is it a posibility that you have ram external to the chip mapped into the same address space as the onchip ram and have 'accidentally' disabled the internal XRAM? Mark.
May be you're right, i'm thinking myself, that it should be stable. I've did not rescaned the reset value, hoping the correct result of reset. I'll try tomorrow do it as you suggest, then will post the result. It is true, that Atmel suggests not to use the R0 registers for accessing the XRAM larger then FFh, but nobody says that it should not work. I'll myself thinking that it will be more reliable to use two registers like R0 and R1, instead of switching between DPTR's. The only thing, that sorrows me is the speed, but in my situation it's not a great problem, and i hope to increase it switching to X2 mode.
It is true, that Atmel suggests not to use the R0 registers for accessing the XRAM larger then FFh, but nobody says that it should not work. Where does the high byte of the address come from? Internal XRAM is - to my knowledge - not attached to P2 in any derivative (it would be ridiculous to do so) I'll myself thinking that it will be more reliable to use two registers like R0 and R1, instead of switching between DPTR's Dual DPTR is not a problem if you pay attention This is not an issue of what is "reliable" but of using the dual DPTR correctly. Erik
To Mark Hickman You've said you've been using this model. Did it bring you any problems. You see? it is the first time we've chosen this MC and the first task for us is to test it for confirming its reliabness. We've studied the atmel's errata docs, they says about reinterrups, witch takes places using timer 0 and 1 in X2 mode. Nowdays we have not yet confirmed it. We have experience of using AT89S8252, and found a problem with flash RAM, witch sometimes after several resets and power-downs, cleares itself. We'll test C51ED2 for this later. May be there is something more?
"Where does the high byte of the address come from? Internal XRAM is - to my knowledge - not attached to P2 in any derivative (it would be ridiculous to do so)" Don't some variants have an SFR to do this?
hi, they says about reinterrups, witch takes places using timer 0 and 1 in X2 mode No, it occures only if the timers in different X2 mode: either Timer 1 in X1 and Timer 2 in X2 or vice versa. Regards, Oleg
hi, It is true, that Atmel suggests not to use the R0 registers for accessing the XRAM larger then FFh, but nobody says that it should not work. You should read the datasheet once again. Thay do say that it does not work: ===== from page 25 of AT89C51RD2 Accesses to XRAM above 0FFH can only be done by the use of DPTR. ===== Notice the word "ONLY" in quotation above. Regards, Oleg
"Where does the high byte of the address come from? Internal XRAM is - to my knowledge - not attached to P2 in any derivative (it would be ridiculous to do so)" Don't some variants have an SFR to do this? yes, most do, but not the derivative discussed. Thus "Where does the high byte ..." Erik