Hello,
I'm trying to debug an application on an i.MXRT1166. The application has a WFI instruction in the idle loop. As soon as that is reached, my debugger (Lauterbach Trace32) tells me that the core has been powered down.
For the i.MXRT1050, it was possible to disable that behavior by setting the LPM in CCM->CLPCR to 0 (remain in run mode). That allowed to debug an application without or with minimal changes.
I didn't yet find something similar for the i.MXRT1160/i.MXRT1170 family. How can I keep the core awake for debugging during an WFI instruction on these chips?
Best regards
Christian Mauderer
Solved! Go to Solution.
Hi @christian_mauderer ,
If your low power is entered, you just need to wait the wakeup.
Or you comment the low power code to stop the low power entry.
But, seems you can't accept the code modification, even have some way to stop the low power entry, you still can't accept the code modification.
In fact, the RT project is not big, I think just comment the low power API calling is very simple, and won't meet any issues if you remember to modify it back.
Best Regards,
Kerry
Hi @christian_mauderer ,
Thank you for your interest in the NXP MIMXRT product, I would like to provide service for you.
Do you really need the low power mode during debug? In fact, in the low power mode, the JTAG/SWD interface will be powered down, that's why you lost the debug.
If you want to debug the normal code, I suggest you comment the low power function at first, after all the normal code function works with the debugger, then you can add the low power function again.
This is also the method we are always doing.
Wish it helps you!
If you still have questions about it, please kindly let me know.
Best Regards,
Kerry
Hello @kerryzhou,
thanks for the quick response. You are right, that commenting power save functions is one possibility. But it means that I have to debug modified code. At the current development state it's annoying because I have to remember to patch the code for debugging and remove the patch for production. It still works but usually I prefer if I can debug unmodified code because it is easy to forget adding / removing the modification.
Beneath that: In my experience, I sooner or later will have a binary from a production version that I have to debug and where I can't rebuild the code because otherwise the problem vanishes. In these cases, I just can't avoid the low power modes by modifying the code.
Best regards
Christian
Hi @christian_mauderer ,
Lower power mode will power down the JTAG, so can't debug.
To the code patch, I think you can use:
#ifdef xxxx,
Then just when XXX is defined, then do the debug, otherwise, add the low power back.
This won't make any issues.
Just a test method.
Best Regards,
Kerry
Hello @kerryzhou,
does that mean, that there is no possibility to prevent the processor from entering low power mode when a WFI is executed? I think every processor I have seen in the past had such a feature.
I agree that in a lot of cases it will work to just disable low power modes. But not in all cases - and the ones where it doesn't work are the tricky ones.
In my current case, the WFI is in the idle task of an operating system. The system is an open source project. They won't accept a patch that disables that WFI based on some obscure debug define. So I have to maintain that patch locally. That means I have to add the patch, rebuild the system, rebuild the applications that link against the system and so on. I expect that I have to explain that process to every colleague who is working with the software. It's possible but not very convenient.
An example where it won't work to patch the software: In the past I had a problem more than once that either due to a stack overflow or due to a bad pointer, some memory at a random location has been overwritten. As soon as I changed only a single instruction of the code, the bug vanished because the memory layout changed. For these cases, I can't add a #ifdef somewhere to chase the bug.
In other cases, I debugged binaries from customers. I didn't have sources for these. Being able to disable low power modes using a debugger (by setting some register after the application has initialized the register) is crucial. I'm working on a software that later will be included in customer applications. So that case isn't unlikely.
Best regards
Christian
Hi @christian_mauderer ,
Yes, you are right, in fact, to the debug function in the low power mode, all the ARM related chip is similart.
Please check this post, whether it is useful to you:
https://mcuoneclipse.com/2019/01/02/regaining-debug-access-of-nxp-i-mx-rt1064-evk-executing-wfi/
Or you can run the code, and use the attach function to debug it, this post:
https://community.nxp.com/t5/LPC-Microcontrollers/Debug-in-WFI-mode/td-p/673763
My own experience, except comment the low power to debug, I can use printf instead of the real debug to print the information which I want to check, then at last, delete the print code.
Wish it helps you!
Best Regards,
Kerry
Hello @kerryzhou,
thanks for the links. The blog post (first link) you mentioned handles the i.MXRT1064. It describes the problem that it's difficult to access and re-flash the system as soon as an application executes a WFI. You need the right timing for that so that the debugger is connected before the WFI is executed. Also loading a new application if the current one goes into WFI can be tricky too, it's not my primary problem at the moment.
The blog post also mentions calling CLOCK_SetMode(kCLOCK_ModeRun); which is basically the method I described for the i.MXRT1050 in my opening post. For the i.MXRT1050 I either added that line to my code or used the debugger to set the register, depending on the situation.
Basically I'm searching for something like that only for the i.MXRT11xx. The whole power and clock part has been reworked in that family and I haven't yet found a register to prevent the core from sleeping (like the run mode in the i.MXRT10xx). I really assume that I just haven't found it yet - the clock/power part in the manual is a few hundred pages.
The second link (the community post) basically tells me that debugging in low power mode doesn't work. That's why I want to get rid of the mode during a debug session. It's really annoying, if the debugger suddenly tells "core power down" and can't even set a breakpoint any more. If the system is in idle, it's usually not long enough awake that the debugger can connect during that time.
Printf / printk debugging would be a very poor substitution for a real debugger. And for some of the problems in my earlier posts it wouldn't work.
Best regards
Christian
Hi @christian_mauderer ,
Thanks for your effort.
You can consider, in the low power mode, the debugger function is not supported!
So, you really need to find some other workaround to accept. Or debug before entering low power, or use some log to check it.
Thanks a lot for your understanding.
Best Regards,
Kerry
Hello @kerryzhou,
do I understand that correctly that there is officially no method to disable the low power modes when a WFI is executed? That would be a big disadvantage of that processor family.
Best regards
Christian
Hi @christian_mauderer ,
I already help you check with our internal low power expert.
No other way to debug in the low power mode. This is the chip feature.
Or you can use the wait mode to test, as the wait still have clock and power.
Wish it helps you!
Best Regards,
Kerry
Hello @kerryzhou,
thanks for the response. I understand that I can't debug in low power mode.
That's why I wanted to know whether there is a method to disable low power mode like in the i.MXRT10xx family (basically I asked that in my first question already).
I think I have a problem understanding your last answer (sorry, I'm not a native speaker), so sorry that I have to ask again: You say
Or you can use the wait mode to test, as the wait still have clock and power.
Do you mean one of the methods that need modifying the code that we already discussed or is that something different that I missed in an earlier response?
Best regards
Christian
Hi @christian_mauderer ,
If your low power is entered, you just need to wait the wakeup.
Or you comment the low power code to stop the low power entry.
But, seems you can't accept the code modification, even have some way to stop the low power entry, you still can't accept the code modification.
In fact, the RT project is not big, I think just comment the low power API calling is very simple, and won't meet any issues if you remember to modify it back.
Best Regards,
Kerry
Thanks for the clarification. I just was not sure about that last comment.
That more or less answers my question: There is no possibility to disable the power down mode when a WFI instruction is in the code. From my point of view, that's a sever limitation of that processor family.