Forums

DSP56F80x question about a pipeline dependency when disabling interrupts

Started by Art Johnson March 28, 2003
Hello,

I have a question about whether or not there is a pipeline dependency when
disabling interrupts in the DSP56F80x devices (we use the DSP56F807).
Specifically, in the following instruction sequence:

X_Ram_Test_Loop:
// Disable interrupts during the following critical operations
move sr,r0
bfset #$200,sr
// Save the original RAM data in the N register
move x:(r3),n
// Write the inverse of the data to the RAM location
move n,y1
not y1
move y1,x:(r3)
// Test that the inverse data is in the RAM location
move x:(r3),x0
// If the inverse data is not OK, show the error
cmp y1,x0
bne X_Ram_Test_Error
// Write the original of the data to the RAM location
move n,y1
move y1,x:(r3)
// Test that the original data is in the RAM location
move x:(r3),x0
// If the original data is not OK, show the error
cmp y1,x0
bne X_Ram_Test_Error
// Re-enable interrupts, if they were enabled before
bftstl #$200,r0
bcc X_Ram_Test_Loop1
bfclr #$200,sr
X_Ram_Test_Loop1:
// If the RAM area is not all tested, test the next location
lea (r3)+
decw y0
bne X_Ram_Test_Loop
// Y0 = 0 = FALSE = All RAM was OK
// Point to the next memory to test
move r3,x:(r2 + RAM_TEST_CURR_ADDR_OFFSET )
rts

The above code is used to test all of Data (X) RAM for any bad locations, it
steps through all of X RAM and flags any bad locations.

We have found (by removing the call to this function) that execution of this
code has been responsible for occasional corruption of data that is changed in
Interrupt Service Routines (ISRs) in our programs. This can be explained if the
instruction:
move x:(r3),n
(which immediately follows the instruction that disables interrupts) is executed
BEFORE interrupts are disabled by the "bfset #$200,sr" instruction.

So, my question is this:
Is it necessary to put a nop instruction after the "bfset #$200,sr" instruction,
due to pipeline dependencies in the DSP56F80x chips, to ensure that interrupts
are disabled for the following instruction?

If the answer is yes, the above instruction sequence will need to be changed to:
bfset #$200,sr
nop
move x:(r3),n
to ensure that interrupts are disabled when the "move x:(r3),n" instruction is
executed.

Thanks in advance for your help.

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com



Thanks for this information, and also please have a look at the attached message
I received. It looks like at least one (and possibly more) NOP instructions are
required after disabling interrupts, before you can safely access any critical
data or registers. I also had another message from Greg Coonley at DSPOS on
this subject, so there seems to be a fair amount of evidence that this is a real
problem. I am now running some tests where I have put our "Memory Test"
function back into a couple of different systems, to see if the strange problems
we were having will come back. I will let you know when I have some results.

Regards,
Art -----Original Message-----
From: Yochum, William [mailto:]
Sent: Friday, March 28, 2003 11:48 AM
To: Art Johnson
Subject: RE: [motoroladsp] DSP56F80x question about a pipeline dependency when
disabling interrupts I'll be curious to see what kind of answer you get.

A pipeline dependency might explain a more esoteric strange problem (related to
interrupts) that I reported in a mail message to the [motoroladsp] list on
1/18/2003. See attached. -----Original Message-----
From: Art Johnson [mailto:]
Sent: Friday, March 28, 2003 12:48 PM
To:
Subject: [motoroladsp] DSP56F80x question about a pipeline dependency when
disabling interrupts Hello,

I have a question about whether or not there is a pipeline dependency when
disabling interrupts in the DSP56F80x devices (we use the DSP56F807).
Specifically, in the following instruction sequence:

X_Ram_Test_Loop:
// Disable interrupts during the following critical operations
move sr,r0
bfset #$200,sr
// Save the original RAM data in the N register
move x:(r3),n
// Write the inverse of the data to the RAM location
move n,y1
not y1
move y1,x:(r3)
// Test that the inverse data is in the RAM location
move x:(r3),x0
// If the inverse data is not OK, show the error
cmp y1,x0
bne X_Ram_Test_Error
// Write the original of the data to the RAM location
move n,y1
move y1,x:(r3)
// Test that the original data is in the RAM location
move x:(r3),x0
// If the original data is not OK, show the error
cmp y1,x0
bne X_Ram_Test_Error
// Re-enable interrupts, if they were enabled before
bftstl #$200,r0
bcc X_Ram_Test_Loop1
bfclr #$200,sr
X_Ram_Test_Loop1:
// If the RAM area is not all tested, test the next location
lea (r3)+
decw y0
bne X_Ram_Test_Loop
// Y0 = 0 = FALSE = All RAM was OK
// Point to the next memory to test
move r3,x:(r2 + RAM_TEST_CURR_ADDR_OFFSET )
rts

The above code is used to test all of Data (X) RAM for any bad locations, it
steps through all of X RAM and flags any bad locations.

We have found (by removing the call to this function) that execution of this
code has been responsible for occasional corruption of data that is changed in
Interrupt Service Routines (ISRs) in our programs. This can be explained if the
instruction:
move x:(r3),n
(which immediately follows the instruction that disables interrupts) is executed
BEFORE interrupts are disabled by the "bfset #$200,sr" instruction.

So, my question is this:
Is it necessary to put a nop instruction after the "bfset #$200,sr" instruction,
due to pipeline dependencies in the DSP56F80x chips, to ensure that interrupts
are disabled for the following instruction?

If the answer is yes, the above instruction sequence will need to be changed to:
bfset #$200,sr
nop
move x:(r3),n
to ensure that interrupts are disabled when the "move x:(r3),n" instruction is
executed.

Thanks in advance for your help.

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com

_____________________________________
Note: If you do a simple "reply" with your email client, only the author of this
message will receive your answer. You need to do a "reply all" if you want your
answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:

To Post:

To Leave:

Archives: http://www.yahoogroups.com/group/motoroladsp

More Groups: http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/> .


RE: [motoroladsp] DSP56F80x question about a pipeline dependency when disabling interrupts

I have been using 1 nop or other instruction before the move of critical data.  Don't remember reading that anywhere, but inspected my code.  Perhaps I observed a problem along the way, and may have just done it since I have been used to seeing that problem on the 80x86 family in the past.

Jerry.

> -----Original Message-----
> From: Art Johnson [mailto:a...@pmc-controls.com]
> Sent: Friday, March 28, 2003 11:48 AM
> To: m...@yahoogroups.com
> Subject: [motoroladsp] DSP56F80x question about a pipeline dependency
> when disabling interrupts
>
>
> Hello,
>
> I have a question about whether or not there is a pipeline
> dependency when disabling interrupts in the DSP56F80x devices
> (we use the DSP56F807).  Specifically, in the following
> instruction sequence:
>
> X_Ram_Test_Loop:
>   // Disable interrupts during the following critical operations
>   move     sr,r0
>   bfset    #$200,sr
>   // Save the original RAM data in the N register
>   move     x:(r3),n
>   // Write the inverse of the data to the RAM location
>   move     n,y1
>   not      y1
>   move     y1,x:(r3)
>   // Test that the inverse data is in the RAM location
>   move     x:(r3),x0
>   // If the inverse data is not OK, show the error
>   cmp      y1,x0
>   bne      X_Ram_Test_Error
>   // Write the original of the data to the RAM location
>   move     n,y1
>   move     y1,x:(r3)
>   // Test that the original data is in the RAM location
>   move     x:(r3),x0
>   // If the original data is not OK, show the error
>   cmp      y1,x0
>   bne      X_Ram_Test_Error
>   // Re-enable interrupts, if they were enabled before
>   bftstl   #$200,r0
>   bcc      X_Ram_Test_Loop1
>   bfclr    #$200,sr
> X_Ram_Test_Loop1:
>   // If the RAM area is not all tested, test the next location
>   lea      (r3)+
>   decw     y0
>   bne      X_Ram_Test_Loop
>   // Y0 = 0 = FALSE = All RAM was OK
>   // Point to the next memory to test
>   move     r3,x:(r2 + RAM_TEST_CURR_ADDR_OFFSET )
>   rts
>
> The above code is used to test all of Data (X) RAM for any
> bad locations, it steps through all of X RAM and flags any
> bad locations.
>
> We have found (by removing the call to this function) that
> execution of this code has been responsible for occasional
> corruption of data that is changed in Interrupt Service
> Routines (ISRs) in our programs.  This can be explained if
> the instruction:
>   move     x:(r3),n
> (which immediately follows the instruction that disables
> interrupts) is executed BEFORE interrupts are disabled by the
> "bfset #$200,sr" instruction.
>
> So, my question is this:
> Is it necessary to put a nop instruction after the "bfset
> #$200,sr" instruction, due to pipeline dependencies in the
> DSP56F80x chips, to ensure that interrupts are disabled for
> the following instruction?
>
> If the answer is yes, the above instruction sequence will
> need to be changed to:
>   bfset  #$200,sr
>   nop
>   move   x:(r3),n
> to ensure that interrupts are disabled when the "move
> x:(r3),n" instruction is executed.
>
> Thanks in advance for your help.
>
> Regards,
>
> Art Johnson
> Senior Systems Analyst
> PMC Prime Mover Controls Inc.
> 3600 Gilmore Way
> Burnaby, B.C., Canada
> V5G 4R8
> Phone:  604 433-4644
> FAX:    604 433-5570
> Email:  a...@pmc-controls.com
> http://www.pmc-controls.com
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Make Money Online Auctions! Make $500.00 or We Will Give You
> Thirty Dollars for Trying!
> http://us.click.yahoo.com/yMx78A/fNtFAA/46VHAA/PNArlB/TM
> --------------------------
> -------~->
>
> _____________________________________
> Note: If you do a simple "reply" with your email client, only
> the author of this message will receive your answer.  You
> need to do a "reply all" if you want your answer to be
> distributed to the entire group.
>
> _____________________________________
> About this discussion group:
>
> To Join:  m...@yahoogroups.com
>
> To Post:  m...@yahoogroups.com
>
> To Leave: m...@yahoogroups.com
>
> Archives: http://www.yahoogroups.com/group/motoroladsp
>
> More Groups: http://www.dsprelated.com/groups.php3

>
> " TARGET="_blank">http://docs.yahoo.com/info/terms/



________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information visit http://www.messagelabs.com
________________________________________________________________________


________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information visit http://www.messagelabs.com
________________________________________________________________________
Hello,

In order to see if NOP instructions after the "bfset #$200,sr" instruction would
fix the problems we were having, I ran tests over the weekend on the following
systems:
- 2 systems without the Memory Test function
- 2 systems with the "bad" Memory Test function
- 2 systems with the "good" Memory Test function

The only difference between the "bad" and "good" Memory Test functions, is the
insertion of 4 NOPs just after the "bfset #$200,sr" instruction that disables
the interrupts.

The results of the tests are as follows:
- 2 systems without the Memory Test function - OK
- 2 systems with the "bad" Memory Test function - Failed
- 2 systems with the "good" Memory Test function - OK

These tests show that it is necessary to insert NOP instructions immediately
after the "bfset #$200,sr" instruction that disables the interrupts, to ensure
that interrupts are disabled before testing or changing any critical data. We
used 4 NOP instructions, as is suggested in Section 7.2.3 "Instruction Pipeline
Dependencies and Interlocks" in the DSP56800 16-Bit Digital Signal Processor
Family Manual (DSP56800FM/D Rev. 2.0, 05/2002).

It should be noted that I have seen this code sequence (ie the "bfset #$200,sr"
instruction immediately followed by testing or changing critical data) in all
libraries I have looked at.

I think it would be very useful, if Motorola could provide a list of exactly
which instructions and addressing modes are affected by the pipeline
dependencies in the DSP56F80x devices. I have looked in the latest versions of
both the DSP56800 Family Manual, and the DSP56F80x User's Manual, and I have not
found this information. There are some examples in the DSP56800 Family Manual
Section 4.4 "Pipeline Dependencies", and in Section 7.2.3 "Instruction Pipeline
Dependencies and Interlocks", but I cannot find a complete list of these
dependencies. It is left up to the user to make an educated guess about whether
or not a pipeline dependency may be causing a problem, and to test this theory
by inserting 4 NOP instructions to see if this fixes the problem.

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com




Hello at all!

about the following statement:
> These tests show that it is necessary to insert NOP instructions
immediately after the "bfset #$200,sr" instruction that disables the
interrupts, to ensure that interrupts are disabled before testing or
changing any critical data.

I've just discovered that I need to add also a nop after the
interrupt enable (bfclr #$200,sr) to make work my project.

Maybe the problem is that the following instructions are the COP
reset... bah.
I'm working with the DSP56F803 since August 2000 and yet today I'm
discovering new problems.
I'm not very happy...

regards.
M.Cardin