High current problem for app_pwm SDK13.0

[George Leung]

Hi,

I am working on nRF52832 with SDK13.0 + GCC Eclipse.

I have used 2 app_pwm instances for driving a 3 color led. Once I init the pwm and set the duty cycle, the current increase from 3uA (sleep state) to 6.5mA. This 6.5mA current is just for the MCU as I have a separate power supply for the LED, the MCU is sinking current from the LED. When I call app_pwm_disable and app_pwm_uninit, the current still keep at 6.5mA.

Further more, if I just init the pwm but not set the duty cycle, it would be just 1mA and able to go back to 3uA sleep when I disable the pwm.

I have searched for some post about the pwm which mention about the pan73_workaround fix but I already found that in app_pwm_disable.

I have 2 questions: Is 6.5mA normal for using app_pwm? How to remove that 6.5mA when I disable the pwm?

Regards, George

[George Leung]

Hi Sigurd,

I got another problem. As I am using FreeRTOS, the sleep is handled by the rtos. I try to add this workaround in the vPortSuppressTicksAndSleep and the system cannot go to sleep. Is that I do something wrong?

In port_cmsis_systick.c:

    /* Sleep until something happens.  configPRE_SLEEP_PROCESSING() can
         * set its parameter to 0 to indicate that its implementation contains
         * its own wait for interrupt or wait for event instruction, and so wfi
         * should not be executed again.  However, the original expected idle
         * time variable must remain unmodified, so a copy is taken. */
        xModifiableIdleTime = xExpectedIdleTime;
        configPRE_SLEEP_PROCESSING( xModifiableIdleTime );
        if ( xModifiableIdleTime > 0 )
        {
#ifdef SOFTDEVICE_PRESENT
            if (softdevice_handler_is_enabled())
            {
				__set_FPSCR(__get_FPSCR() & ~(0x0000009F));
				(void) __get_FPSCR();
				NVIC_ClearPendingIRQ(FPU_IRQn);

                uint32_t err_code = sd_app_evt_wait();
                APP_ERROR_CHECK(err_code);
            }
            else
#endif
            {
                /* No SD -  we would just block interrupts globally.
                * BASEPRI cannot be used for that because it would prevent WFE from wake up.
                */
                do{
                    __WFE();
                } while (0 == (NVIC->ISPR[0] | NVIC->ISPR[1]));
            }
        }
        configPOST_SLEEP_PROCESSING( xExpectedIdleTime );

[Sigurd]

Could be another peripheral that is generating the interrupt. Take a look into ISPR[0] and ISPR[1] registers when you wake-up. (NVIC), so you can figure out which peripheral cause the pending interrupt.