The issue is reproducable by opening evkmimxrt1064_gpt_timer example under drivers->gpt and removing GETCHAR(); line in the main file. If _WFI(); is removed, the issue does not occur.
SEGGER Ultra debugger no longer can connect to the target. As a workaround, the bootmode can be changed to something else, like SD (not connected) to make the microcontroller get stuck in ROMCP when booting. Control can then be regained.
Assuming that this was done on a PCBA where there are no bootmode dipswitches, how could the control be regained and the controller reprogrammed? I was running these examples on a board we developed, and now it is pretty much bricked. It seems to me that JTAG should always be able to gain control of the processor.
So the questions are:
Best regards,
CarrotMan
已解决! 转到解答。
Hi @CarrotMan ,
Why you use _WFI() in your code, it will let the chip enter the low power mode, and some mode will disable the external debugger, then you can't connect it.
When you meet this issues, you even can enter the serial download mode, and download a new code which don't have _WFI() to recovery it.
Wish it helps you!
If you still have questions about it, please kindly let me know.
Best Regards,
Kerry
Hi @CarrotMan ,
Why you use _WFI() in your code, it will let the chip enter the low power mode, and some mode will disable the external debugger, then you can't connect it.
When you meet this issues, you even can enter the serial download mode, and download a new code which don't have _WFI() to recovery it.
Wish it helps you!
If you still have questions about it, please kindly let me know.
Best Regards,
Kerry