Bueno vamos por partes
Primero en la version del proteus que tengo la 7.2 SP0 si pude cargar el codigo en C para simularlo y funciono bien, exceptuando la parte del reset claro.
aunque es raro ello ya que nunca habilitas int por usb, lo que con el global deberia mantenerse inactivo, muy raro, pueden ser problemas del compilador, lamentablemente el ccs trae muchos bugs (errores) en varias ocasiones ha sacado canas a muchos muchachos de aca, y pues ni modo, seria bueno cambiar de lenguaje, pero nose, hay tantas cosas, haber pues.... Mr. Green
Sobre esto que puso cryn , a mi parecio que es error del proteus porque cuando hize el reset del MCLR el proteus habilito la interrupcion del USB , estoy seguro de esto porque revise el codigo en ensamblador que genera el CCS, al principio tambien pense que era un error del CCS, a mi tambien me dio muchos dolores de cabeza, pero resulto que no.
Sobre la ultima parte que puse en el anterior post , tiene que ver justamente con el vector de interrupcion, me explico , cuando revise el codigo en asm que genera el CCS note lo siguiente
Al momento de habilitar las interrupciones despues de revisar el dipswitch el CCS usa el siguiente codigo en asm
enable_interrupts(global); //Habilita máscara global de int.
movlw 0xC0
iorwf INTCON,F
bra 0x26C
la direccion 0x26C corresponde al inicio del ciclo infinito que enigma utiliza, bueno como puede verse el CCS ademas de habilitar la interrupcion global (bit 7), tambien habilita las interrupciones perifericas , esto ultimo en este caso en particular no es necesario, una vez actualizado el registro INTCON se deberia ejecutar el salto al inicio del ciclo infinito, pero como misteriosamente los bits USBIE y USBIF estan en 1 despues de un reset por MCLR o WDT (error del proteus segun yo), el microcontrolador va al vector de interrupciones donde sucede algo como lo siguiente :
en la posicion 0x08
//Primero el CCS guarda las variables de contexto y luego revisa las fuentes de interrupcion
0x04C btfss 0xFF2.4 ;Revisa si la INT0 esta habilitada
0x04E goto 0x058
0x052 btfsc 0xFF2,1 ;Revisa si produjo la INT0 (INT0IF = 1)
0x054 goto 0x0AA ;Si se produjo va a atender esta interrupcion
0x058 btfss 0xFF0.3 ;Revisa si la INT1 esta habilitada
0x05A goto 0x064
0X05E btfsc 0xFF0,0 ;Revisa si produjo la INT1 (INT1IF = 1)
0x060 goto 0x0B6 ;Si se produjo va a atender esta interrupcion
//Despues el CCS recupera las variables de contexto y termina con el clasico
retfie
En las rutinas de interrupcion que genera el CCS, este se encarga de poner en cero los bits INT0IF e INT1IF, para poder volver a la ejecucion normal del programa, el problemas es que al no esperarse la interrupcion por USB ,ya que no deberia pasar,el CCS no genera codigo para atender esta interrupcion entonces USBIE y USBIF estan siempre en 1 por lo que luego del retfie siempre se retorna al vector de interrupcion ya que USBIF y USBIE estan en 1. Entonces la solucion es deshabilitar por software de alguna forma la interrupcion por USB, pero solo para la simulacion, ya que segun la hoja de datos despues de un reset por MCLR o por WDT estas interrupciones estan deshabilitadas. pero esto ultimo aun hay que probarlo.
Saludos