Hi, I am using Quad timers and doing floating point calculation. [56F827] I am getting following message while debugging my code. how to know which interrupt is not handled? if divide by zero interrupt occurs then how will I know about the same? Regards, Nitin extern void configUnhandledInterruptISR (void); /*********************************************************************** ****** The following Interrupt Vector MUST be at the beginning of this vector.c file so that it is located at P:0x0000 by the linker.cmd file. ************************************************************************ *****/ asm void configInterruptVector(void) { jsr archStart #ifdef INTERRUPT_VECTOR_ADDR_1 jsr INTERRUPT_VECTOR_ADDR_1 #elif GPR_INT_PRIORITY_1 == 0 jsr configUnhandledInterruptISR #else jsr Interrupt1 #endif |
**************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. *************************************************************************** |
|
Unhandled interrupt message?
Hi, I have *read* that the TCSR register (ITCN_Base + $1C) on a 56803 is *supposed* to hold the "output of the current active vector" in bits 8-13 (page 4-15, section 4.5.4.2 of the 5680x User Manual). However, when I look at it with the CW debugger while inside an ISR, I don't see anything I recognize in there. I haven't researched that, just peeked and shrugged when I was hoping to figure out ~which~ IRQ was firing. I was reading about the 56803, and you have a 56827, so your mileage may vary. Rick Corey -----Original Message----- From: Nitin Madhukar Yewale [mailto:] Sent: Thursday, January 16, 2003 9:29 AM To: Subject: [motoroladsp] Unhandled interrupt message? Hi, I am using Quad timers and doing floating point calculation. [56F827] I am getting following message while debugging my code. how to know which interrupt is not handled? if divide by zero interrupt occurs then how will I know about the same? Regards, Nitin extern void configUnhandledInterruptISR (void); /*********************************************************************** ****** The following Interrupt Vector MUST be at the beginning of this vector.c file so that it is located at P:0x0000 by the linker.cmd file. ************************************************************************ *****/ asm void configInterruptVector(void) { jsr archStart #ifdef INTERRUPT_VECTOR_ADDR_1 jsr INTERRUPT_VECTOR_ADDR_1 #elif GPR_INT_PRIORITY_1 == 0 jsr configUnhandledInterruptISR #else jsr Interrupt1 #endif _____________________________________ 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] Unhandled interrupt message?
I have replaced the default "unhandled interrupts" that have appeared, with my own stub ISR routines for the "Reserved" or abnormal interrupts (3,4,5,6,etc...). That way I can have a debug instruction there that will break the Codewarrior debugger when one occurs. I can then easily tell which interrupt I got unexpectedly. As I recall, the Motorola SDK general purpose system also puts the ISR number in the N register, if you are using the SDK in the normal manner with the supplied default ISR handlers. Jerry. -----Original Message-----
... ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information visit http://www.messagelabs.com ________________________________________________________________________ |
Message
It shows 0x0005 as "N" register contents. I have gone through the
User manual of 826/7 [Page no 137] says "Allocated to HW Stack
OverFlow".
How to overcome the above interrupt? When this interrupt will
occuer?
Does my code uses h/w stack? Just to avoid such problems i am using
global variables so that they will not take space on Stack.
Regards,
Nitin
|
**************************Disclaimer********************************************\ ****** Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ********************************************************************************\ ******** |
Message
Hardware stack overflow is related to nested Do loops as I
recall. Interrupt routines should really not use the Do loop construct, if
background code is also using the construct. There is very limited nesting
of Do loops in hardware.
Jerry.
________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information visit http://www.messagelabs.com ________________________________________________________________________ |
This may be related to a very similar problem we have been having here,
which is that CodeWarrior version 5.0.2 puts 'do' instructions in the assembler code, even if you have turned that option off. We have had occasional hardware stack overflow exceptions, that are caused by this problem. This problem has been fixed in CodeWarrior version 5.0.4, which we are in the process of testing here. 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 -----Original Message----- From: Johnson, Jerry [mailto:] Sent: Thursday, January 16, 2003 10:13 AM To: 'Nitin Madhukar Yewale'; Johnson, Jerry; Subject: RE: [motoroladsp] Unhandled interrupt message? Hardware stack overflow is related to nested Do loops as I recall. Interrupt routines should really not use the Do loop construct, if background code is also using the construct. There is very limited nesting of Do loops in hardware. Jerry. -----Original Message----- From: Nitin Madhukar Yewale [mailto:] Sent: Thursday, January 16, 2003 12:08 PM To: Johnson, Jerry; Subject: RE: [motoroladsp] Unhandled interrupt message? It shows 0x0005 as "N" register contents. I have gone through the User manual of 826/7 [Page no 137] says "Allocated to HW Stack OverFlow". How to overcome the above interrupt? When this interrupt will occuer? Does my code uses h/w stack? Just to avoid such problems i am using global variables so that they will not take space on Stack. Regards, Nitin -----Original Message----- From: Johnson, Jerry [mailto:] Sent: Thursday, January 16, 2003 11:31 PM To: Nitin Madhukar Yewale; Subject: RE: [motoroladsp] Unhandled interrupt message? I have replaced the default "unhandled interrupts" that have appeared, with my own stub ISR routines for the "Reserved" or abnormal interrupts (3,4,5,6,etc...). That way I can have a debug instruction there that will break the Codewarrior debugger when one occurs. I can then easily tell which interrupt I got unexpectedly. As I recall, the Motorola SDK general purpose system also puts the ISR number in the N register, if you are using the SDK in the normal manner with the supplied default ISR handlers. Jerry. -----Original Message----- From: Nitin Madhukar Yewale [mailto:] Sent: Thursday, January 16, 2003 8:29 AM To: Subject: [motoroladsp] Unhandled interrupt message? ... ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information visit http://www.messagelabs.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 ________________________________________________________________________ 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 ________________________________________________________________________ _____________________________________ 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 |
|
Nitin, Art, and other DSP56800 developers, If indeed you are running into the issue where the compiler inserts 'do' instructions in the assembler code even though the option is turned off, this issue is actually fixed in R5.0.3, NOT R5.0.4 (See WB1-39699 at: http://www.metrowerks.com/mw/support/download/default.htm?did21). The issue we are addressing with the upcoming patch R5.0.4 has nothing to do with the 'do' instruction generation issue. Just wanted to clarify.... Regards, John --- In , "Art Johnson" <art@p...> wrote: > This may be related to a very similar problem we have been having here, which is that CodeWarrior version 5.0.2 puts 'do' instructions in the assembler code, even if you have turned that option off. We have had occasional hardware stack overflow exceptions, that are caused by this problem. This problem has been fixed in CodeWarrior version 5.0.4, which we are in the process of testing here. > > 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: art@p... > http://www.pmc-controls.com > > -----Original Message----- > From: Johnson, Jerry [mailto:jljohnson@g...] > Sent: Thursday, January 16, 2003 10:13 AM > To: 'Nitin Madhukar Yewale'; Johnson, Jerry; > Subject: RE: [motoroladsp] Unhandled interrupt message? > Hardware stack overflow is related to nested Do loops as I recall. Interrupt routines should really not use the Do loop construct, if background code is also using the construct. There is very limited nesting of Do loops in hardware. > > Jerry. > -----Original Message----- > From: Nitin Madhukar Yewale [mailto:nitin.yewale@w...] > Sent: Thursday, January 16, 2003 12:08 PM > To: Johnson, Jerry; > Subject: RE: [motoroladsp] Unhandled interrupt message? > It shows 0x0005 as "N" register contents. I have gone through the User manual of 826/7 [Page no 137] says "Allocated to HW Stack OverFlow". > How to overcome the above interrupt? When this interrupt will occuer? > Does my code uses h/w stack? Just to avoid such problems i am using global variables so that they will not take space on Stack. > Regards, > Nitin > > -----Original Message----- > From: Johnson, Jerry [mailto:jljohnson@g...] > Sent: Thursday, January 16, 2003 11:31 PM > To: Nitin Madhukar Yewale; > Subject: RE: [motoroladsp] Unhandled interrupt message? > I have replaced the default "unhandled interrupts" that have appeared, with my own stub ISR routines for the "Reserved" or abnormal interrupts (3,4,5,6,etc...). That way I can have a debug instruction there that will break the Codewarrior debugger when one occurs. I can then easily tell which interrupt I got unexpectedly. As I recall, the Motorola SDK general purpose system also puts the ISR number in the N register, if you are using the SDK in the normal manner with the supplied default ISR handlers. > Jerry. > -----Original Message----- > From: Nitin Madhukar Yewale [mailto:nitin.yewale@w...] > Sent: Thursday, January 16, 2003 8:29 AM > To: > Subject: [motoroladsp] Unhandled interrupt message? > ... ______________________________________________________________________ __ > This email has been scanned for all viruses by the MessageLabs SkyScan > service. For more information visit http://www.messagelabs.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 > |
--- In , "Nitin Madhukar Yewale" <nitin.yewale@w...> wrote: > Hi, > I am using Quad timers and doing floating point calculation. > [56F827] > > I am getting following message while debugging my code. > > how to know which interrupt is not handled? > > if divide by zero interrupt occurs then how will I know about > the same? > Regards, > Nitin > > extern void configUnhandledInterruptISR (void); > > /******************************************************************* **** > ****** > The following Interrupt Vector MUST be at the beginning of this > vector.c file so that it is located at P:0x0000 by the > linker.cmd file. > ********************************************************************** ** > *****/ > asm void configInterruptVector(void) > { > jsr archStart > > #ifdef INTERRUPT_VECTOR_ADDR_1 > jsr INTERRUPT_VECTOR_ADDR_1 > #elif GPR_INT_PRIORITY_1 == 0 > jsr configUnhandledInterruptISR > #else > jsr Interrupt1 > #endif > We have posted a new training exercise, Exercise 3c, on the Motorola Web site to address how to debug interrupt problems when using CodeWarrior and Embedded SDK in your projects. This exercise covers how one can determine the interrupt configuration of a project (interrupt vectors, priorities, nesting) and how to debug unhandled interrupts. Two different techniques are presented to cover debugging unhandled interrupts. You can find this exercise on the latest training CD or at http://e-www.motorola.com/collateral/56800_EXERCISE_3C.zip |
Message
The hardware stack is used exclusively for supporting nested
Hardware do loops. The hardware stack supports just two nested do loops. Trying
to perform a third nested do loop will cause this interrupt to occur. One way
that you can get an unexpected and aparently random is to have hardware do loops
in an ISR and also in your regular code.
If you have an ISR that requires the use of a do loop you can either
limit your regular code to a single loop therby reserving a hardware stack
location. Or you can in your ISR save off and restore locations in the hardware
stack. Techniques for doing this are shown in the 56800 user manual in section
8.12 and 8.13.
-----Original Message-----
From: Johnson, Jerry [mailto:j...@giddings.com] Sent: Thursday, January 16, 2003 11:13 AM To: 'Nitin Madhukar Yewale'; Johnson, Jerry; m...@yahoogroups.com Subject: RE: [motoroladsp] Unhandled interrupt message?
|