|
I have another beginner SDK question, after searching the Yahoo archive
and all the manuals that seemed relevant. I seemed to have found an answer, but it didn't seem to work, nor did any of the variations I tried. I'm trying to disable nested interrupts in the SDK. I have some "impossible" code behavior, and thought it might be due to nested interrupts changing the Z bit in the status register behind my back. Although I'm trying to block nested IRQs, bits [9:8] in the SR are always 0x01, which seem to enable maskable IRQs (though perhaps the NestedIPRMask is blocking them). I see it is the I-one bit (not the I-zero bit as I thought before) that masks all interrupts except NMIs. I've tried these three lines (one at a time, of course) in my appconfig.h for RAM, and FLASH, as the first changed line: #DEFINE USE_NESTED_INTERRUPTS NO #undef USE_NESTED_INTERRUPTS #DEFINE USE_NESTED_INTERRUPTS YES Below them, I have these lines: #define GPR_INT_PRIORITY_14 4 // MSCAN Tx Ready TXEIE #define GPR_INT_PRIORITY_15 5 // MSCAN Rx Ready RXFIE void ISR_CAN_Transmit(void); // Thanks, MotoDSP group! void ISR_CAN_Receive( void); #define NORMAL_ISR_14 ISR_CAN_Transmit // no "F"! #define NORMAL_ISR_15 ISR_CAN_Receive Does " #DEFINE USE_NESTED_INTERRUPTS NO" work for other people here? Should I also poke configNestedIPRmask[ ] manually? Does USE_NESTED_INTERRUPTS affect only the IPR masks and not the status register I-one bit (bit #9)? Thanks again for your help, people. Rick Corey - - - - - The reason I'm concerned about nested IRQs is that I can go to mixed mode and watch what seems to be wrong behavior for TSTW or BNE (see mixed display at the end of the email). At the source level, *both* DoA and DoB would run. if (ptr == NULL) { DoA } if (ptr != NULL) { DoB } Elsewhere in my code (like, outside ISRs), the test (ptr == NULL) seems to work OK. I would always execute DoA whether the pointer was zero or not. I would execute both DoA and DoB on the same pass through the code, if the ptr was non-zero, and I wasn't modifying the pointer in DoA. Just 2-3 times, I saw correct behavior, right after I first added the line #DEFINE USE_NESTED_INTERRUPTS YES However, that behavior "went away". Also, if anything, this should turn nesting ON. I could watch BNE branch the same way whether the pointer was 0 or $20A3. The sr.Z bit was always set in those tests, but I could see it go to 0 after the != test (watching only source level). I don't completely believe that I'm seeing what I'm seeing, so please don't take my word for it. After I'm sure I have nested IRQs blocked I'll report again. real source code: volatile struct CanPktBuffer *psTmpDbgPtr; volatile struct CanPktBuffer *psPRLL_ListHead=NULL; . . . . if (psTmpDbgPtr == NULL) { psPRLL_ListHead = *ppsPktToInsert; // DoA } // there is no "else" here if ( psTmpDbgPtr != NULL ) { // DoB while ( ( psInsertHere->pnext != NULL ) && ( psInsertHere->pnext->DataByte[PACKET_LEN] < (*ppsPktToInsert)->DataByte[PACKET_LEN] ) ) { psInsertHere = psInsertHere->pnext; } etc etc } I started out with a simpler: If ( psPRLL_ListHead == NULL) { DoA } else { DoB } and then inserted the TmpPtr, and removed the else, switched the order of the ptr and the NULL, in desperation. real mixed mode: psTmpDbgPtr = psPRLL_ListHead; P:000002DA: F8542052 move X:0x2052,R0 P:000002DC: 9832 moves R0,X:0x0032 if (psTmpDbgPtr == NULL) P:000002DD: BE32 tstw X:0x0032 P:000002DE: A203 bne AddPktToPRLL+0x9 (0x2e2); 0x000173 { psPRLL_ListHead = *ppsPktToInsert; P:000002DF: F816 move X:(R2),R0 P:000002E0: D8542052 move R0,X:0x2052 } if ( psTmpDbgPtr != NULL ) P:000002E2: BE32 tstw X:0x0032 P:000002E3: A319 beq AddPktToPRLL+0x24 (0x2fd); 0x00018b { // walk the ToTxList to insert in order or at end while ( ( psInsertHere->pnext != NULL ) && P:000002E4: A903 bra AddPktToPRLL+0xf (0x2e8); 0x000176 ( psInsertHere->pnext->DataByte[PACKET_LEN] < (*ppsPktToInsert)->DataByte[PACKET_LEN] ) ) { psInsertHere = psInsertHere->pnext; P:000002E5: FB43000F move X:(R3+0x000f),R3 P:000002E7: E040 nop } P:000002E8: FE43000F tstw X:(R3+0x000f) P:000002EA: A309 beq AddPktToPRLL+0x1b (0x2f4); 0x00017f P:000002EB: F843000F move X:(R3+0x000f),R0 P:000002ED: F916 move X:(R2),R1 P:000002EE: F1400004 move X:(R0+0x0004),Y0 P:000002F0: F0410004 move X:(R1+0x0004),X0 P:000002F2: 7C43 cmp X0,Y0 P:000002F3: A171 bcs AddPktToPRLL+0xc (0x2e5); 0x00016b Rick Corey, Software Development DPC Instrument Systems Division, Flanders NJ |
|
|
USE_NESTED_INTERRUPTS
Started by ●October 12, 2002
Reply by ●October 15, 20022002-10-15
|
Unfortunately, our documentation is wrong. You will not find a single instance of USE_NESTED_INTERRUPTS in the SDK source files. To turn nested interrupts off, you will have to open dispatcher.asm file located in the sys directory, and modify the following line of code: define SUPPORT_NESTED_INTERRUPTS '1' You will have to change 1 to 0. I am not sure why SDK implementation doesn't allow configuration of this parameter via appconfig.h, while SDK documentation talks about it, and I apologize for any confusion it caused. Sincerely, Leonard N. Elevich Motorola DSPO -----Original Message----- From: Corey, Rick [mailto:] Sent: Saturday, October 12, 2002 2:43 PM To: Motodsp (E-mail) Cc: Nickerson, Steve Subject: [motoroladsp] USE_NESTED_INTERRUPTS I have another beginner SDK question, after searching the Yahoo archive and all the manuals that seemed relevant. I seemed to have found an answer, but it didn't seem to work, nor did any of the variations I tried. I'm trying to disable nested interrupts in the SDK. I have some "impossible" code behavior, and thought it might be due to nested interrupts changing the Z bit in the status register behind my back. Although I'm trying to block nested IRQs, bits [9:8] in the SR are always 0x01, which seem to enable maskable IRQs (though perhaps the NestedIPRMask is blocking them). I see it is the I-one bit (not the I-zero bit as I thought before) that masks all interrupts except NMIs. I've tried these three lines (one at a time, of course) in my appconfig.h for RAM, and FLASH, as the first changed line: #DEFINE USE_NESTED_INTERRUPTS NO #undef USE_NESTED_INTERRUPTS #DEFINE USE_NESTED_INTERRUPTS YES Below them, I have these lines: #define GPR_INT_PRIORITY_14 4 // MSCAN Tx Ready TXEIE #define GPR_INT_PRIORITY_15 5 // MSCAN Rx Ready RXFIE void ISR_CAN_Transmit(void); // Thanks, MotoDSP group! void ISR_CAN_Receive( void); #define NORMAL_ISR_14 ISR_CAN_Transmit // no "F"! #define NORMAL_ISR_15 ISR_CAN_Receive Does " #DEFINE USE_NESTED_INTERRUPTS NO" work for other people here? Should I also poke configNestedIPRmask[ ] manually? Does USE_NESTED_INTERRUPTS affect only the IPR masks and not the status register I-one bit (bit #9)? Thanks again for your help, people. Rick Corey - - - - - The reason I'm concerned about nested IRQs is that I can go to mixed mode and watch what seems to be wrong behavior for TSTW or BNE (see mixed display at the end of the email). At the source level, *both* DoA and DoB would run. if (ptr == NULL) { DoA } if (ptr != NULL) { DoB } Elsewhere in my code (like, outside ISRs), the test (ptr == NULL) seems to work OK. I would always execute DoA whether the pointer was zero or not. I would execute both DoA and DoB on the same pass through the code, if the ptr was non-zero, and I wasn't modifying the pointer in DoA. Just 2-3 times, I saw correct behavior, right after I first added the line #DEFINE USE_NESTED_INTERRUPTS YES However, that behavior "went away". Also, if anything, this should turn nesting ON. I could watch BNE branch the same way whether the pointer was 0 or $20A3. The sr.Z bit was always set in those tests, but I could see it go to 0 after the != test (watching only source level). I don't completely believe that I'm seeing what I'm seeing, so please don't take my word for it. After I'm sure I have nested IRQs blocked I'll report again. real source code: volatile struct CanPktBuffer *psTmpDbgPtr; volatile struct CanPktBuffer *psPRLL_ListHead=NULL; . . . . if (psTmpDbgPtr == NULL) { psPRLL_ListHead = *ppsPktToInsert; // DoA } // there is no "else" here if ( psTmpDbgPtr != NULL ) { // DoB while ( ( psInsertHere->pnext != NULL ) && ( psInsertHere->pnext->DataByte[PACKET_LEN] < (*ppsPktToInsert)->DataByte[PACKET_LEN] ) ) { psInsertHere = psInsertHere->pnext; } etc etc } I started out with a simpler: If ( psPRLL_ListHead == NULL) { DoA } else { DoB } and then inserted the TmpPtr, and removed the else, switched the order of the ptr and the NULL, in desperation. real mixed mode: psTmpDbgPtr = psPRLL_ListHead; P:000002DA: F8542052 move X:0x2052,R0 P:000002DC: 9832 moves R0,X:0x0032 if (psTmpDbgPtr == NULL) P:000002DD: BE32 tstw X:0x0032 P:000002DE: A203 bne AddPktToPRLL+0x9 (0x2e2); 0x000173 { psPRLL_ListHead = *ppsPktToInsert; P:000002DF: F816 move X:(R2),R0 P:000002E0: D8542052 move R0,X:0x2052 } if ( psTmpDbgPtr != NULL ) P:000002E2: BE32 tstw X:0x0032 P:000002E3: A319 beq AddPktToPRLL+0x24 (0x2fd); 0x00018b { // walk the ToTxList to insert in order or at end while ( ( psInsertHere->pnext != NULL ) && P:000002E4: A903 bra AddPktToPRLL+0xf (0x2e8); 0x000176 ( psInsertHere->pnext->DataByte[PACKET_LEN] < (*ppsPktToInsert)->DataByte[PACKET_LEN] ) ) { psInsertHere = psInsertHere->pnext; P:000002E5: FB43000F move X:(R3+0x000f),R3 P:000002E7: E040 nop } P:000002E8: FE43000F tstw X:(R3+0x000f) P:000002EA: A309 beq AddPktToPRLL+0x1b (0x2f4); 0x00017f P:000002EB: F843000F move X:(R3+0x000f),R0 P:000002ED: F916 move X:(R2),R1 P:000002EE: F1400004 move X:(R0+0x0004),Y0 P:000002F0: F0410004 move X:(R1+0x0004),X0 P:000002F2: 7C43 cmp X0,Y0 P:000002F3: A171 bcs AddPktToPRLL+0xc (0x2e5); 0x00016b Rick Corey, Software Development DPC Instrument Systems Division, Flanders NJ _____________________________________ 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/ |
|
|
Reply by ●October 15, 20022002-10-15
|
One more clarification about our documentation being wrong. After reading this portion of the documentation more carefully, you will find that it doesn’t talk about some global macro that you can use to toggle nested interrupts in the SDK. This example defines this macro in the appconfig.h for local use only. So SDK documentation is correct. And you have to use method that I have described in my previous email to disable nested interrupts.
There is however, another way for you to disable nested interrupts. If you define all interrupts to be the same priority:
#define
GPR_INT_PRIORITY_14
4 // MSCAN Tx Ready
TXEIE
SDK should disable nested interrupts for you automatically. The only time SDK re-enables interrupts (uses nested interrupts), is when you use different interrupt priorities (as in your example).
I still think that example in our documentation is some what misleading (I misread it just like you), unless you read it very carefully.
Leonard
-----Original
Message-----
Unfortunately,
our documentation is wrong. You will
not find a single 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 ">Yahoo! Terms of Service. |
Reply by ●October 15, 20022002-10-15
|
Thanks for the help and frankness, Leonard. If I get this working, I'll take out my workarounds and reply to the group "that worked". However, I have to chase another frustrating problem first. Rick Corey P.S. Is there a way to generate pre-processor output? I'm disenheartened and frustrated again; trying to compile from the SDK for FLASH instead of external RAM is giving me five compiler errors in config.h, which I don't feel very safe in modifying. Should we #define INCLUDE_FLASH just to download to FLASH? Surely not. We can download to FLASH all day in the non-SDK projects we've built. "preceding #if is missing config.h line 2381 #endif" We've gone through 2,381 lines of config.h without finding why #ifdef and #ifndef might get unmatched when we go from RAM to FLASH. as far as we can tell, the .H files we have looked at seem to have matching numbers of #ifdef + #ifndef and #endif ... as far as we can tell, which only goes so far due to the conditional degree of nesting of includes and #if s. We assume that some #define somewhere is interfering with the SDK config/appconfig mechanism. I am trying to use the SDK interrupt dispatcher for two non-driver interrupts - CAN IRQs without the CAN driver. Of course I am not #define - ing INCLUDE_CAN because we aren't/can't use the CAN driver as it is. -----Original Message----- From: Leonard N. Elevich [mailto:] Sent: Monday, October 14, 2002 7:45 PM To: 'Corey, Rick'; 'Motodsp (E-mail)' Cc: 'Nickerson, Steve' Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS One more clarification about our documentation being wrong. After reading this portion of the documentation more carefully, you will find that it doesn't talk about some global macro that you can use to toggle nested interrupts in the SDK. This example defines this macro in the appconfig.h for local use only. So SDK documentation is correct. And you have to use method that I have described in my previous email to disable nested interrupts. There is however, another way for you to disable nested interrupts. If you define all interrupts to be the same priority: #define GPR_INT_PRIORITY_14 4 // MSCAN Tx Ready TXEIE #define GPR_INT_PRIORITY_15 4 // MSCAN Rx Ready RXFIE SDK should disable nested interrupts for you automatically. The only time SDK re-enables interrupts (uses nested interrupts), is when you use different interrupt priorities (as in your example). I still think that example in our documentation is some what misleading (I misread it just like you), unless you read it very carefully. Leonard -----Original Message----- From: Leonard N. Elevich [mailto:] Sent: Monday, October 14, 2002 4:31 PM To: 'Corey, Rick'; 'Motodsp (E-mail)' Cc: 'Nickerson, Steve' Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS Unfortunately, our documentation is wrong. You will not find a single instance of USE_NESTED_INTERRUPTS in the SDK source files. To turn nested interrupts off, you will have to open dispatcher.asm file located in the sys directory, and modify the following line of code: define SUPPORT_NESTED_INTERRUPTS '1' You will have to change 1 to 0. I am not sure why SDK implementation doesn't allow configuration of this parameter via appconfig.h, while SDK documentation talks about it, and I apologize for any confusion it caused. Sincerely, Leonard N. Elevich Motorola DSPO -----Original Message----- From: Corey, Rick [mailto:] Sent: Saturday, October 12, 2002 2:43 PM To: Motodsp (E-mail) Cc: Nickerson, Steve Subject: [motoroladsp] USE_NESTED_INTERRUPTS I have another beginner SDK question, after searching the Yahoo archive and all the manuals that seemed relevant. I seemed to have found an answer, but it didn't seem to work, nor did any of the variations I tried. I'm trying to disable nested interrupts in the SDK. I have some "impossible" code behavior, and thought it might be due to nested interrupts changing the Z bit in the status register behind my back. Although I'm trying to block nested IRQs, bits [9:8] in the SR are always 0x01, which seem to enable maskable IRQs (though perhaps the NestedIPRMask is blocking them). I see it is the I-one bit (not the I-zero bit as I thought before) that masks all interrupts except NMIs. I've tried these three lines (one at a time, of course) in my appconfig.h for RAM, and FLASH, as the first changed line: #DEFINE USE_NESTED_INTERRUPTS NO #undef USE_NESTED_INTERRUPTS #DEFINE USE_NESTED_INTERRUPTS YES Below them, I have these lines: #define GPR_INT_PRIORITY_14 4 // MSCAN Tx Ready TXEIE #define GPR_INT_PRIORITY_15 5 // MSCAN Rx Ready RXFIE void ISR_CAN_Transmit(void); // Thanks, MotoDSP group! void ISR_CAN_Receive( void); #define NORMAL_ISR_14 ISR_CAN_Transmit // no "F"! #define NORMAL_ISR_15 ISR_CAN_Receive Does " #DEFINE USE_NESTED_INTERRUPTS NO" work for other people here? Should I also poke configNestedIPRmask[ ] manually? Does USE_NESTED_INTERRUPTS affect only the IPR masks and not the status register I-one bit (bit #9)? Thanks again for your help, people. Rick Corey - - - - - The reason I'm concerned about nested IRQs is that I can go to mixed mode and watch what seems to be wrong behavior for TSTW or BNE (see mixed display at the end of the email). At the source level, *both* DoA and DoB would run. if (ptr == NULL) { DoA } if (ptr != NULL) { DoB } Elsewhere in my code (like, outside ISRs), the test (ptr == NULL) seems to work OK. I would always execute DoA whether the pointer was zero or not. I would execute both DoA and DoB on the same pass through the code, if the ptr was non-zero, and I wasn't modifying the pointer in DoA. Just 2-3 times, I saw correct behavior, right after I first added the line #DEFINE USE_NESTED_INTERRUPTS YES However, that behavior "went away". Also, if anything, this should turn nesting ON. I could watch BNE branch the same way whether the pointer was 0 or $20A3. The sr.Z bit was always set in those tests, but I could see it go to 0 after the != test (watching only source level). I don't completely believe that I'm seeing what I'm seeing, so please don't take my word for it. After I'm sure I have nested IRQs blocked I'll report again. real source code: volatile struct CanPktBuffer *psTmpDbgPtr; volatile struct CanPktBuffer *psPRLL_ListHead=NULL; . . . . if (psTmpDbgPtr == NULL) { psPRLL_ListHead = *ppsPktToInsert; // DoA } // there is no "else" here if ( psTmpDbgPtr != NULL ) { // DoB while ( ( psInsertHere->pnext != NULL ) && ( psInsertHere->pnext->DataByte[PACKET_LEN] < (*ppsPktToInsert)->DataByte[PACKET_LEN] ) ) { psInsertHere = psInsertHere->pnext; } etc etc } I started out with a simpler: If ( psPRLL_ListHead == NULL) { DoA } else { DoB } and then inserted the TmpPtr, and removed the else, switched the order of the ptr and the NULL, in desperation. real mixed mode: psTmpDbgPtr = psPRLL_ListHead; P:000002DA: F8542052 move X:0x2052,R0 P:000002DC: 9832 moves R0,X:0x0032 if (psTmpDbgPtr == NULL) P:000002DD: BE32 tstw X:0x0032 P:000002DE: A203 bne AddPktToPRLL+0x9 (0x2e2); 0x000173 { psPRLL_ListHead = *ppsPktToInsert; P:000002DF: F816 move X:(R2),R0 P:000002E0: D8542052 move R0,X:0x2052 } if ( psTmpDbgPtr != NULL ) P:000002E2: BE32 tstw X:0x0032 P:000002E3: A319 beq AddPktToPRLL+0x24 (0x2fd); 0x00018b { // walk the ToTxList to insert in order or at end while ( ( psInsertHere->pnext != NULL ) && P:000002E4: A903 bra AddPktToPRLL+0xf (0x2e8); 0x000176 ( psInsertHere->pnext->DataByte[PACKET_LEN] < (*ppsPktToInsert)->DataByte[PACKET_LEN] ) ) { psInsertHere = psInsertHere->pnext; P:000002E5: FB43000F move X:(R3+0x000f),R3 P:000002E7: E040 nop } P:000002E8: FE43000F tstw X:(R3+0x000f) P:000002EA: A309 beq AddPktToPRLL+0x1b (0x2f4); 0x00017f P:000002EB: F843000F move X:(R3+0x000f),R0 P:000002ED: F916 move X:(R2),R1 P:000002EE: F1400004 move X:(R0+0x0004),Y0 P:000002F0: F0410004 move X:(R1+0x0004),X0 P:000002F2: 7C43 cmp X0,Y0 P:000002F3: A171 bcs AddPktToPRLL+0xc (0x2e5); 0x00016b Rick Corey, Software Development DPC Instrument Systems Division, Flanders NJ _____________________________________ 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 <http://www.yahoogroups.com/group/motoroladsp> More Groups: http://www.dsprelated.com/groups.php3 <http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/ _____________________________________ 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 <http://www.yahoogroups.com/group/motoroladsp> More Groups: http://www.dsprelated.com/groups.php3 <http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/> Terms of Service. <http://rd.yahoo.com/M!9695.2310151.3725769.2113459/D=egroupweb/S057718 55:HM/A26184/R=0/*http://ad.doubleclick.net/jump/N879.ameritrade.yahoo/B1 054521.11;sz00x250;adc=ZHS;ord34639144?> <http://us.adserver.yahoo.com/l?M!9695.2310151.3725769.2113459/D=egroupmai l/S=:HM/A26184/randT3408226> _____________________________________ 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 <http://www.yahoogroups.com/group/motoroladsp> More Groups: http://www.dsprelated.com/groups.php3 <http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/> . |
|
|
Reply by ●October 15, 20022002-10-15
|
OK, I see it now. The documentation says that code example 4-1 (page 4-3 of SDK Targeting 803 Manual) "shows how nesting MIGHT BE turned on and off." The example shows how a #define might be used in user code to set all IRQ priority levels to "1", in user code. I see that the key part of the code example is the "1" priority, not #defining anything. I also see "If any interrupt is defined to have a priority greater than one, then ... compiled to enable nested interrupts." I'll try, first, setting all my priorities to '1". Thanks again. Rick Corey -----Original Message----- From: Leonard N. Elevich [mailto:] Sent: Monday, October 14, 2002 7:45 PM To: 'Corey, Rick'; 'Motodsp (E-mail)' Cc: 'Nickerson, Steve' Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS One more clarification about our documentation being wrong. After reading this portion of the documentation more carefully, you will find that it doesn't talk about some global macro that you can use to toggle nested interrupts in the SDK. This example defines this macro in the appconfig.h for local use only. So SDK documentation is correct. And you have to use method that I have described in my previous email to disable nested interrupts. There is however, another way for you to disable nested interrupts. If you define all interrupts to be the same priority: #define GPR_INT_PRIORITY_14 4 // MSCAN Tx Ready TXEIE #define GPR_INT_PRIORITY_15 4 // MSCAN Rx Ready RXFIE SDK should disable nested interrupts for you automatically. The only time SDK re-enables interrupts (uses nested interrupts), is when you use different interrupt priorities (as in your example). I still think that example in our documentation is some what misleading (I misread it just like you), unless you read it very carefully. Leonard [Corey, Rick] < big snip |
Reply by ●October 15, 20022002-10-15
|
You don’t need to use SDK’s INCLUDE_FLASH to target your application into Flash.
I would be glad to help you figure out your preprocessor problem. If you can send me your project (zipped) as is, or trim it down to bare code as long as problem is still there, I will take a look at it.
As far as generation of the pre-processor output, I am not aware of any options that you can give to CodeWarrior to force the output.
Leonard
-----Original
Message-----
Thanks for the help and frankness, Leonard.
If I get this working, I'll take out my workarounds and reply to the group "that worked". However, I have to chase another frustrating problem first.
Rick Corey
P.S. Is there a way to generate pre-processor output?
I'm disenheartened and frustrated again; trying to compile from the SDK for FLASH instead of external RAM is giving me five compiler errors in config.h, which I don't feel very safe in modifying. Should we #define INCLUDE_FLASH just to download to FLASH? Surely not. We can download to FLASH all day in the non-SDK projects we've built.
"preceding #if is missing config.h line 2381 #endif"
We've gone through 2,381 lines of config.h without finding why #ifdef and #ifndef might get unmatched when we go from RAM to FLASH. as far as we can tell, the .H files we have looked at seem to have matching numbers of #ifdef + #ifndef and #endif ... as far as we can tell, which only goes so far due to the conditional degree of nesting of includes and #if s.
We assume that some #define somewhere is interfering with the SDK config/appconfig mechanism.
I am trying to use the SDK interrupt dispatcher for two non-driver interrupts - CAN IRQs without the CAN driver. Of course I am not #define - ing INCLUDE_CAN because we aren't/can't use the CAN driver as it is.
|
Reply by ●October 15, 20022002-10-15
|
Leonard, You are right. I must have pasted an extra #endif into that file days ago, and never noticed, because I didn't use it until just now. Thank you! (putting on a Dunce Cap and sitting in the corner) Rick Corey -----Original Message----- From: Leonard N. Elevich [mailto:] Sent: Tuesday, October 15, 2002 1:45 PM To: 'Corey, Rick' Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS Rick, in your appconfig.h file for flash configuration you have an extra #endif at the end of the file. Since this file is included in the config.h, preprocessor gives you error for config.h file. Once I removed extra #endif in your appconfig.h file, your project compiled fine. Leonard -----Original Message----- From: Corey, Rick [mailto:] Sent: Tuesday, October 15, 2002 9:49 AM To: 'Leonard N. Elevich' Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS Thank you! I really appreciate this. Maybe I'm just worn down by missing deadlines and working weekends and evenings, yet making no progress. I've tried re-installing the SDK, then got called over to put out another fire. Here's the project - oh please tell me that I did something amazingly stupid! Rick Corey -----Original Message----- From: Leonard N. Elevich [mailto:] Sent: Tuesday, October 15, 2002 12:13 PM To: 'Corey, Rick'; 'Motodsp (E-mail)' Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS You don't need to use SDK's INCLUDE_FLASH to target your application into Flash. I would be glad to help you figure out your preprocessor problem. If you can send me your project (zipped) as is, or trim it down to bare code as long as problem is still there, I will take a look at it. As far as generation of the pre-processor output, I am not aware of any options that you can give to CodeWarrior to force the output. Leonard -----Original Message----- From: Corey, Rick [mailto:] Sent: Tuesday, October 15, 2002 8:00 AM To: 'Leonard N. Elevich'; Motodsp (E-mail) Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS Thanks for the help and frankness, Leonard. If I get this working, I'll take out my workarounds and reply to the group "that worked". However, I have to chase another frustrating problem first. Rick Corey P.S. Is there a way to generate pre-processor output? I'm disenheartened and frustrated again; trying to compile from the SDK for FLASH instead of external RAM is giving me five compiler errors in config.h, which I don't feel very safe in modifying. Should we #define INCLUDE_FLASH just to download to FLASH? Surely not. We can download to FLASH all day in the non-SDK projects we've built. "preceding #if is missing config.h line 2381 #endif" We've gone through 2,381 lines of config.h without finding why #ifdef and #ifndef might get unmatched when we go from RAM to FLASH. as far as we can tell, the .H files we have looked at seem to have matching numbers of #ifdef + #ifndef and #endif ... as far as we can tell, which only goes so far due to the conditional degree of nesting of includes and #if s. We assume that some #define somewhere is interfering with the SDK config/appconfig mechanism. I am trying to use the SDK interrupt dispatcher for two non-driver interrupts - CAN IRQs without the CAN driver. Of course I am not #define - ing INCLUDE_CAN because we aren't/can't use the CAN driver as it is. -----Original Message----- From: Leonard N. Elevich [mailto:] Sent: Monday, October 14, 2002 7:45 PM To: 'Corey, Rick'; 'Motodsp (E-mail)' Cc: 'Nickerson, Steve' Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS One more clarification about our documentation being wrong. After reading this portion of the documentation more carefully, you will find that it doesn't talk about some global macro that you can use to toggle nested interrupts in the SDK. This example defines this macro in the appconfig.h for local use only. So SDK documentation is correct. And you have to use method that I have described in my previous email to disable nested interrupts. There is however, another way for you to disable nested interrupts. If you define all interrupts to be the same priority: #define GPR_INT_PRIORITY_14 4 // MSCAN Tx Ready TXEIE #define GPR_INT_PRIORITY_15 4 // MSCAN Rx Ready RXFIE SDK should disable nested interrupts for you automatically. The only time SDK re-enables interrupts (uses nested interrupts), is when you use different interrupt priorities (as in your example). I still think that example in our documentation is some what misleading (I misread it just like you), unless you read it very carefully. Leonard -----Original Message----- From: Leonard N. Elevich [mailto:] Sent: Monday, October 14, 2002 4:31 PM To: 'Corey, Rick'; 'Motodsp (E-mail)' Cc: 'Nickerson, Steve' Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS Unfortunately, our documentation is wrong. You will not find a single instance of USE_NESTED_INTERRUPTS in the SDK source files. To turn nested interrupts off, you will have to open dispatcher.asm file located in the sys directory, and modify the following line of code: define SUPPORT_NESTED_INTERRUPTS '1' You will have to change 1 to 0. I am not sure why SDK implementation doesn't allow configuration of this parameter via appconfig.h, while SDK documentation talks about it, and I apologize for any confusion it caused. Sincerely, Leonard N. Elevich Motorola DSPO -----Original Message----- From: Corey, Rick [mailto:] Sent: Saturday, October 12, 2002 2:43 PM To: Motodsp (E-mail) Cc: Nickerson, Steve Subject: [motoroladsp] USE_NESTED_INTERRUPTS I have another beginner SDK question, after searching the Yahoo archive and all the manuals that seemed relevant. I seemed to have found an answer, but it didn't seem to work, nor did any of the variations I tried. I'm trying to disable nested interrupts in the SDK. I have some "impossible" code behavior, and thought it might be due to nested interrupts changing the Z bit in the status register behind my back. Although I'm trying to block nested IRQs, bits [9:8] in the SR are always 0x01, which seem to enable maskable IRQs (though perhaps the NestedIPRMask is blocking them). I see it is the I-one bit (not the I-zero bit as I thought before) that masks all interrupts except NMIs. I've tried these three lines (one at a time, of course) in my appconfig.h for RAM, and FLASH, as the first changed line: #DEFINE USE_NESTED_INTERRUPTS NO #undef USE_NESTED_INTERRUPTS #DEFINE USE_NESTED_INTERRUPTS YES Below them, I have these lines: #define GPR_INT_PRIORITY_14 4 // MSCAN Tx Ready TXEIE #define GPR_INT_PRIORITY_15 5 // MSCAN Rx Ready RXFIE void ISR_CAN_Transmit(void); // Thanks, MotoDSP group! void ISR_CAN_Receive( void); #define NORMAL_ISR_14 ISR_CAN_Transmit // no "F"! #define NORMAL_ISR_15 ISR_CAN_Receive Does " #DEFINE USE_NESTED_INTERRUPTS NO" work for other people here? Should I also poke configNestedIPRmask[ ] manually? Does USE_NESTED_INTERRUPTS affect only the IPR masks and not the status register I-one bit (bit #9)? Thanks again for your help, people. Rick Corey - - - - - The reason I'm concerned about nested IRQs is that I can go to mixed mode and watch what seems to be wrong behavior for TSTW or BNE (see mixed display at the end of the email). At the source level, *both* DoA and DoB would run. if (ptr == NULL) { DoA } if (ptr != NULL) { DoB } Elsewhere in my code (like, outside ISRs), the test (ptr == NULL) seems to work OK. I would always execute DoA whether the pointer was zero or not. I would execute both DoA and DoB on the same pass through the code, if the ptr was non-zero, and I wasn't modifying the pointer in DoA. Just 2-3 times, I saw correct behavior, right after I first added the line #DEFINE USE_NESTED_INTERRUPTS YES However, that behavior "went away". Also, if anything, this should turn nesting ON. I could watch BNE branch the same way whether the pointer was 0 or $20A3. The sr.Z bit was always set in those tests, but I could see it go to 0 after the != test (watching only source level). I don't completely believe that I'm seeing what I'm seeing, so please don't take my word for it. After I'm sure I have nested IRQs blocked I'll report again. real source code: volatile struct CanPktBuffer *psTmpDbgPtr; volatile struct CanPktBuffer *psPRLL_ListHead=NULL; . . . . if (psTmpDbgPtr == NULL) { psPRLL_ListHead = *ppsPktToInsert; // DoA } // there is no "else" here if ( psTmpDbgPtr != NULL ) { // DoB while ( ( psInsertHere->pnext != NULL ) && ( psInsertHere->pnext->DataByte[PACKET_LEN] < (*ppsPktToInsert)->DataByte[PACKET_LEN] ) ) { psInsertHere = psInsertHere->pnext; } etc etc } I started out with a simpler: If ( psPRLL_ListHead == NULL) { DoA } else { DoB } and then inserted the TmpPtr, and removed the else, switched the order of the ptr and the NULL, in desperation. real mixed mode: psTmpDbgPtr = psPRLL_ListHead; P:000002DA: F8542052 move X:0x2052,R0 P:000002DC: 9832 moves R0,X:0x0032 if (psTmpDbgPtr == NULL) P:000002DD: BE32 tstw X:0x0032 P:000002DE: A203 bne AddPktToPRLL+0x9 (0x2e2); 0x000173 { psPRLL_ListHead = *ppsPktToInsert; P:000002DF: F816 move X:(R2),R0 P:000002E0: D8542052 move R0,X:0x2052 } if ( psTmpDbgPtr != NULL ) P:000002E2: BE32 tstw X:0x0032 P:000002E3: A319 beq AddPktToPRLL+0x24 (0x2fd); 0x00018b { // walk the ToTxList to insert in order or at end while ( ( psInsertHere->pnext != NULL ) && P:000002E4: A903 bra AddPktToPRLL+0xf (0x2e8); 0x000176 ( psInsertHere->pnext->DataByte[PACKET_LEN] < (*ppsPktToInsert)->DataByte[PACKET_LEN] ) ) { psInsertHere = psInsertHere->pnext; P:000002E5: FB43000F move X:(R3+0x000f),R3 P:000002E7: E040 nop } P:000002E8: FE43000F tstw X:(R3+0x000f) P:000002EA: A309 beq AddPktToPRLL+0x1b (0x2f4); 0x00017f P:000002EB: F843000F move X:(R3+0x000f),R0 P:000002ED: F916 move X:(R2),R1 P:000002EE: F1400004 move X:(R0+0x0004),Y0 P:000002F0: F0410004 move X:(R1+0x0004),X0 P:000002F2: 7C43 cmp X0,Y0 P:000002F3: A171 bcs AddPktToPRLL+0xc (0x2e5); 0x00016b Rick Corey, Software Development DPC Instrument Systems Division, Flanders NJ _____________________________________ 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 <http://www.yahoogroups.com/group/motoroladsp> More Groups: http://www.dsprelated.com/groups.php3 <http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/ _____________________________________ 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 <http://www.yahoogroups.com/group/motoroladsp> More Groups: http://www.dsprelated.com/groups.php3 <http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/> Service. <http://rd.yahoo.com/M!9695.2310151.3725769.2113459/D=egroupweb/S057718 55:HM/A26184/R=0/*http:/ad.doubleclick.net/jump/N879.ameritrade.yahoo/B10 54521.11;sz00x250;adc=ZHS;ord34639144? <http://us.adserver.yahoo.com/l?M!9695.2310151.3725769.2113459/D=egroupmai l/S=:HM/A26184/randT3408226 _____________________________________ 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 <http://www.yahoogroups.com/group/motoroladsp> More Groups: http://www.dsprelated.com/groups.php3 <http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/> Service. |
Reply by ●October 29, 20022002-10-29
|
Hi Rick Yes, all you have to do to enable nested interrupts is to #define the priorities to be from 2-7. If you look in the Motorola SDK file "const.c", you can see that the array "configNestedIPRmask[]" is automatically created from your #defines of the interrupt priority levels, and the value in configNestedIPRmask[0] is a Boolean flag for the interrupt dispatcher that enables nested interrupts. This array is automatically set to enable nested interrupts when any of the interrupt priorities is greater than 1. I am posting this message to the motoroladsp discussion group, as I thought the information about enabling nested interrupts would be useful to other members. In Vancouver, we don't normally get any frost until late December. Our weather is _much_ warmer than most of Canada, due to the warm ocean current coming up from Hawaii. Our temperatures in winter are much like they are in Texas (where my sister lives), and often we are warmer than Houston or Dallas/Fort Worth. Art Johnson -----Original Message----- From: [mailto:] Sent: Tuesday, October 29, 2002 7:44 AM To: Art Johnson Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS Hi Art That sounds like a lot of fun. I often wish I had a small wood lathe. I also had fun, but it was at work, chasing a missed deadline. I dropped back to non-nestable "Normal" interrupts using the SDK dispatcher, for now. We are going to pursue some application functionality first to make our managers stop scowling. >> One system has a total of 21 interrupts enabled and active. All of these systems have been running for many months without any hiccups, crashes, or other strange things happening (other than ones caused by CodeWarrior). << This is very re-assuring. If it weren't for you and one or two others expressing confidence, we would be looking for an alternative to the 803 (and tossing several boards EE designed and weeping and wailing and gnashing our teeth). If we find that our stepper motor IRQs do need to interrupt our CANbus IRQs, we will try out the nestable feature of the SDK. My understanding is that I should just set some of these lines to 2-7, and the IRQs will become nestable through dispatcher #ifdefs. #define GPR_INT_PRIORITY_14 1 // 4 // MSCAN Tx Ready TXEIE #define GPR_INT_PRIORITY_15 1 // 5 // MSCAN Rx Ready RXFIE #define GPR_INT_PRIORITY_16 1 // 4 // MSCAN WakeUp WUPIE #define GPR_INT_PRIORITY_17 1 // 6 // MSCAN Errors RWRNIE TWRNIE RERRIE TERRIE BOFFIE OVRIE Thanks for all your help! Good luck with the garden; don't you have heavy frost already? Rick Corey -----Original Message----- From: Art Johnson [mailto:] Sent: Thursday, October 24, 2002 9:48 AM To: Corey, Rick Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS Hi Rick, I had a really good time on my vacation, playing in my garden, and I also bought a lot of new power tools for my (woodworking) workshop at home. I just finished clearing up everything that had piled up while I was on vacation, and reading all my emails. Are your nested interrupts working OK now? We have several new products here that use nested interrupts at all 7 priority levels, with both "Normal" interrupts and "Super Fast" interrupts. One system has a total of 21 interrupts enabled and active. All of these systems have been running for many months without any hiccups, crashes, or other strange things happening (other than ones caused by CodeWarrior). If you are still having problems, please let me know and give me some details of what is going on. One thing we do use here (and which I very strongly recommend) is a RealTime Operating System (RTOS). This allows you to split up your software into completely independent "tasks", so it is very easy to make sure that there is no possibility of interaction between different parts of your program. We use the DSP OS RTOS, here's the link if you're interested: DSP OS is located at: <http://www.dspos.com> Regards, Art -----Original Message----- From: Corey, Rick [mailto:] Sent: Tuesday, October 15, 2002 11:02 AM To: 'Leonard N. Elevich'; Motodsp (E-mail) Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS Leonard, You are right. I must have pasted an extra #endif into that file days ago, and never noticed, because I didn't use it until just now. Thank you! (putting on a Dunce Cap and sitting in the corner) Rick Corey -----Original Message----- From: Leonard N. Elevich [mailto:] Sent: Tuesday, October 15, 2002 1:45 PM To: 'Corey, Rick' Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS Rick, in your appconfig.h file for flash configuration you have an extra #endif at the end of the file. Since this file is included in the config.h, preprocessor gives you error for config.h file. Once I removed extra #endif in your appconfig.h file, your project compiled fine. Leonard -----Original Message----- From: Corey, Rick [mailto:] Sent: Tuesday, October 15, 2002 9:49 AM To: 'Leonard N. Elevich' Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS Thank you! I really appreciate this. Maybe I'm just worn down by missing deadlines and working weekends and evenings, yet making no progress. I've tried re-installing the SDK, then got called over to put out another fire. Here's the project - oh please tell me that I did something amazingly stupid! Rick Corey -----Original Message----- From: Leonard N. Elevich [mailto:] Sent: Tuesday, October 15, 2002 12:13 PM To: 'Corey, Rick'; 'Motodsp (E-mail)' Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS You don't need to use SDK's INCLUDE_FLASH to target your application into Flash. I would be glad to help you figure out your preprocessor problem. If you can send me your project (zipped) as is, or trim it down to bare code as long as problem is still there, I will take a look at it. As far as generation of the pre-processor output, I am not aware of any options that you can give to CodeWarrior to force the output. Leonard -----Original Message----- From: Corey, Rick [mailto:] Sent: Tuesday, October 15, 2002 8:00 AM To: 'Leonard N. Elevich'; Motodsp (E-mail) Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS Thanks for the help and frankness, Leonard. If I get this working, I'll take out my workarounds and reply to the group "that worked". However, I have to chase another frustrating problem first. Rick Corey P.S. Is there a way to generate pre-processor output? I'm disenheartened and frustrated again; trying to compile from the SDK for FLASH instead of external RAM is giving me five compiler errors in config.h, which I don't feel very safe in modifying. Should we #define INCLUDE_FLASH just to download to FLASH? Surely not. We can download to FLASH all day in the non-SDK projects we've built. "preceding #if is missing config.h line 2381 #endif" We've gone through 2,381 lines of config.h without finding why #ifdef and #ifndef might get unmatched when we go from RAM to FLASH. as far as we can tell, the .H files we have looked at seem to have matching numbers of #ifdef + #ifndef and #endif ... as far as we can tell, which only goes so far due to the conditional degree of nesting of includes and #if s. We assume that some #define somewhere is interfering with the SDK config/appconfig mechanism. I am trying to use the SDK interrupt dispatcher for two non-driver interrupts - CAN IRQs without the CAN driver. Of course I am not #define - ing INCLUDE_CAN because we aren't/can't use the CAN driver as it is. -----Original Message----- From: Leonard N. Elevich [mailto:] Sent: Monday, October 14, 2002 7:45 PM To: 'Corey, Rick'; 'Motodsp (E-mail)' Cc: 'Nickerson, Steve' Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS One more clarification about our documentation being wrong. After reading this portion of the documentation more carefully, you will find that it doesn't talk about some global macro that you can use to toggle nested interrupts in the SDK. This example defines this macro in the appconfig.h for local use only. So SDK documentation is correct. And you have to use method that I have described in my previous email to disable nested interrupts. There is however, another way for you to disable nested interrupts. If you define all interrupts to be the same priority: #define GPR_INT_PRIORITY_14 4 // MSCAN Tx Ready TXEIE #define GPR_INT_PRIORITY_15 4 // MSCAN Rx Ready RXFIE SDK should disable nested interrupts for you automatically. The only time SDK re-enables interrupts (uses nested interrupts), is when you use different interrupt priorities (as in your example). I still think that example in our documentation is some what misleading (I misread it just like you), unless you read it very carefully. Leonard -----Original Message----- From: Leonard N. Elevich [mailto:] Sent: Monday, October 14, 2002 4:31 PM To: 'Corey, Rick'; 'Motodsp (E-mail)' Cc: 'Nickerson, Steve' Subject: RE: [motoroladsp] USE_NESTED_INTERRUPTS Unfortunately, our documentation is wrong. You will not find a single instance of USE_NESTED_INTERRUPTS in the SDK source files. To turn nested interrupts off, you will have to open dispatcher.asm file located in the sys directory, and modify the following line of code: define SUPPORT_NESTED_INTERRUPTS '1' You will have to change 1 to 0. I am not sure why SDK implementation doesn't allow configuration of this parameter via appconfig.h, while SDK documentation talks about it, and I apologize for any confusion it caused. Sincerely, Leonard N. Elevich Motorola DSPO -----Original Message----- From: Corey, Rick [mailto:] Sent: Saturday, October 12, 2002 2:43 PM To: Motodsp (E-mail) Cc: Nickerson, Steve Subject: [motoroladsp] USE_NESTED_INTERRUPTS I have another beginner SDK question, after searching the Yahoo archive and all the manuals that seemed relevant. I seemed to have found an answer, but it didn't seem to work, nor did any of the variations I tried. I'm trying to disable nested interrupts in the SDK. I have some "impossible" code behavior, and thought it might be due to nested interrupts changing the Z bit in the status register behind my back. Although I'm trying to block nested IRQs, bits [9:8] in the SR are always 0x01, which seem to enable maskable IRQs (though perhaps the NestedIPRMask is blocking them). I see it is the I-one bit (not the I-zero bit as I thought before) that masks all interrupts except NMIs. I've tried these three lines (one at a time, of course) in my appconfig.h for RAM, and FLASH, as the first changed line: #DEFINE USE_NESTED_INTERRUPTS NO #undef USE_NESTED_INTERRUPTS #DEFINE USE_NESTED_INTERRUPTS YES Below them, I have these lines: #define GPR_INT_PRIORITY_14 4 // MSCAN Tx Ready TXEIE #define GPR_INT_PRIORITY_15 5 // MSCAN Rx Ready RXFIE void ISR_CAN_Transmit(void); // Thanks, MotoDSP group! void ISR_CAN_Receive( void); #define NORMAL_ISR_14 ISR_CAN_Transmit // no "F"! #define NORMAL_ISR_15 ISR_CAN_Receive Does " #DEFINE USE_NESTED_INTERRUPTS NO" work for other people here? Should I also poke configNestedIPRmask[ ] manually? Does USE_NESTED_INTERRUPTS affect only the IPR masks and not the status register I-one bit (bit #9)? Thanks again for your help, people. Rick Corey - - - - - The reason I'm concerned about nested IRQs is that I can go to mixed mode and watch what seems to be wrong behavior for TSTW or BNE (see mixed display at the end of the email). At the source level, *both* DoA and DoB would run. if (ptr == NULL) { DoA } if (ptr != NULL) { DoB } Elsewhere in my code (like, outside ISRs), the test (ptr == NULL) seems to work OK. I would always execute DoA whether the pointer was zero or not. I would execute both DoA and DoB on the same pass through the code, if the ptr was non-zero, and I wasn't modifying the pointer in DoA. Just 2-3 times, I saw correct behavior, right after I first added the line #DEFINE USE_NESTED_INTERRUPTS YES However, that behavior "went away". Also, if anything, this should turn nesting ON. I could watch BNE branch the same way whether the pointer was 0 or $20A3. The sr.Z bit was always set in those tests, but I could see it go to 0 after the != test (watching only source level). I don't completely believe that I'm seeing what I'm seeing, so please don't take my word for it. After I'm sure I have nested IRQs blocked I'll report again. real source code: volatile struct CanPktBuffer *psTmpDbgPtr; volatile struct CanPktBuffer *psPRLL_ListHead=NULL; . . . . if (psTmpDbgPtr == NULL) { psPRLL_ListHead = *ppsPktToInsert; // DoA } // there is no "else" here if ( psTmpDbgPtr != NULL ) { // DoB while ( ( psInsertHere->pnext != NULL ) && ( psInsertHere->pnext->DataByte[PACKET_LEN] < (*ppsPktToInsert)->DataByte[PACKET_LEN] ) ) { psInsertHere = psInsertHere->pnext; } etc etc } I started out with a simpler: If ( psPRLL_ListHead == NULL) { DoA } else { DoB } and then inserted the TmpPtr, and removed the else, switched the order of the ptr and the NULL, in desperation. real mixed mode: psTmpDbgPtr = psPRLL_ListHead; P:000002DA: F8542052 move X:0x2052,R0 P:000002DC: 9832 moves R0,X:0x0032 if (psTmpDbgPtr == NULL) P:000002DD: BE32 tstw X:0x0032 P:000002DE: A203 bne AddPktToPRLL+0x9 (0x2e2); 0x000173 { psPRLL_ListHead = *ppsPktToInsert; P:000002DF: F816 move X:(R2),R0 P:000002E0: D8542052 move R0,X:0x2052 } if ( psTmpDbgPtr != NULL ) P:000002E2: BE32 tstw X:0x0032 P:000002E3: A319 beq AddPktToPRLL+0x24 (0x2fd); 0x00018b { // walk the ToTxList to insert in order or at end while ( ( psInsertHere->pnext != NULL ) && P:000002E4: A903 bra AddPktToPRLL+0xf (0x2e8); 0x000176 ( psInsertHere->pnext->DataByte[PACKET_LEN] < (*ppsPktToInsert)->DataByte[PACKET_LEN] ) ) { psInsertHere = psInsertHere->pnext; P:000002E5: FB43000F move X:(R3+0x000f),R3 P:000002E7: E040 nop } P:000002E8: FE43000F tstw X:(R3+0x000f) P:000002EA: A309 beq AddPktToPRLL+0x1b (0x2f4); 0x00017f P:000002EB: F843000F move X:(R3+0x000f),R0 P:000002ED: F916 move X:(R2),R1 P:000002EE: F1400004 move X:(R0+0x0004),Y0 P:000002F0: F0410004 move X:(R1+0x0004),X0 P:000002F2: 7C43 cmp X0,Y0 P:000002F3: A171 bcs AddPktToPRLL+0xc (0x2e5); 0x00016b Rick Corey, Software Development DPC Instrument Systems Division, Flanders NJ _____________________________________ 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 <http://www.yahoogroups.com/group/motoroladsp> More Groups: http://www.dsprelated.com/groups.php3 <http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/ _____________________________________ 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 <http://www.yahoogroups.com/group/motoroladsp> More Groups: http://www.dsprelated.com/groups.php3 <http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/> Service. <http://rd.yahoo.com/M!9695.2310151.3725769.2113459/D=egroupweb/S057718 55:HM/A26184/R=0/*http:/ad.doubleclick.net/jump/N879.ameritrade.yahoo/B10 54521.11;sz00x250;adc=ZHS;ord34639144? <http://us.adserver.yahoo.com/l?M!9695.2310151.3725769.2113459/D=egroupmai l/S=:HM/A26184/randT3408226 _____________________________________ 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 <http://www.yahoogroups.com/group/motoroladsp> More Groups: http://www.dsprelated.com/groups.php3 <http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/> Service. _____________________________________ 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/ |
