VLLS on K20 with MQXLite

[michaelplayle]

I have been tasked with debugging an application built with MQXLite and trying to get it to enter & exit VLLS2.

I am in the process of determining if the peripherals are being disabled prior to entry into VLLS2 to ensure those are not causing it to hang in an "undefined" state.

I have tried to verify the VLLS2 mode is properly configured (as compared with a bare-metal test application that works).  It looks like all the register settings are being correctly made.

Symptoms: The processor appears to be entering VLLS2, but does not respond to the configured wake-up pins (one is a reed-switch).  Attempting to pause the debugger (JLink) gets a "halt failed" message.  When attempting to resume or reset the processor, it gives the appearance of having lost the application - the debug stack trace indicates trying to run from address 0xFFFFFFFF like it has tried to go to an undefined or lost memory address.

Question #1: How should the necessary ISRs be defined or installed (and where)?

We are using RTC and two external pins for wake up sources.  They appear to be correctly defined for the LLWU module.  I know that a LLWU ISR and Port ISR will be required for the LLWU module to call before it goes to the reset path.  I do not know if they are getting correctly established.  The MQXLite code as inherited is using both the _int_install_kernel_isr() and _int_install_isr() routines/methods with both types of isr table references (inside the RTOS and outside the RTOS).

Question #2: Is there a more specific application note for setting up the power management in MQXLite?

I have already gone through AN4503, AN4447 and AN4470.  The LPM driver referenced appears to only be available for full MQX and not part of the MQXLite (as downloaded in PExDriverSuite_v10.4).  The afore mentioned bare-metal test application that works is known to be disabling all peripherals prior to VLLS2 entry.  The MQXLite based application is unknown.

[michaelplayle · Accepted solution]

Our other developer spent additional time on this over the weekend and was able to determine a method to force MQXLite to leave the very base level vector table (as defined in the Vectors.c file) at the original base address of 0x00000000 so that the LLWU interrupt controller can properly locate the desired vectors.  He then adjusted the MQXLite routine that copies the vector table to RAM to read from that base location for the RTOS's active copy used by it.  He also had to make minor adjustments to the "install isr" routines used by the RTOS.

We now have VLLS2 working in MQXLite without causing additional problems with the RTOS installing ISRs as needed by various tasks as they are initialized.

[yasuhikokoumoto]

Hi Michael,

although I don't know about MQX or MQXLite, did you set LLWU_PE1, LLWU_PE2, LLWU_PE3, LLWU_PE4 corresponding to the wake-up pins and set LLWU_ME corresponding to the wake-up module (RTC) and clear LLWU_F1, LLWU_F2, LLWU_F3 corresponding to the wake-up flags? You should also set NVIC for the LLWU interrupt. I can think of only these procedures.

Best regards,

Yasuhiko Koumoto.

[michaelplayle]

Hi Yasuhiko Koumoto,

Yes, I did those steps in the bare-metal version.  I also tried to ensure they were all being done in the MQXLite version, but could not guarantee the NVIC (or rather it's equivalent) in the MQXLite version was getting set correctly.  In the RTOS versions (MQX & MQXLite) the ISR vector table(s) seem to get relocated and abstracted.  This appears to me to be the stumbling block.  I am trying to find out how to get around that and keep the RTOS satisfied for it to still "install" soft ISR vectoring.

Best regards,

Michael Playle

[yasuhikokoumoto]

Hi Michael,

you can get the vector table base address from VTOR (whose address is mapped at 0xE000ED08). Unless VTOR value was known, the LLWU interrupt could be enabled by the NVIC registers as the following.

              NVIC_ICPR0 = 1 << 9;
              NVIC_ISER0 = 1 << 9;

These are the MK20DZ50. Cannot these help you?

Best regards,
Yasuhiko Koumoto.

[michaelplayle]

Hi Yasuhiko Koumoto,

There is not a problem with setting the "enable" (NVIC_ISER) and the "priority" (NVIC_ICPR).  I have confirmed these are getting set as desired.  It appears to be with the actual vectoring address that is involved as the MQXLite appears to relocate the actual vector table in a way that conflicts with the ROM addressing used by a bare-metal application.  The vector table seems to end up relocated into RAM instead of remaining at 0xE000E000.  We are using an MK20DX256VLK7 processor.

Best regards,

Michael Playle

[macl]

Hi Michael,

We did a training class at FTF last year about using low power features of Kinetis MCUs with MQX and MQX Lite RTOS.  The last section is about using the power mode control features of Processor Expert with MQX Lite.  I highly recommend you check out this training.  Using the built-in features of processor expert might make things go more smoothly.

The presentation is online at the link below.  I am attaching the lab guide and software demo.  Hope this helps.  Please note, this is demo software, not fully tested or officially released.  :smileyhappy:

Hands-On Workshop: Create Low-Power Applications with MQX™ and MQX™ Lite RTOS

Thanks,
Mac

[michaelplayle]

Mac,

I had found a similar Freescale presentation about the Low Power in MQX & MQXLite.  They do not discuss VLLSx modes.  Are those modes not supportable when using MQX or MQXLite?  Is there an explanation for why they do not seem usable through MQX and MQXLite?

I have been able to get LLS working under our application as a "fallback" option, but we would at least like to understand why VLLSx modes fail.

Michael Playle

[macl]

Hi,

Sorry, I don't know all the details, but I do know that waking up from VLLSx modes causes the system to go through a reset (everything gets re-initialized).  This still should not prevent entering the mode.  I believe that some of the registers are write-once, so I recommend checking the software flow and see if the key registers are accidentally being written more than once. 

Thanks,
Mac

[michaelplayle]

Mac,

I have already checked all of that.  I can get the code to enter the VLLS2 mode.  The failures happen on exit from the mode.

We are using an external reed switch on PE10 as a wake-up source.  I know I have that correctly configured prior to entry into VLLS2.  (It wakes the unit when using LLS instead of VLLS2.)  It acts like the LLWU ISR vectoring is lost and the unit does not recover or go through reset.  The debugger indicates it is trying to run code at address 0xFFFFFFFF (like the whole vector table has been lost).

In a bare-metal test base, I can get the VLLSx modes working fine and they do go through the reset as expected.  When we try to port that functionality into the MQXLite based application it fails as described.

[macl]

Hi Michael,

This is a bit beyond my area of knowledge.  I am going to recommend this thread be added to our community subspace for Kinetis MCUs. 

Thanks,
Mac

[michaelplayle]

Hi Mac,

Putting the question to the community space is fine by me.  Can you facilitate that for me?

Perhaps someone in the community will know the underlying fundamentals of MQX and MQXLite that are preventing use of VLLSx modes.