Mising port pin interrupt when switching from LLS to RUN mode

[aleksandartrajk]

Hi,

I use KL05 (mkl05z8vfk4) microcontroller in LLS (Low Leakage Stop) mode.

I configured to waking up the processor from LLS with LLWU external pin PTA7 (LLWU_P3) on rising edge also I share the same pin as port interrupt pin on same edge detection.

When I trigger the pin the Cpu_OnLLSWakeUpINT() execute but port interrupt handler does not execute.

Q: Where should I share pin in processor component on Low power mode settings or in PORTA component?

Q: How to setup the pin to enable port interrupt handler execution?

Thanks in advance.

[Robin_Shen]

Hi

GPIO_Init can be used to configure PTA7as port interrupt.

The ISR of PTA7 need to be implemented by user.

Please refer below image:

Best Regards,

Robin

[aleksandartrajk]

Thanks Robin

I have configuration like your advice. My processor most of the time is in LLS mode and when edge happen on the pin (PTA7- LLWU_P3)  processor execute LLWU pin handler but does not execute port interrupt handler (where I use I2C communication).

[Robin_Shen]

In LLS mode: NVIC is disabled and LLWU is used to wake up . (Port interrupt is not active in LLS and so it won't trigger)

When first edge happens, it resumes normal run mode operation by executing the LLWU interrupt service routine. After recovery from LLS, the LLWU is immediately disabled.

In RUN mode: the edge will cause the port interrupt but not the wake up interrupt (since the LLWU is not active  RUN mode).

According to "I configured to waking up the processor from LLS with LLWU external pin PTA7 (LLWU_P3) on rising edge also I share the same pin as port interrupt pin on same edge detection." I think what you want is: the first edge wakeup MCU to Run mode, the second edge cause port interrupt.

I am little confuse, do you want to one edge cause two interrupts(LLWU interrupt and Port interrupt)?

Best Regards,

Robin

[aleksandartrajk]

Thanks Robin,

I understood very wall, you are right. Reading the documentation and watching options in Kinetis studio about pin shearing I thought that I can use same edge detection in both handlers. (It is not true.)

Regarding all those things, now I transfer my code from port interrupt handler to LLWU handler and I have issues whit I2C. You can see the conversation whit Mark.

Regards

Aleksandar

[mjbcswitzerland]

Aleksandar

I did a test on the FRDM-KL05Z, where I run I2C continuously to monitor the accelerometer on the board.
I then command it to go to LLS mode and the current drops to around 3uA (about 5mA when operating at full speed).
Using LLWU_P3 I wake it up and the I2C continues normally.
Here is the scope shot of wake-up from LLS (Channel 2 is PTA7):

This is the debug interface output:

When not in LLS mode the I2C is read as fast as possible (back-to-back requests).

Therefore I see no reason for problems waking and using I2C.

If you have a FRDM-KL05Z you can test with the attached binary. Debug is on OpenSDA UART at 115'200. Type 'L' on debug UART to switch to LLS. Falling edge on J7-4 wakes.

Regards

Mark

[mjbcswitzerland]

Aleksandar

I have added a short video showing how I set up the project to quickly test this complete operation as well as showing the real-time behavior.

https://youtu.be/iZEMRiDmHzw

If you are doing real developments and not just learning by doing you can get a complete working solution in the uTasker project - it is open source or supported, depending on requirements, but it saves time using proven code rather than needing to piece together and fix example code.

Regards

Mark

[aleksandartrajk]

I solved the problem finally, it was in interrupt priority levels.

I appreciate your time and explanation.

Mark thanks much.

[mjbcswitzerland]

Aleksandar

One week ago I suggested

>>Since the I2C operation looks OK I would suggest that you have a problem with its interrupt no longer being detected(?)

Can you explain why using the LLS mode caused the interrupt priorities to change so that it stopped?

Regards

Mark

[aleksandartrajk]

Hi Mark,

Using the LLS mode did not cause the interrupt priorities to change. Yesterday I saw that I have setup for LLWU interrupt as high priority and I2C as priority level 1, that was the reason to stopped my I2C communication. 

Regards

Aleksandar

[mjbcswitzerland]

Aleksandar

Interrupt priority settings is not a general explanation of a peripheral interrupt no longer being recognised; one can set any mixtures of priority levels without causing such an effect.

The only time that this would be an explanation is when the LLWU interrupt routine never terminates and so you need it to be pre-empted by a higher priority interrupt for other things to operate (nested interrupts).

Is it possible that your modification just makes it "look" like you have correct operation but the LLWU interrupt service routine is never quit or continuously interrupting? Are you clearing the LLWU interrupt source after you have woken up?

Regards

Mark

[aleksandartrajk]

Hi Mark,

Reading the documentation and watching options in Kinetis studio about pin shearing I thought that I can use same edge detection in both handlers. (It is not true.)

I understood that In LLS mode: NVIC is disabled and only LLWU is used to wake-up. In Run mode: LLWU is disabled and it detected peripheral interrupts.

I made the test to see that LLWU interrupt routine terminate and enter LLS mode again. All is fine.

My LLWU interrupt service routine enter and exit only when I trigger the pin. 

Yes, after LLWU ISR I clear the LLWU flags.

Regards

Aleksandar

[mjbcswitzerland]

Hi

In LLS mode the LLWU is active and so will wake up to RUN mode when the edge takes place.

The Port interrupt is not active in LLS and so it won't trigger.

Alternatively in RUN mode an edge will cause the port interrupt to fire but not the wake up interrupt (since the LLWU is not active  RUN mode).

This means that you will always only get one interrupt; the one depending on the mode at that point in time.

Regards

Mark

http://www.utasker.com/kinetis/FRDM-KL05Z.html
http://www.utasker.com/kinetis/LLWU.html

[aleksandartrajk]

Thanks Mark

I have implemented port interrupt handler on 2 different PORT pins (PORTA and PORTB) (3-axis sensor whit 2 interrupt lines) on two different priorities. All port handlers use I2C communication and it works perfectly. I would like to implement LLS mode for low power consumption, but considering your explanation, it seems I can not share same pin edge detection. 

In  Cpu_OnLLSWakeUpINT()  I check the source on wake up and read through I2C, but communication gets stuck (see picture below) -- I do not know the reason -- processor is in  RUN and as far as I know all activities should work normally. Do you have any idea?

[mjbcswitzerland]

Hello Aleksandar

If I understand correctly you have woken the processor from LLS mode with a LLWU port event, which you detect as the reason and use it to start an I2C operation. The I2C operation, however, doesn't continue as expected after the slave address has been sent (and acknowledged).

Since the I2C operation looks OK I would suggest that you have a problem with its interrupt no longer being detected(?)

I don't know the libraries that you are using but in case of problems there is a complete solution for your device at http://www.utasker.com/kinetis/FRDM-KL05Z.html which includes all low power modes, I2C and everything that a KL05 needs and has been proven in product use. It allows the KL05 to be simulated in (approx.) real time (including I2C devices). The binary at the link includes accelerometer operation on the FRDM board and also low power modes.
I2C solution: http://www.utasker.com/docs/uTasker/uTasker_I2C.pdf

Regards

Mark

[aleksandartrajk]

Thanks Mark

Yes, you have understооd correctly.

In LLWU port handler I start I2C communication but gets stuck.

What do you mean (you have a problem with its interrupt no longer being detected(?))?

[mjbcswitzerland]

Aleksandar

Your image shows that the processor wakes up and sends something across the I2C bus. It shows that the I2C slave ACKs, but the master holds the SCL line low.

You need to compare this with the "good" case and work out what the 'difference' is and then 'why' there is the difference.

I as assuming that the I2C driver is interrupt driven and that is why I suggested that maybe you have no more interrupt from it after waking - possibly explaining why it behaves differently. Possibly you move back to LLS mode again before the I2C transmission has completed (?)

Regards

Mark

[aleksandartrajk]

Hi Mark

I appreciate your time.

Yes, the I2C driver is interrupt driven.

I tested reading trough I2C before put processor in LLS mode and work fine. (see picture below). After that, I put the processor in LLS mode.

Then I trigger the wake-up pin PTA7 and in LLWU handler read again, I2C get stuck also processor get stuck. The CI2C1_OnMasterBlockSent() and CI2C1_OnMasterBlockReceived() does not execute. (picture in the previous post)

I check that processor do not go in LLS mode.

I have several sources to wake-up the processor, like LPTMR0 and in its interrupt handler, I use the I2C communication and work without issues(if PTA7 pin is turned-off as LLWU interrupt pin). 

Any idea, probably I should reinti I2C or something like that?

Regards

Aleksandar