- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
gdb stops with the following message:
Signal Stop Print Pass to program Description SIGTRAP Yes Yes No Trace/breakpoint trap info signal SIGTRAP disassembly stops at: --> 0x00800098 <alt_irq_entry+120>: break 0 what is the cause of this message ??? thanksLink Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have the same problem. Have you had any luck figuring out what causes it?
-Paul- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Paul and Fischer,
It's possible that you have a spurious interrupt. Knowing that the code is "breaking" at <alt_irq_entry+120> doesn't help me to further debug the issue, however. If you're not using 5.01 (5.0 SP1 for both Quartus II and Nios II), then I: 1. Recommend that you do. 2. Would not be able to help you with any other version(s). If you are using 5.01, then the default behavior is to fall into an "unknown" section, if the code can't determine what caused the exception: .section .exceptions.unknown
/*
* If you get here then one of the following could have happened:
*
* - Your program could have been compiled for a full-featured Nios II
* core, but it is running on a smaller core, and instruction emulation
* has been disabled by defining ALT_NO_INSTRUCTION_EMULATION.
*
* You can work around the problem by re-enabling instruction emulation,
* or you can figure out why your program is being compiled for a system
* other than the one that it is running on.
*
* - Your program has executed a trap instruction, but has not implemented
* a handler for this instruction.
*
* - Your program has executed an illegal instruction (one which is not
* defined in the instruction set).
*
* - Your hardware is broken and is generating spurious interrupts (a
* peripheral which deasserts its interrupt output before its interrupt
* handler has been executed will cause spurious interrupts).
*
*/
# ifdef NIOS2_HAS_DEBUG_STUB
/*
* Either tell the user now (if there is a debugger attached) or go into
* the debug monitor which will loop until a debugger is attached.
*/
break
# else
/*
* If there is no debug stub then a BREAK will probably cause a reboot.
* An infinate loop will probably be more useful.
*/
0:
br 0b
# endif
If this is the spot in the code, that you're reaching, then some possible causes are listed in the above comments. You should also take a look at the current state of the registers and the stack traceback (if possible). Best Regards, - slacker
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- your hardware is broken and is generating spurious interrupts (a
peripheral which deasserts its interrupt output before its interrupt
handler has been executed will cause spurious interrupts). That is what got me. I forgot to loop back the interrupt request bit to hold the irq state until the interrupt service routine could clear it. assign irq = (irq & ~irq_clear) | (irq_trigger);
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page