Kinetis llwu fails with multiple wake-up triggers

[roybunce]

I'm using a K60, spending most of its time in low-leakage wake-up mode. The wake-up event is triggered by an external device which sends a stream of pulses when the K60 should wake. The software is taken from the latest Freescale low power demo code.

If I send a single pulse it wakes correctly every time, but if I send a stream of pulses it fails every time. When it fails there is a small increase in current (a few mA), which confirms that the wake-up signal has been recognised, but there is no other detectable activity. The CPU hangs before it can output any debug messages, and the IAR IDE can't help because it loses sync during the llwu sleep.

I could modify the external device to send a single pulse, but I would prefer to understand what is going wrong. Any ideas would be appreciated.

Thanks,

Roy

[roybunce]

A bit more information. I "fixed" the problem by re-initialising the relevant I/O port bit immediately after power-up, even before disabling the watchdog. If I don't do this very early in the code, the port bit is forced to a hard "high" and the CPU hangs. I'd still like to know why this happens in case other related problems are waiting to catch me out later.

Roy

[zhaohuiliu · Accepted solution]

Hi Roy,

Are you using PTA4 for as the wakeup source? It seems that you are using VLLSx mode, which go through a reset recovery flow. If you are using PTA4, here some reason for your case.

1. single pulse less than the VLLSx mode recovery time, will wakeup MCU without any issue

2. multi pulses longer than the VLLSx mode recovery time, after MCU recovery, it will go into NMI interrupt as the previous configuration is lost after the recovery.

3. Your NMI isr may access some registers while their clock are disabled after VLLSx recovery.

4. Hardfault interrupt entered or NMI isr last too long

5. MCU has never to config WDOG, WDOG reset occur

6. If PTA4 still in LOW level while WDOG reset, MCU enter Ez-PORT mode

7. No code executed in Ez-PORT mode

If you are not use PTA4, this is not for your case.

Hope this helpful.

Thanks

Sandy

[roybunce]

Thanks Perla and Sandy,

I am using PTA4, so maybe the device is going into Ex-PORT mode. I don't think it is anything to do with NMI, because under the fault conditions it doesn't enter the NMI handler. The LLWU interrupt is not masked and there is no Hard Fault interrupt, but it does follow the reset recovery flow until the next trigger pulse appears.

The safest option is to modify the schematic so that there is only one wake-up trigger. It works every time with a single pulse.

Regards,

Roy

[zhaohuiliu]

Hi Roy,

Are you using NMI functionality in your application? if not, you can disable it permanently via FOPT setting. In IAR IDE, you should have vector.h file, modify CONFIG_4 to following value will disalbe NMI and EZ-PORT mode.

#define CONFIG_4  (pointer*)0xfffff9fe, //nmi = 0, EZPORT = 0, LPBOOT = 1

or just disable EZ-PORT mode

#define CONFIG_4  (pointer*)0xfffffdfe, //nmi = 1, EZPORT = 0, LPBOOT = 1

See more details in Chapter 6  FOPT boot options session.

Make sure you have the option of --enable_config_write to use IAR flash loader to program flash configuration filed.

If you want to use NMI and Ez-Mode, make sure following items checked in NMI isr routine.

1. checking if MCU wakeup from VLLSx mode, if yes, make sure to disable WDOG for VLLSx mode recovery time may be up to 100us.

2. checking if MCU wakeup from VLLSx mode, if yes, make sure no printf or any registers accessing before the clock for certain modules enabled in your NMI isr

Hope this helpful.

Sandy

[perlam_i_au]

The LLWU signals has been designed to be used as pulse not data stream as is mentioned in the reference manual K60P144M150SF3RM:

16.2 LLWU Signal Descriptions

The signal properties of LLWU are shown in the following table. The external wakeup

input pins can be enabled to detect either rising edge, falling edge, or on any change.

Also you have to take care about masking the LLWU interrupt because this could hang the core, as is mentioned on Table 3-4. Interrupt vector assignments in the same reference manual:

The LLWU interrupt must not

be masked by the interrupt

controller to avoid a scenario

where the system does not fully

exit stop mode on an LLS

recovery.

Please let me know if this information is useful, also I will be glad to reproduce the error and take a look on your project if you want to share it with me :smileygrin:

Have a nice day!!
Perla

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------