manuseamento excepção microchip

Question

Ao executar o meu programa em um dispositivo de microchip ICD3, manipulação de exceção parece estranho. O programa irá parar de resposta quando exceção ocorre. Ao verificar o código, percebi que o padrão-geral-exception-handler.c irá criar um loop infinito. É realmente confuso porque eu não posso saber onde o erro ocorre e qual é a razão. Isso significa Microchip faz tratamento de exceção não apoio? Ou há uma maneira de ler a mensagem de erro?

loop infinito:

---  \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        

Ao definir um _general_exception_handler, funciona!

// 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
    }
}

Answer 1

Na maioria dos microcontroladores, não há nenhum código além do que você colocar lá. Na maioria dos casos, se ocorrer uma exceção e você não tiver definido um manipulador para ele, o processador não teria nenhuma idéia de como colocar uma caixa de diálogo "Sorry, um erro de sistema ocorreu". O uso de dois bytes para uma instrução de "ramo-a-auto" é suficiente para produzir uma resposta previsível a uma excepção; sem conhecimentos específicos do melhor curso de ação, um branch-to-self ou reinicialização forçada é provavelmente tão boa uma resposta como qualquer coisa.

PS - Alguns compiladores para várias plataformas vai omitir vetores de interrupções ou exceções não utilizados; se tais exceções ocorrem de forma inesperada, coisas estranhas e bizarras pode acontecer. Alguns compiladores irá produzir código que irá forçar uma redefinição imediata (nota que, se watchdog timer estiver ativado, um auto-jump-to-causará um reset, eventualmente). Alguns compiladores gerar um retorno de-interrupção imediata (que em alguns de CPU pode ser inútil, e em outros podem causar o mau comportamento). Meu padrão favorito seria ter todas as interrupções não utilizados fazer uma chamada (não um ramo) para uma etiqueta UnexpectedInterrupt, que na ausência de qualquer definição explícita irá apontar para uma instrução de branch-to-self. Se alguém faz isso, um manipulador de UnexpectedInterrupt pode pop a pilha e gravar o tipo de interrupção inesperada. Eu não vi tal padrão, no entanto, fora as minhas próprias tabelas de vetores de interrupção gerada por manualmente.

Answer 2

Assim como um heads-up para uma maior depuração exceção PIC32, os códigos de excepção e todos os bits do registrador 'Causa' (o valor que você está lendo em sua variável _excep_code antes e-ing todos os outros pedaços de distância) são definido em:

manual PIC32 família Referência , Seção 2.12.9 Causa Register http://ww1.microchip.com/downloads/en/DeviceDoc/61113C.pdf