KW41Z Power Manager Demo App not working

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

KW41Z Power Manager Demo App not working

1,944 Views
thibautkoch
Contributor II

Hi,

I recently bought a KW41Z development kit and trying to understand the different functionalities I need by going though the demos. Most of them worked flawlessly but power_manager and power_mode_switch seems not to be fully functional out of the box.

Both starts without troubles and show on my UART or debug console (depending on which options I chose when downloading the demo) a menu to select the desired power mode.

From option A to E (Run, Wait, Stop, VLPR and VLPH) everything behave as intended (I didn't check the consumption but I think there is no problem) but for all the other modes (VLPS, LLS/LLS3, VLPR0, VLLS1, VLLS2 and VLLS3), be it using LPTMR or SW3 (GPIO) triggers, it seems that it automatically wakes up just after being put to sleep. I looked at the most plausible causes (switching between UART/stock debugging, configuration of the ide...) but nothing seems to make it work.

I followed the exact same procedure described here for dowloading each component and dowloaded the demo the same way it's done for the hybrid (BLE+Thread) demo : Getting Started with FRDM-KW41Z | NXP 

Others seems to have the same kind of problem (Low power mode with KW41Z ) but he managed to get LSS3 working which was sufficient for him. I need under 10uA most of the time while retaining some core data so it's not enough for me even if I managed to do the same.

How can I make it work ?

Is there some parameters which could induce such behavior ?

Thanks in advance.

Regards, 

Loïc

14 Replies

1,641 Views
Sebastian_Del_Rio
NXP Employee
NXP Employee

Hi Loïc, I hope you're doing well!

 

I tried replicating the issue you're experiencing, and tried setting the device in all of the available power modes using the power_manger and the power_mode_switch SDK examples, from SDK versions 2.2.1 and 2.2.2, but did not run into any issues with it.

 

I tried both methods of waking up the device, with the LPTMR and with SW3, and both worked as expected.

 

Were any changes done to the example code?

Could you please try performing a mass-erase operation on your board and reprogramming the SDK example?

Also, could you please confirm the Jumper Configuration with Chapter 4.2 of the FRDM-KW41Z Board User's Guide?

 

Please let me know if you still have issues.

 

Take care, best regards,

Sebastian

0 Kudos

1,641 Views
thibautkoch
Contributor II

Hi Sebatian,

Thank you for your answer, I use SDK 2.2.1, no changes were done to the sample code.

I tried with both boards I received so I will try mass-erase on one but I don't know how to procede, I saw I had to set a register to a certain value but through what am I supposed to modify this register ?

I'm debugging through the usb port, so I left the board as is in this configuration :

pastedImage_1.png

Also I don't have any way currently to add the jumpers in section 4.2 since I'm teleworking and would need to weld some pins to the board. 

0 Kudos

1,641 Views
Sebastian_Del_Rio
NXP Employee
NXP Employee

Hi Loïc,

 

Could you please try the SDK example in the newer 2.2.2 Version to see if it behaves the same in your board?

 

Also, could you please let me know which board revision are you using? It should come on a sticker attached to the underside of the board.

 

Take care, best regards,

Sebastian

0 Kudos

1,641 Views
thibautkoch
Contributor II

Hi Sebastian,

I tried the newest SDK 2.2.2.

pastedImage_2.png

I have run into the exact same issues. One thing I noticed too is that the option E (VLPW) behave the same bad way the others do in some occasion but I couldn't figure out if there was a pattern. It's not instantaneous as the others though, and when it does so the device go back in run mode instead of VLPR (same as the others).

I'm using a board with revision C2.

Thank you very much for your time.

Best regards,

Loïc

0 Kudos

1,641 Views
Sebastian_Del_Rio
NXP Employee
NXP Employee

Hi Loïc,

 

Unfortunately, I have not been able to replicate this issue. Is it possible to try performing a mass erase to your board? Is it possible to test this SDK example using a different board revision?

 

Please let me know if you need any more information.

 

Take care, best regards,

Sebastian

0 Kudos

1,641 Views
thibautkoch
Contributor II

Hi Sebastian,

I erased it using j-flash lite, same problem. I don't have any other boards than the two I received in the box.

Most I can do is a clean reinstall of the MCU/J-link software and SDK, or ask to buy a new kit.

Take care and thank you for your time.

Best regards,

Loïc

0 Kudos

1,641 Views
Sebastian_Del_Rio
NXP Employee
NXP Employee

Hi Loïc,

 

I was able to get a hold of a FRDM-KW41Z Rev. C2 board, and I was able to replicate the behavior you're experiencing.

 

We will take a closer look at it, and I will provide an update soon.

 

Please let me know if you need any more information.

 

Take care, best regards,

Sebastian

0 Kudos

1,641 Views
thibautkoch
Contributor II

Hi Sebastian,

That's a very good news !

I hope the problem is easy to fix. I will work on the bluetooth part for the moment.

While you are at it, the glucose meter from freertos didn't display any values on the android application while the health termomether did, didn't investigate that further but you may want to.

Thank you very much and have a nice week-end !

Best regards,

Loïc

0 Kudos

1,641 Views
Sebastian_Del_Rio
NXP Employee
NXP Employee

Hi Loïc, I hope you're doing well!

 

After some close examination of the new C2 Rev. FRDM KW41Z board, I was able to determine the cause of the behavior you were reporting.

 

Revision C2 no longer has some of the jumper headers soldered to the board, such as the DCDC configuration jumpers.

Instead, these jumpers come pre-connected to set the board to a Buck Auto-Start DCDC configuration, which doesn't allow the use of some of the VLLSx power modes.

 

To allow the use of these power modes, the DCDC should be configured in bypass mode by physically cutting the default connections on J16, and soldering jumper headers to perform the following connections:

pastedImage_3.png

 

More information about these new board configurations can be read in the FRDM-KW41Z Freedom Development Board User's Guide for Rev. C2 (FRDMKW41ZUGvC2).

 

Please let me know if you need any more information.

 

Take care, best regards,

Sebastian

0 Kudos

1,641 Views
thibautkoch
Contributor II

Hi Sebastian,

Sorry for the delay I didn't have the material to do what you suggested.

I mounted the jumpers but J16 is the ground so I wasn't able to cut it, can you send me a photo of your board ?

Without J16 cut I have an error : 

Error in final launch sequence:

Failed to execute MI command:
-target-select remote localhost:2331

Error message from debugger back end:
localhost:2331: Aucune connexion n\222a pu être établie car l\222ordinateur cible l\222a expressément refusée.
Failed to execute MI command:
-target-select remote localhost:2331

Error message from debugger back end:
localhost:2331: Aucune connexion n\222a pu être établie car l\222ordinateur cible l\222a expressément refusée.
localhost:2331: Aucune connexion n\222a pu être établie car l\222ordinateur cible l\222a expressément refusée.

Could not connect to target.
SEGGER J-Link GDB Server V6.62d Command Line Version
JLinkARM.dll V6.62d (DLL compiled Mar 2 2020 09:22:41)
Command line: -nosilent -swoport 2332 -select USB=621000000 -telnetport 2333 -singlerun -endian little -noir -speed auto -port 2331 -vd -device MKW41Z512xxx4 -if SWD -halt -reportuseraction
-----GDB Server start settings-----
GDBInit file: none
GDB Server Listening port: 2331
SWO raw output listening port: 2332
Terminal I/O port: 2333
Accept remote connection: localhost only
Generate logfile: off
Verify download: on
Init regs on start: off
Silent mode: off
Single run mode: on
Target connection timeout: 0 ms
------J-Link related settings------
J-Link Host interface: USB
J-Link script: none
J-Link settings file: none
------Target related settings------
Target device: MKW41Z512xxx4
Target interface: SWD
Target interface speed: auto
Target endian: little
Connecting to J-Link...
$$UserActionStart$$: Terms of use
$$UserActionEnd$$: Terms of use
J-Link is connected.
Device "MKW41Z512XXX4" selected.
Firmware: J-Link OpenSDA 2 compiled May 6 2016 11:04:17
Hardware: V1.00
S/N: 621000000
Checking target voltage...
Target voltage: 3.30 V
Listening on TCP/IP port 2331
Connecting to target...
InitTarget()
Connect Under Reset
Communication error while accessing MDM-AP.
Connect Under Reset
InitTarget()
Connect Under Reset
Communication error while accessing MDM-AP.
Connect Under Reset
ERROR: InitTarget(): PCode returned with error code -1
InitTarget()
Connect Under Reset
Communication error while accessing MDM-AP.
Connect Under Reset
InitTarget()
Connect Under Reset
Communication error while accessing MDM-AP.
Connect Under Reset
ERROR: InitTarget(): PCode returned with error code -1
ERROR: Could not connect to target.
Target connection failed. GDBServer will be closed...Restoring target state and closing J-Link connection...
Shutting down...
Could not connect to target.

0 Kudos

1,641 Views
Sebastian_Del_Rio
NXP Employee
NXP Employee

Hi Loïc,

 

Setting J16 to 1-2 configuration will send the PSWITCH pin of the MCU to GND, indicating Bypass mode to the MCU:

pastedImage_2.png

Please also note that jumpers J38 and J39 by default come open, and for Bypass mode to work correctly, should also be shorted/closed:

 pastedImage_3.png

Please let me know if you continue to have issues.

 

Best regards,

Sebastian

1,641 Views
thibautkoch
Contributor II

Hi Sebastian,

In Bypass mode I'm not able to debug the board, same as described in the precedent comment. However it seems that a mode I used by mistakes is working fine (J38 on, J39 on, J16 5-6 and J17-4). Should I test it or could it damage the board ? It could be that my J16 is reversed explaining why it works.

Thanks,

Loïc

0 Kudos

1,641 Views
Sebastian_Del_Rio
NXP Employee
NXP Employee

Hi Loïc, 

We do not recommend using other configurations for the DCDC jumpers as they could cause the device to malfunction and could cause damage. 

Could you please confirm the connections for J16 to ensure a correct DCDC circuit configuration?

Please let me know if you need any more information.

Best regards,

Sebastian

0 Kudos

1,641 Views
thibautkoch
Contributor II

Hi Sebastian,

Sorry for the delay but we were able to do proper measurement only this week and it turns out that the J16 connection we thought was entirely cut wasn't. That's solved and the code seems to work.

I say seems because when we do the measurements on J18, it stays at around 8mA regardless of the mode displayed by the example code. Is there a problem with my measurement location or is it an anormal behavior ?

Best regards,

Loïc

0 Kudos