Home/ Questions/Q 6729253
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T10:16:02+00:00

While running my program on a microchip ICD3 device, the exception handling looks weird.

  • 0

While running my program on a microchip ICD3 device, the exception handling looks weird. The program will stop response while exception occurs. While checking the code, I noticed that the default-general-exception-handler.c will create an infinite loop. It is really confusing because I cannot know where the error occurs and what is the reason. Does that mean Microchip doesn’t support exception handling? Or is there a way to read the error message?

infinite loop:

---  \home\c11067\work\C32\builds\pic32-microchip-release-1.12-20101221-rc2-20101221\pic32-libs\libc\stubs\default-general-exception-handler.c
9D00DD28  1000FFFF   beq         zero,zero,0x9d00dd28
9D00DD2C  00000000   nop

By defining a _general_exception_handler, it works!

// declared static in case exception condition would prevent
// auto variable being created
static enum {
    EXCEP_IRQ = 0,          // interrupt
    EXCEP_AdEL = 4,         // address error exception (load or ifetch)
    EXCEP_AdES,             // address error exception (store)
    EXCEP_IBE,              // bus error (ifetch)
    EXCEP_DBE,              // bus error (load/store)
    EXCEP_Sys,              // syscall
    EXCEP_Bp,               // breakpoint
    EXCEP_RI,               // reserved instruction
    EXCEP_CpU,              // coprocessor unusable
    EXCEP_Overflow,         // arithmetic overflow
    EXCEP_Trap,             // trap (possible divide by zero)
    EXCEP_IS1 = 16,         // implementation specfic 1
    EXCEP_CEU,              // CorExtend Unuseable
    EXCEP_C2E               // coprocessor 2
} _excep_code;



static unsigned int _epc_code;
static unsigned int _excep_addr;

// this function overrides the normal _weak_ generic handler
void _general_exception_handler(void)
{
    asm volatile("mfc0 %0,$13" : "=r" (_excep_code));
    asm volatile("mfc0 %0,$14" : "=r" (_excep_addr));

    _excep_code = (_excep_code & 0x0000007C) >> 2;

    while (1) {
        // Examine _excep_code to identify the type of exception
        // Examine _excep_addr to find the address that caused the exception
    }
}
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    On most microcontrollers, there isn’t any code beyond what you put there. In most cases, if an exception occurs and you haven’t defined a handler for it, the processor would have no idea how to put up a “Sorry, a system error occurred” dialog box. Using two bytes for a “branch-to-self” instruction is enough to yield a predictable response to an exception; without particular knowledge of any better course of action, a branch-to-self or forced reset is probably as good a response as anything.

    PS–Some compilers for various platforms will omit vectors for unused interrupts or exceptions; if such exceptions occur unexpectedly, weird and bizarre things can happen. Some compilers will produce code that will force an immediate reset (note that if watchdog timer is enabled, a jump-to-self will cause a reset, eventually). Some compilers generate an immediate return-from-interrupt (which on some CPU’s may be useless, and on others can cause bad behavior). My favorite pattern would be to have all unused interrupts make a call (not a branch) to an UnexpectedInterrupt label, which in the absence of any explicit definition will point to a branch-to-self instruction. If one does that, an UnexpectedInterrupt handler can pop the stack and record what type of unexpected interrupt occurred. I’ve not seen such a pattern, though, outside my own manually-generated interrupt vector tables.

    • 0