Consumo de modo de suspensión profunda de PIC

Me gustaría saber por qué mi PIC, que cuando lo pongo en modo de suspensión profunda, consume más de lo que especifica la hoja de datos. Conecté un medidor de corriente de precisión y descubrí que cuando cargo el código que hace que el controlador entre en modo de suspensión profunda, consume 0,27 mA en relación con la clasificación de 860 nA dada. Me gustaría tener su visión para el problema. Las pruebas las he hecho en una PCB con cristal para 16 MHz y para RTCC. ¿Por qué muestra tanto consumo?

// PIC18F26J50 Configuration Bit Settings

#include <p18F26J50.h>

// CONFIG1L
#pragma config WDTEN = OFF      // Watchdog Timer (Disabled - Controlled by SWDTEN bit)
#pragma config PLLDIV = 1       // PLL Prescaler Selection bits (No prescale (4 MHz oscillator input drives PLL directly))
#pragma config STVREN = ON      // Stack Overflow/Underflow Reset  (Enabled)
#pragma config XINST = OFF       // Extended Instruction Set (Enabled)

// CONFIG1H
#pragma config CPUDIV = OSC1    // CPU System Clock Postscaler (No CPU system clock divide)
#pragma config CP0 = OFF        // Code Protect (Program memory is not code-protected)

// CONFIG2L
#pragma config OSC = ECPLL      // Oscillator (EC+PLL (CLKO-RA6), USB-EC+PLL)
#pragma config T1DIG = ON       // T1OSCEN Enforcement (Secondary Oscillator clock source may be selected)
#pragma config LPT1OSC = OFF    // Low-Power Timer1 Oscillator (High-power operation)
#pragma config FCMEN = ON       // Fail-Safe Clock Monitor (Enabled)
#pragma config IESO = ON        // Internal External Oscillator Switch Over Mode (Enabled)

// CONFIG2H
#pragma config WDTPS = 32768    // Watchdog Postscaler (1:32768)

// CONFIG3L
#pragma config DSWDTOSC = INTOSCREF// DSWDT Clock Select (DSWDT uses INTRC)
#pragma config RTCOSC = T1OSCREF// RTCC Clock Select (RTCC uses T1OSC/T1CKI)
#pragma config DSBOREN = ON     // Deep Sleep BOR (Enabled)
#pragma config DSWDTEN = ON     // Deep Sleep Watchdog Timer (Enabled)
#pragma config DSWDTPS = G2     // Deep Sleep Watchdog Postscaler (1:2,147,483,648 (25.7 days))

// CONFIG3H
#pragma config IOL1WAY = ON     // IOLOCK One-Way Set Enable bit (The IOLOCK bit (PPSCON<0>) can be set once)
#pragma config MSSP7B_EN = MSK7 // MSSP address masking (7 Bit address masking mode)

// CONFIG4L
#pragma config WPFP = PAGE_63   // Write/Erase Protect Page Start/End Location (Write Protect Program Flash Page 63)
#pragma config WPEND = PAGE_WPFP// Write/Erase Protect Region Select (valid when WPDIS = 0) (Page WPFP<5:0> through Configuration Words erase/write protected)
#pragma config WPCFG = OFF      // Write/Erase Protect Configuration Region (Configuration Words page not erase/write-protected)

// CONFIG4H
#pragma config WPDIS = OFF      // Write Protect Disable bit (WPFP<5:0>/WPEND region ignored)






        #include<p18F26J50.h>
        #include"delays.h"


                void main (void)

{


                    int x;

                    TRISC=0x00;
                    PORTCbits.RC2=1;
                    Delay10KTCYx(20);



                    WDTCONbits.REGSLP = 1;                                                          //PERIPHERAL INT DISABLE
                    OSCCONbits.IDLEN = 0;
                    INTCONbits.GIE=0;

                    PORTCbits.RC2=0;
                    DSCONHbits.DSEN=1;

                    Sleep();

                    x=0;

                while(1)
        {
         ;
        }


    }``
Con los modos de suspensión, debe tener cuidado de apagar los periféricos que no está usando y colocar todos los pines en un estado en el que consuman la menor cantidad de corriente. Podría valer la pena intentar publicar el código mínimo que hace que suceda.
@PeterJ He incluido el código en el que he puesto el TRISC como en estado de salida. Pero no está habilitado para salir cuando entra en suspensión profunda.
Ponga la instantánea esquemática. Cuando el código es correcto... Es posible que haya dejado pocos IO o pines de entrada sin terminación o algunos de los dispositivos están tomando mucha corriente (en uA) en modo de desactivación como LDO, búferes, etc... He visto el mismo caso en la placa de controladores atmel xmega. La conclusión es que quedaron pocos pines sin terminación, LDO malo (corriente de 40uA cuando EN es BAJO)

Respuestas (1)

He encontrado la respuesta, fue un error de mi parte. En el código anterior, he habilitado el TRISC como salida. Esa es la razón del consumo de .278 mA que se muestra allí. Si configura TRISC como entrada, el consumo terminaría con unas pocas decenas de uA.

Y si no hace nada más que el modo de suspensión profunda y elimina el código de configuración del puerto, el consumo se reduciría a 80 nA respectivamente.