Device doesn't retain low power configs

[Raffaele]

Hi,

sorry if the title is misleading.
I'm having issues with programming a KL03. The code that I program the device with has a low power task that periodically moves from VLPW to VLPS, and vice versa.
If I:
Program the device -> Power it off -> Power it on again
Or
Power it on -> Program with recompiled code (even the same exact code, just freshly recompiled)
 it stalls at the beginning (but I think neither in VLPW nor in VLPS, because the power consumption is larger than VLPW and lower than VLPS. I measured  the powers for each state).
Instead, if I:
Program the device -> Power it off -> Power it on -> RE-PROGRAM with the same code (not recompiled), then it works properly, and alternates between VLPW and VLPS.

What could it be?
My intuition is that during reprogramming something gets pulled high/low, probably for a certain amount of time necessary for my device to work properly.  And since this doesn't happen with a simple restart, the device/code gets stuck somewhere

[Raffaele]

any help on what could cause the issue? Is it probably the fnLowPower task , but why would it work in one case (i.e., program device - turn off - turn on - reprogram) and not in the other (program - turn off - turn on)?


EDIT Update: I'm using some interrupt signals and it looks like my code gets stack when I inform that I want to enter VLPS (fnSetLowPowerMode(VLPS_MODE)). At that point, the task doesn't get activated any more when I use uTaskerMonoTimer('j', (DELAY_LIMIT) (5 * SEC), UTASKER_ACTIVATE);

[mark]

Hi

Sorry for not being able to respond earlier.

It may be that the open source version doesn't have all up to date low power control features but the thing to be aware of is that some of the low power registers are maintained across resets and some can only be written once after power on and any attempts to write them again with different values are ignored (also after a SW reset). Generally a power cycle is advised whenever something fundamental is change in a program.

Maybe this can explain something?

I checked the HW-related low power related code that I have in the Kinetis framework, which you can compare and check up on it the user's manual to see whether it helps explain or identify something:

Immediately after a reset:
        #if defined SUPPORT_LOW_POWER && (defined KINETIS_K_FPU || defined KINETIS_KL || defined KINETIS_REVISION_2 || (KINETIS_MAX_SPEED > 100000000))
            #if defined SUPPORT_LPTMR                                    // ensure no interrupts pending after waking from VLLS modes via LPTMR
    POWER_UP_ATOMIC(5, LPTMR0);                                          // power up the low power timer
    PMC_REGSC = PMC_REGSC_ACKISO;                                        // acknowledge the isolation mode to set certain peripherals and I/O pads back to normal run state
    LPTMR0_CSR = 0;                                                      // clear possible pending interrupt and stop the timer
    POWER_DOWN_ATOMIC(5, LPTMR0);                                        // power down the low power timer
            #else
    PMC_REGSC = PMC_REGSC_ACKISO;                                        // acknowledge the isolation mode to set certain peripherals and I/O pads back to normal run state
            #endif
        #endif


After a reset (but later):

#if defined SUPPORT_LOW_POWER
    #if defined KINETIS_K_FPU || defined KINETIS_KL || defined KINETIS_KM || defined KINETIS_REVISION_2 || (KINETIS_MAX_SPEED > 100000000)
    SMC_PMPROT = SMC_PMPROT_LOW_POWER_LEVEL;                             // {117} - this may already have been written (with the same value) already during clock initialisation when HSRUN mode is used
    #elif !defined KINETIS_KE && !defined KINETIS_KEA
        #if !defined MC_PMPROT_LOW_POWER_LEVEL
            #define MC_PMPROT_LOW_POWER_LEVEL (MC_PMPROT_AVLP | MC_PMPROT_ALLS | MC_PMPROT_AVLLS1 | MC_PMPROT_AVLLS2 | MC_PMPROT_AVLLS3) // allow all low power modes if nothing else defined
        #endif
    MC_PMPROT = MC_PMPROT_LOW_POWER_LEVEL;                               // {117}
    #endif
    #if defined ERRATA_ID_8068 && !defined SUPPORT_RTC                   // if low power mode is to be used but the RTC will not be initialised clear the RTC invalid flag to avoid the low power mode being blocked when e8068 is present
    POWER_UP_ATOMIC(6, RTC);                                             // temporarily enable the RTC module
    RTC_TSR = 0;                                                         // clear the RTC invalid flag with a write of any value to RTC_TSR
    POWER_DOWN_ATOMIC(6, RTC);                                           // power down the RTC again
    #endif
#endif

Regards

Mark

[Raffaele]

No worries about late reply Mark, thank you I appreciate your help.

Apparently there were three causes of error in my set-up: 1) as you pointed out, I needed to power cycle the board between programming it, 2) I had a signal analyzer connected to the board that was changing the absorbed current and gave inconsistent results, 3) I was trying to read an interrupt that was too short for the low power clock and the microcontroller wasn't able to catch it and it seemed like something stopped working.

Thanks