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 |
|
DSP56F80x question about a pipeline dependency when disabling interrupts
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-----
________________________________________________________________________
________________________________________________________________________ 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 |