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.
First let me describe a little bit about our system:
It is not von-neuman, and the main code executes from OTP (One Time Programable) memory. there is also a small amount of XRAM, and code can also be executed from there too.
When executing from OTP, we are unable to use MOVX to read or write CODE. We can use MOVC read CODE.
When executing from XRAM, we are unable to use MOVX to read or write XDATA. We can use both MOVC and MOVX to read CODE.
Despite being OTP, we do have the ability to dynamically patch an small number of quads of OTP code at any address to whatever value we choose.
My belief is that all the elements that are needed to execute a MON51 stub from OTP are present. We can patch code to jump to the stub on a break point, and code can be read through the MOVC to keep adjacent instructions coherent in the patch?
My question is, does anyone have any experience or deep working knowledege of the MON51 that can point me to section that inserts the jumps that set and clear break points? Are there any thoughts about how to modify this with minimum impact on the stub?
Thanks in advance,
Chris.
"The XRAM is mapped into the code space"
I think it could help if you tidied-up your teminology a bit:
The 8051 architecture has two external address spaces: 1. XDATA - this has read+write access, and is addressed by the MOVX instruction; 2. CODE - this has read-only access, instructions are fetched from here, and MOVC provides read-only access.
These terms are defined by the 8051 architecture, and are totally independent of your target hardware - the memory that's addressed by MOVX is always "XDATA" as far as the 8051 is concerned!
Therefore, it's best not to think of anything in your target hardware as "XRAM" - especially as you say it can be mapped into the 8051's CODE space!
I speak from experience here, having worked with the Triscend E5, which allowed any part of its external memory to be mapped (and re-mapped) into the 8051's CODE or XDATA spaces - or both!
to clarify then:
1) both OTP and RAM are available in the 'XDATA' and the 'CODE' space.
2) Instructions may be executed from OTP or RAM.
3) MOVC can always read OTP memory (only).
4) MOVX will read OTP memory when executed from RAM.
5) MOVX will read and write RAM when executed from OTP.
Hope that helps. best not mention the ROM or I'll properly confuse you ;)
"best not mention the ROM or I'll properly confuse you"
No worries there: the Triscend had on-chip "external" RAM, on-chip ROM, off-chip RAM, and off-chip Flash - all of which were variously mapped between CODE and XDATA!! :-0
Chris,
did you actually try to configure MON51 already. BEFORE_GO, AFTER_GO and WR_CODE give you full control about the memory interface.
I'm in the process. The MON51 is compiled and in a hardware image, but we've broken our MOVX instruction on all memory buses at the moment. Its going to be after the weekend now before I find out if it worked I'm afraid...
Can I take the oportunity to ask if there are any licensing implications of including a MON51 binary in a ROM image? this might be another route open to us.