Troubleshooting a board with LLWU wake-up problems

[michaelburr]

I have a board with a K10 processor which was returned by a customer and I'm trying to track down the root cause of the issue. Most boards of this design work OK, but it's not yet clear whether we have a hardware or software or even a silicon problem. Looking for suggestions how to isolate the issue further.

Background:

Processor is MK10DX256VLH7. Using the Freescale MQX RTOS.

We're using the LLWU module to put the board to sleep or wake it up according to certain signals mapped to GPIO pins (specifically a keypad and an accelerometer). Basically the board should wake up whenever a button is pressed or the assembly is moved. When the board goes to sleep (due to inactivity), we use this MQX function to put the processor into the LLS low-power state:

_lpm_set_operation_mode( LPM_OPERATION_MODE_STOP );

We have the pins LLWU_P0, LLWU_P1, LLWU_P2, and LLWU_P4 set up as wake-up event sources during the low-power state.

Description of the problem:

The pins LLWU_P0, LLWU_P1, LLWU_P2 (all on Port E) do not work as wake-up event sources, but the pin LLWU_P4 (Port A) does work.

We’ve verified that the buttons are generating the expected negative edge which should trigger the wake-up. All of these pins do work as interrupt sources when the board is awake..

On the other hand, pins LLWU_P0 and LLWU_P1 sometimes cause spurious wake-ups: that is they cause wake-up events even though the keypad button connected to these pins has not been pressed. These pins are pulled up to a certain power supply when sleeping, and we have looked for glitches on that power supply that might be causing the spurious wake-ups, but we haven't found any.

We've also tried disabling LLWU_P0 and LLWU_P1 as direct wake-up sources, and hooked up the filters (LLWU_FILT1 and LLWU_FILT2) to those pins instead, and set them up as wake-up sources. In that case we found that the spurious wake-ups don’t happen anymore, but the buttons still do not cause the expected wake-up when pressed.

If anyone has ideas what else we might try to track down this issue, please let me know! Thanks for reading this.

[philip_drake]

Hello Michael,

First let me say that I have not fully utilized and tested the MQX low power mode functionality.  I cannot confirm that MQX does not have an issue with the initialization or handling of the wake up sources for low power modes.  I seem to remember that this MCU has been through a thorough validation to make sure all of the LLWU sources do result in a wake up from each of the low power modes.

From your description I'm reading that the keyboard inputs are not using the TSI but are physical switches that cause a pin transition. All of the pins with the exception of the NMI pin are edge sensitive, so if falling edge is selected and the input pin is already low upon low power mode entry the input would need to go high then low to trigger a wake up event.

The 2N36B does not support LLS low power mode - see errata  e7214.

This was fixed on 3N36B.  In researching the reason this mode was not supported I found that if the MCU entered LLS mode on 2N36B parts the RAM could be corrupted.  If RAM is corrupted then the MCU could get lost due to an invalid stack or heap. 

What low power mode besides LLS was used in the workaround? If it was VLPS then the LLWU wakeups are not used and the corresponding pin interrupt function will need to be used. If the VLLS3 low power mode was used, then the customer needs to make sure both the pin interrupt and the appropriate LLWU_PE bit is set to falling edge, the PORTE clock gate is turned on and the PORTE pins are properly configured as digital inputs.  For instance PTE1/LLWU_P0 mux selection could be ALT1 for GPIO, ALT3 for UART1_RX or ALT7 for SPI1_SIN since all are digital inputs .  If the GPIO INPUT is desired with  PORTE_PCR1(MUX = ALT1) then the pull up can be enabled in the PCR register (PE = 1 and PS = 1) and the GPIO Port Data Direction Register (GPIOE_PDDR) bit 1,2 and 4 must = 0 configuring the pin as an input.

This LLS RAM corruption issue was fixed in 3N36B.  So the setup indicated above for LLWU wake up from VLLS3 would apply.

To debug this issue I would suggest using the debugger to stop the MCU before the low power mode entry and check the various register settings to make sure the MCU is properly set up.(see serialization note below as well)

The spurious wake ups that are cleared up with the enabling of the filter issue - is that on 2N36B silicon? was LLS being used? the fact that the filter enable cleared up the problem may mean several things. The wake up edged without filter can be very short and wake the MCU.  I've seen a pulse as short as 1-4 ns cause a wakeup.  Even if the pin filter is enabled in the PORT_PCR register, the wake up pulse can be 9ns and wake up the MCU.  Noise on the ground or VDD could also be coupled into and cause a perturbation resulting in a wake up event.

One last possibility is a serialization issue.  This issue would manefest itself differently depending on the kinds of things going on in the MCU.  Simply put, the process of writing to a module to set a control bit or clear a flag takes a number of cycles.  If subsequent code requires that control bit to be in it's written state or a flag to be cleared then a readback of the register is needed to hold off the execution of that subsequent  CPU code. The read back after a write stalls the CPU until the write and read have completed.

Let me know if there are any ways I can assist further.  There is always AN4503, I updated this year, that might help.

Best Regards,

Philip Drake

[isaacavila]

Hi Michael,

You said that most boards work ok, didn't you? If so, it could be related to chip-specific damage. Do all chips have same MASK?

Regards,

Isaac

[michaelburr]

Well, this product has used both the 2N36B and the 3N36B mask. Newer boards (including the particular one we’re discussing here) have 3N36B.

Yes, most boards work OK. There have been customer complaints related to sleep/wake issues, and it’s not clear whether this board is unique.

Mike Burr

[isaacavila]

Hi Michael,

The only silicon issue related to LLWU is mentioned in this errata: (http://cache.freescale.com/files/32bit/doc/errata/KINETIS_K_3N36B.pdf?fpsp=1&WT_TYPE=Errata&WT_VENDO... )

And this is related to incorrect triggers by wake-up from LLWU, but i suppose you cannot wake-up the MCU in the first try, right?

I could test this issue on a K20 board (due there is no K10-based board), but this might not be useful for you.

Regards,

Isaac

[michaelburr]

Thank you for the idea! I have seen those Errata, too. A failure of "entry into LLS" might be the same thing as our spurious wake-ups, but as you say it's not the same problem as our failure to wake-up at all. I didn't think that e5952 would apply, because we don't ever use VLPR mode (so far as I know)--but it might be worth checking more carefully the way we handle the LLWU interrupt.

It probably wouldn't be worth testing on your board, since it would be hard to reproduce the exact circumstances. Thanks for the offer, though.