Yahoo Groups archive

68300

Index last updated: 2026-04-29 00:01 UTC

Thread

RMW instructions

RMW instructions

2003-11-14 by Keith.Wilson@softron.de

Hello All,

I'm programming some hardware which apart from the uC, also consists of a 8-bit D-type output latch, configured as a port. The outputs of this latch need to be individually programmed (ie.- set/reset). I understand that because it's a WRITE-only device, RMW (Read-Modify-Write) instructions must be avoided when directly addressing this port - ie. by using a Shadow register. 
My question - is there a list of RMW instructions for the CPU32 processor (68332)?? I'm currently assuming that instructions like "ORI.X", "AND.X" use RMW bus accessses.......

Thanks in advance.  

-----Ursprungliche Nachricht-----
Von: Melear Charles-rdph40 [mailto:charles.melear@...]
Gesendet: Dienstag, 16. September 2003 20:37
An: '68300@yahoogroups.com'
Betreff: RE: [68300] Disabling interrupts during Flash writing sessions


Hello everyone,
 
In the 683xx series (of which the 68302 is NOT a member, oddly enough) when a write is done to the CPU status register, the "edge recognition" circuit for IRQ7 is re-enabled.  What this means in English is that if the I-bits are any value at all (yep, any old value) and the IRQ7 pin is currently low  and the code is inside the IRQ7 interrupt handler and the IRQ7 line remains low at the exit (execution of an RTE instruction) a NEW IRQ7 will be recognized even though there was no high to low transition on IRQ7.
 
The IRQ7 edge detect circuit is re-enabled any time that there is a "write" to the CPU status register as well, such as one created by an ori.w #0x0700,%sr or an andi.w #0xf8ff,%sr instruction.

If the IRQ7 line is low when you enable interrupts with one of the above instructions, a new IRQ7 will be taken.  If this occurs, will it mess up your system?
 
I think that the 68302 works the same way.  Remember, the 68302 uses a 68000 core as opposed to a 68020 core.
 
 
 
 
 
 
Also, if you are getting a Bus Error, there is a lot of stuff pushed to the stake.  If you system has not gone totally to the weeks, have the Bus Error handler dump the stack contents to memory, that is, read the last 50 or so bytes on the stack.  this will give you all sorts of information about where the error occurs and what type of error it is.
 
Regards,
 
Charlie
Show quoted textHide quoted text
 -----Original Message-----
From: jeffrey.tenney@... [mailto:jeffrey.tenney@...]
Sent: Tuesday, September 16, 2003 12:58 PM
To: 68300@yahoogroups.com
Subject: RE: [68300] Disabling interrupts during Flash writing sessions



Marty,

Be sure your VBR points into RAM, meaning that your entire 
interrupt-vector table is in RAM. 

Also, be sure your ISRs are also in RAM and can execute from there.  The 
routines must be position independent or you must map the RAM to the 
"correct" address for the routines.

Jeff





"Marty Burns" <burnsmarty@...>
09/15/2003 05:48 PM
Please respond to 68300


        To:     <68300@yahoogroups.com>
        cc: 
        Subject:        RE: [68300] Disabling interrupts during Flash writing sessions


After the enable command.

-----Original Message-----
From: jeffrey.tenney@... [mailto:jeffrey.tenney@...]
Sent: Monday, September 15, 2003 8:08 PM
To: 68300@yahoogroups.com
Subject: Re: [68300] Disabling interrupts during Flash writing sessions


Marty,

Do you get the mysterious fault immediately after the DISABLE command or
immediately after the ENABLE command?

Jeff





"Marty Burns" <burnsmarty@...>
09/14/2003 02:19 PM
Please respond to 68300


        To:     <68300@yahoogroups.com>
        cc:     "Martin J. Burns" <burnsmarty@...>
        Subject:        [68300] Disabling interrupts during Flash writing
sessions


I am debugging the flash writing routines for an embedded 68LC302
application. I seem to get some kind of bus fault? when I disable
interrupts
prior to invoking a flash erase followed by interrupt enable. I think the
communications engine is in the process of transmitting and it may have a
transmitter interrupt ready when I invoke the enable interrupts code.

Does anyone have a sense that I should be doing something additional in my
entry and leaving the flash routines. Note the flash routines are located
in
RAM. The rest of the code is in the FLASH. These routines involve
execution
from RAM since the FLASH is not valid during erase or write.

To disable interrupts:
#define DISABLE          ASM(" ori.w #0x0700,%sr")

To enable interrups:
#define ENABLE           ASM(" andi.w #0xf8ff,%sr")

To erase flash:

void FlashErase(int sector)
{
                 FLASH_PTR[0] = 0xF0F0;  // reset device to read mode

                 DISABLE;

                 FLASH_PTR[0x555] = 0xAAAA;      // unlock 1
                 FLASH_PTR[0x2AA] = 0x5555;      // unlock 2
                 FLASH_PTR[0x555] = 0x8080;
                 FLASH_PTR[0x555] = 0xAAAA;
                 FLASH_PTR[0x2AA] = 0x5555;
                 FLASH_PTR[flashSectors[sector].offset/2] = 0x3030;
                 while(FlashStatus(FLASH_PTR)!=STATUS_READY)
                                 TICKLE_WATCHDOG;

                 ENABLE;

}


int FlashStatus(volatile WORD *fp)
{
                  unsigned char d, t;
                  int retry = 1;

again:

                  d = *fp;        /* read data */
                  t = d ^ *fp;    /* read it again and see what toggled */

                  if (t == 0) {           /* no toggles, nothing's
happening */
                                 return STATUS_READY;
                  }
                  else if (t == 0x04) { /* erase-suspend */
                                 if (retry--) goto again;    /* may have
been write completion */
                                 return STATUS_ERSUSP;
                  }
                  else if (t & 0x40) {
                                 if (d & 0x20) {     /* timeout */
                                   return STATUS_TIMEOUT;
                                 }
                                 else {
                                   return STATUS_BUSY;
                                 }
                  }

                  if (retry--) goto again;    /* may have been write
completion */

                  return STATUS_ERROR;
}




---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu <http://www.motorola.com/mcu> 



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/> 






[Non-text portions of this message have been removed]



---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu <http://www.motorola.com/mcu> 



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/> 





---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu <http://www.motorola.com/mcu> 



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/>  






[Non-text portions of this message have been removed]



Yahoo! Groups Sponsor	

ADVERTISEMENT
 <http://rd.yahoo.com/M=251812.3856299.5103760.1261774/D=egroupweb/S=1706554205:HM/A=1754451/R=0/SIG=11tkldm5d/*http://www.netflix.com/Default?mqso=60178323&partid=3856299> click here	
  <http://us.adserver.yahoo.com/l?M=251812.3856299.5103760.1261774/D=egroupmail/S=:HM/A=1754451/rand=114580567> 	

---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu <http://www.motorola.com/mcu> 



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> . 




[Non-text portions of this message have been removed]



---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Re: RMW instructions

2003-11-14 by Dimiter Popoff

Keith.Wilson@...,

> I'm currently assuming that instructions like "ORI.X", "AND.X" use RMW bus 
> accessses.......  

Not quite. These use a separate read and a subsequent write cycle; in a 
single processor system, this is indivisible so you may assume for
your purpose they are RMW.
The only opcode using a true RMW cycle (AS does not get deasserted between
the read and write portions of the cycle) for the CPU32 is TAS  (test and set).
With write-only latches like yours, the thing to take care of is to
mask interrupts which might want to modify the latch while doing
"memory-copy read-write and latch write".
All this is valid in a signle processor system, I assume this is the case.

> My question - is there a list of RMW instructions for the CPU32 processor (68332)?? 

There used to be a book, "68k series programmers reference manual" or
something like that. I don't know whether it can be found nowadays,
asking Motorola should work. Perhaps it is on their website as a .pdf
file as well (I have never checked, I have my old paper copy).

Dimiter

--------------------------------------------------------------------
Dimiter Popoff
Transgalactic Instruments, Gourko Str. 25 b, 1000 Sofia, Bulgaria
http://transgalactic.freeyellow.com

Re: [68300] RMW instructions

2003-11-14 by jeffrey.tenney@gm.com

Keith,

Just make sure you separate RMW Instructions and RMW bus cycles.  RMW
Instructions don't necessarily use RMW bus cycles.  (In fact, most don't.)

I don't know of any all-encompassing list of RMW instructions.  However,
you can determine which instructions read, modify, then write just by
considering each instruction individually before you use it.  You'll be
able to predict when the CPU will have to read the original value to
perform the correct operation.

Also, the CPU might be able to help you verify your choice of instructions.
If possible, set up the chip select used for latch as write-only.  During
testing, you'll get an exception if you use any instructions that use a
read cycle.

Jeff



|---------+---------------------------->
|         |           Keith.Wilson@soft|
|         |           ron.de           |
|         |                            |
|         |           11/14/2003 05:59 |
|         |           AM               |
|         |           Please respond to|
|         |           68300            |
|         |                            |
|---------+---------------------------->
  >------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                              |
  |       To:       68300@yahoogroups.com                                                                                        |
  |       cc:                                                                                                                    |
  |       Subject:  [68300] RMW instructions                                                                                     |
  >------------------------------------------------------------------------------------------------------------------------------|




Hello All,

I'm programming some hardware which apart from the uC, also consists of a
8-bit D-type output latch, configured as a port. The outputs of this latch
need to be individually programmed (ie.- set/reset). I understand that
because it's a WRITE-only device, RMW (Read-Modify-Write) instructions must
be avoided when directly addressing this port - ie. by using a Shadow
register.
My question - is there a list of RMW instructions for the CPU32 processor
(68332)?? I'm currently assuming that instructions like "ORI.X", "AND.X"
use RMW bus accessses.......

Thanks in advance.

-----Ursprungliche Nachricht-----
Von: Melear Charles-rdph40 [mailto:charles.melear@...]
Gesendet: Dienstag, 16. September 2003 20:37
An: '68300@yahoogroups.com'
Betreff: RE: [68300] Disabling interrupts during Flash writing sessions


Hello everyone,

In the 683xx series (of which the 68302 is NOT a member, oddly enough) when
a write is done to the CPU status register, the "edge recognition" circuit
for IRQ7 is re-enabled.  What this means in English is that if the I-bits
are any value at all (yep, any old value) and the IRQ7 pin is currently low
and the code is inside the IRQ7 interrupt handler and the IRQ7 line remains
low at the exit (execution of an RTE instruction) a NEW IRQ7 will be
recognized even though there was no high to low transition on IRQ7.

The IRQ7 edge detect circuit is re-enabled any time that there is a "write"
to the CPU status register as well, such as one created by an ori.w
#0x0700,%sr or an andi.w #0xf8ff,%sr instruction.

If the IRQ7 line is low when you enable interrupts with one of the above
instructions, a new IRQ7 will be taken.  If this occurs, will it mess up
your system?

I think that the 68302 works the same way.  Remember, the 68302 uses a
68000 core as opposed to a 68020 core.






Also, if you are getting a Bus Error, there is a lot of stuff pushed to the
stake.  If you system has not gone totally to the weeks, have the Bus Error
handler dump the stack contents to memory, that is, read the last 50 or so
bytes on the stack.  this will give you all sorts of information about
where the error occurs and what type of error it is.

Regards,

Charlie
Show quoted textHide quoted text
 -----Original Message-----
From: jeffrey.tenney@... [mailto:jeffrey.tenney@...]
Sent: Tuesday, September 16, 2003 12:58 PM
To: 68300@yahoogroups.com
Subject: RE: [68300] Disabling interrupts during Flash writing sessions



Marty,

Be sure your VBR points into RAM, meaning that your entire
interrupt-vector table is in RAM.

Also, be sure your ISRs are also in RAM and can execute from there.  The
routines must be position independent or you must map the RAM to the
"correct" address for the routines.

Jeff





"Marty Burns" <burnsmarty@...>
09/15/2003 05:48 PM
Please respond to 68300


        To:     <68300@yahoogroups.com>
        cc:
        Subject:        RE: [68300] Disabling interrupts during Flash
writing sessions


After the enable command.

-----Original Message-----
From: jeffrey.tenney@... [mailto:jeffrey.tenney@...]
Sent: Monday, September 15, 2003 8:08 PM
To: 68300@yahoogroups.com
Subject: Re: [68300] Disabling interrupts during Flash writing sessions


Marty,

Do you get the mysterious fault immediately after the DISABLE command or
immediately after the ENABLE command?

Jeff





"Marty Burns" <burnsmarty@...>
09/14/2003 02:19 PM
Please respond to 68300


        To:     <68300@yahoogroups.com>
        cc:     "Martin J. Burns" <burnsmarty@...>
        Subject:        [68300] Disabling interrupts during Flash writing
sessions


I am debugging the flash writing routines for an embedded 68LC302
application. I seem to get some kind of bus fault? when I disable
interrupts
prior to invoking a flash erase followed by interrupt enable. I think the
communications engine is in the process of transmitting and it may have a
transmitter interrupt ready when I invoke the enable interrupts code.

Does anyone have a sense that I should be doing something additional in my
entry and leaving the flash routines. Note the flash routines are located
in
RAM. The rest of the code is in the FLASH. These routines involve
execution
from RAM since the FLASH is not valid during erase or write.

To disable interrupts:
#define DISABLE          ASM(" ori.w #0x0700,%sr")

To enable interrups:
#define ENABLE           ASM(" andi.w #0xf8ff,%sr")

To erase flash:

void FlashErase(int sector)
{
                 FLASH_PTR[0] = 0xF0F0;  // reset device to read mode

                 DISABLE;

                 FLASH_PTR[0x555] = 0xAAAA;      // unlock 1
                 FLASH_PTR[0x2AA] = 0x5555;      // unlock 2
                 FLASH_PTR[0x555] = 0x8080;
                 FLASH_PTR[0x555] = 0xAAAA;
                 FLASH_PTR[0x2AA] = 0x5555;
                 FLASH_PTR[flashSectors[sector].offset/2] = 0x3030;
                 while(FlashStatus(FLASH_PTR)!=STATUS_READY)
                                 TICKLE_WATCHDOG;

                 ENABLE;

}


int FlashStatus(volatile WORD *fp)
{
                  unsigned char d, t;
                  int retry = 1;

again:

                  d = *fp;        /* read data */
                  t = d ^ *fp;    /* read it again and see what toggled */

                  if (t == 0) {           /* no toggles, nothing's
happening */
                                 return STATUS_READY;
                  }
                  else if (t == 0x04) { /* erase-suspend */
                                 if (retry--) goto again;    /* may have
been write completion */
                                 return STATUS_ERSUSP;
                  }
                  else if (t & 0x40) {
                                 if (d & 0x20) {     /* timeout */
                                   return STATUS_TIMEOUT;
                                 }
                                 else {
                                   return STATUS_BUSY;
                                 }
                  }

                  if (retry--) goto again;    /* may have been write
completion */

                  return STATUS_ERROR;
}




---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu <http://www.motorola.com/mcu>



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ <
http://docs.yahoo.com/info/terms/>






[Non-text portions of this message have been removed]



---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu <http://www.motorola.com/mcu>



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ <
http://docs.yahoo.com/info/terms/>





---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu <http://www.motorola.com/mcu>



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ <
http://docs.yahoo.com/info/terms/>






[Non-text portions of this message have been removed]



Yahoo! Groups Sponsor

ADVERTISEMENT
 <
http://rd.yahoo.com/M=251812.3856299.5103760.1261774/D=egroupweb/S=1706554205:HM/A=1754451/R=0/SIG=11tkldm5d/*http://www.netflix.com/Default?mqso=60178323&partid=3856299
> click here
  <
http://us.adserver.yahoo.com/l?M=251812.3856299.5103760.1261774/D=egroupmail/S
=:HM/A=1754451/rand=114580567
>

---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu <http://www.motorola.com/mcu>



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <
http://docs.yahoo.com/info/terms/> .




[Non-text portions of this message have been removed]



---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.