KL27 - KSDK - LLWU problem

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

KL27 - KSDK - LLWU problem

1,814 Views
thomas_haugen
Contributor I

Hi,

I'm currently working on a project that requires a LLWU pin to wakeup the KL27 from LLS STOP mode. When in sleepdeep mode I trigger the interrupt with a pushbutton (with pullup), The LLWU pin goes low. But instead of running my LLWU interrupt handler it fires the DefaulISR(). I Know this because I toggle a LED inside this ISR.

I have struggled with this for days now and I'm not able find any "clear" answers online..

I using KDS 3.2.0 & PE with KSDK 1.3.0 to setup LLWU pin 8 (GPIOC, pin 4) as a wakeup source. Negative edge triggered.

This is the setup code generated by PE:

From hardware_init.c

void hardware_init(void) {

/* Enable clock for PORTs */

SIM_HAL_EnableClock(SIM,kSimClockGatePortA);

SIM_HAL_EnableClock(SIM,kSimClockGatePortB);

SIM_HAL_EnableClock(SIM,kSimClockGatePortC);

SIM_HAL_EnableClock(SIM,kSimClockGatePortD);

SIM_HAL_EnableClock(SIM,kSimClockGatePortE);

/* Setup board clock source. */

g_xtal0ClkFreq = 0U; /* System oscillator 0 is not enabled */

init_coredebug_pins(CoreDebug_IDX);

init_gpio_pins(GPIOA_IDX);

init_gpio_pins(GPIOC_IDX);

init_gpio_pins(GPIOD_IDX);

init_gpio_pins(GPIOE_IDX);

init_i2c_pins(I2C0_IDX);

init_i2c_pins(I2C1_IDX);

init_llwu_pins(LLWU_IDX);

init_lpuart_pins(LPUART1_IDX);

init_scb_pins(SCB_IDX);

init_uart_pins(UART2_IDX);

}

From Cpu.c - Components_Init()

/*! gpio_llwu_pins Auto initialization start */

GPIO_DRV_Init(gpio_llwu_pins_InpWakup,NULL);

/*! gpio_llwu_pins Auto initialization end */

/*! pwrMan1 Auto initialization start */

NVIC_SetPriority(LLWU_IRQn, 1U);

OSA_InstallIntHandler(LLWU_IRQn, &pwrMan1_llwuIRQHandler);

POWER_SYS_Init(powerConfigsArr, 1U, NULL , 0U);

POWER_SYS_SetWakeupPin(kPowerManagerWakeupPin8, kLlwuExternalPinFallingEdge, NULL);

INT_SYS_EnableIRQ(LLWU_IRQn);

The Interrupt handler is automatically added to Events.c and the prototype in Events.h

void pwrMan1_llwuIRQHandler(void)

{

/* Write your code here. For example clear LLWU wake up flags ... */

//CheckModeButton();

POWER_SYS_ClearWakeupPinFlag(kPowerManagerWakeupPin8);

GPIO_DRV_ClearPinOutput(LED_GREEN2);

}

What am I missing?

Med vennlig hilsen,

Thomas Haugen

Software Development Engineer

GSM: +47 930 35 863

E-mail: thomas.haugen@7sense.no<mailto:thomas.haugen@7sense.no>

7Sense Technologies AS

Kongeveien 73 Tel: +47 33 08 44 00

3188 Horten Fax: +47 33 08 44 01

Norway E-mail: sales@7sense.no<mailto:sales@7sense.no>

0 Kudos
Reply
8 Replies

1,377 Views
Robin_Shen
NXP TechSupport
NXP TechSupport

Hi

Please try to test the power_manager in SDK_2.2_FRDM-KL27Z.

...\SDK_2.2_FRDM-KL27Z\boards\frdmkl27z\demo_apps\power_manager

SDK_2.2_FRDM-KL27Z.pngPower Manager Demo LLS.png

Best Regards,

Robin

 

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

0 Kudos
Reply

1,377 Views
mjbcswitzerland
Specialist V

Hi Thomas

If you have vectors in Flash the interrupt vector will need to be (probably) manually entered in the file that defines its content.
Looking at the code that you have used it is inserting it into RAM (are you sure of the project configuration and have you used interrupts successfully before?). I would normally expect the environment to ensure all this for you but I generally only work with the one that you are to fix bugs for clients.

I just checked by using uTasker code:

INTERRUPT_SETUP interrupt_setup;            // interrupt configuration parameters
interrupt_setup.int_type       = WAKEUP_INTERRUPT;  // configure as wake-up interrupt
interrupt_setup.int_handler    = irq_run;           // run again after wake up
interrupt_setup.int_priority   = PRIORITY_PORT_C_INT; // interrupt priority level
interrupt_setup.int_port       = PORTC;     // the port that the interrupt input is on
interrupt_setup.int_port_bits  = PORTC_BIT1; // the IRQ input connected LLWU_P6 (SW3 on FRDM-KL27Z)
interrupt_setup.int_port_sense = (IRQ_FALLING_EDGE | PULLUP_ON); // interrupt is to be falling edge sensitive
fnConfigureInterrupt((void *)&interrupt_setup);  // configure interrupt

interrupt_setup.int_port_bits  = PORTC_BIT4; // J2-6 on FRDM-KL27Z
interrupt_setup.int_handler    = irq_sleep;  // sleep again after wake-up interrupt
interrupt_setup.int_port_sense = (IRQ_FALLING_EDGE | PULLUP_ON | ENABLE_PORT_MODE); // set the pin to port mode - this is needed if the pin is disabled by default otherwise the pull-up/LLWU functions won't work
fnConfigureInterrupt((void *)&interrupt_setup); // configure interrupt

The binary is attached that operates on the FRDM-KL27Z.

On the LPUART0 (OpenSDA VCOM) at 115200 Baud you can use the command line menu. In the "Admin" menu you can see the low power modes with "show_lp"
which displays:
0 = RUN
1 = WAIT [active]
2 = STOP
3 = VLPR
4 = VLPW
5 = VLPS
6 = LLS
7 = VLLS0
8 = VLLS1
9 = VLLS3

Now command LLS with "set_lp 6" and the board will freeze in the LLS state.

If you press SW2 (PTC1) it wakes up again to the running mode:

WOKEN - restoring WAIT mode


If you go back to LLS you can then test a falling edge on PTC4 (J2-6) and it will wake up and immediately go back to LLS. Therefore if you wake up a number of times it displays:
WOKEN - going to LSS again
WOKEN - going to LSS again
WOKEN - going to LSS again
WOKEN - going to LSS again
WOKEN - going to LSS again


You can get the source from GITHUB if you like [visit http://www.utasker.com/kinetis.html for links] - its LLWU mode is in the file kinetis_LLWU.h
It also allows you to test the operation (wake up, interrupts etc. in its KL27 simulator - using Visual Studio) in case you would like to investigate the full details to work out the problem in your environment.

In case of urgent requirements such difficulties can be fixed within a short time via remote desktop using the services provided at http://www.utasker.com/services.html

Regards

Mark

0 Kudos
Reply

1,377 Views
thomas_haugen
Contributor I

Hi,

I finally solved the problem. The problem was that I used PE to generate the INIT code for the LLWU handler and by another name than the default ISR name LLWU_IRQHandler()

So I commented out the OSA_InstallIntHandler() call and manually added the LLWU_IRQHandler()

in Events.c.

Using PE to install handlers and callbacks for UART’s, I2C etc works fine, but not for the LLWU. Why?

Regards,

Thomas

Fra: Robin_Shen

Sendt: 4. mai 2017 11:36

Til: Thomas Haugen <thomas.haugen@7sense.no>

Emne: Re: - Re: KL27 - KSDK - LLWU problem

NXP Community <https://community.freescale.com/resources/statics/1000/35400-NXP-Community-Email-banner-600x75.jpg>

Re: KL27 - KSDK - LLWU problem

reply from Robin_Shen<https://community.nxp.com/people/Robin_Shen?et=watches.email.thread> in Kinetis Microcontrollers - View the full discussion<https://community.nxp.com/message/902412?commentID=902412&et=watches.email.thread#comment-902412>

0 Kudos
Reply

1,377 Views
Robin_Shen
NXP TechSupport
NXP TechSupport

I am not sure if it was caused by the difference below.

The OSA_InstallIntHandler in Components_Init.

Components_Init.png

Components_Init_c.png

Best Regards,

Robin

0 Kudos
Reply

1,377 Views
thomas_haugen
Contributor I

No, I tried to remove the &, it made no difference. I had to comment out the //OSA_InstallIntHandler then add the default function handler, void LLWU_IRQHandler(void), into Events.c. 

I'm installing handlers for TPM0, I2C0, I2C1, UART2 and LPUART1 with OSA_InstallIntHandler(). It works fine, but not for the LLWU.

Best regards,

Thomas

0 Kudos
Reply

1,377 Views
Robin_Shen
NXP TechSupport
NXP TechSupport

Configure the PTC1 as LLWU wakeup pin. Test with FRDM-KL27Z board, the GREEN LED will light after press the SW3 buttom.

Attach file is that test project.

0 Kudos
Reply

1,377 Views
mjbcswitzerland
Specialist V

Thomas

If you are getting an interrupt it means that the processor has been (successfully) woken - it then will take the pending LLWU interrupt (assuming configured and not masked).

Since the interrupt is causing the default handler to be called it must mean that the interrupt vector is not present in the vector table (it will depend on whether you have vectors in Flash of in RAM on how this is done).

An alternative potential issue could be that the low power mode is not actually being entered and you have a port interrupt enabled on the pin that hasn't be set up correctly - but much less likely.

I have some background at
http://www.utasker.com/kinetis/LLWU.html
and videos at
https://www.youtube.com/watch?v=iZEMRiDmHzw
https://www.youtube.com/watch?v=kWNlsAoMly4
https://www.youtube.com/watch?v=v4UnfcDiaE4

Full low power operation is available in the code at the link below in case you would like to use a proven solution rather than fight with the case tool outputs.

Regards

Mark


http://www.utasker.com/kinetis.html for quality Kinetis firmware

0 Kudos
Reply

1,377 Views
thomas_haugen
Contributor I

Hi,

The vector table is placed in FLASH. Is that the problem?

I have checked that the handler is installed correctly in the vector table with irqNumber = 7.

OSA_InstallIntHandler(LLWU_IRQn, &pwrMan1_llwuIRQHandler);

This method is again calling:

void * INT_SYS_InstallHandler(IRQn_Type irqNumber, void (*handler)(void))

{

#if (defined(__CC_ARM))

extern uint32_t Image$$VECTOR_RAM$$Base[];

#define __VECTOR_RAM Image$$VECTOR_RAM$$Base

#else

extern uint32_t __VECTOR_RAM[];

#endif

/* Check IRQ number */

assert(FSL_FEATURE_INTERRUPT_IRQ_MIN <= irqNumber);

assert(irqNumber <= FSL_FEATURE_INTERRUPT_IRQ_MAX);

/* Check whether there is vector table in RAM */

assert(__VECTOR_RAM != 0U);

/* Save the former handler pointer */

void * retVal = (void *)__VECTOR_RAM[irqNumber + 16];

/* Set handler into vector table */

__VECTOR_RAM[irqNumber + 16] = (uint32_t)handler;

return retVal;

}

Regards,

Thomas

Fra: mjbcswitzerland

Sendt: 3. mai 2017 17:42

Til: Thomas Haugen <thomas.haugen@7sense.no>

Emne: Re: - Re: KL27 - KSDK - LLWU problem

NXP Community <https://community.freescale.com/resources/statics/1000/35400-NXP-Community-Email-banner-600x75.jpg>

Re: KL27 - KSDK - LLWU problem

reply from Mark Butcher<https://community.nxp.com/people/mjbcswitzerland?et=watches.email.thread> in Kinetis Microcontrollers - View the full discussion<https://community.nxp.com/message/902174?commentID=902174&et=watches.email.thread#comment-902174>

0 Kudos
Reply