Since we are working with the RT1060, we often ran into a situation, where we could not access the CPU with the debugger anymore. It was always some kind of software bug during development.
The problem is, that we are developing the software in flash memory. And when such faulty software is in flash, it keeps booting each time after power up and locks out the debugger again, so that it is not possible to erase that software anymore.
The only way to get out of this situation, is to change the boot mode from SPI flash to something else. Then it was again possible to access the cpu with the debugger and erase the flash.
We have now found a way to easily reproduce this situation on a RT1060 dev board. We attached a sample project for this. We reproduce that situation by trying to access the PHY, while the ENET peripheral is not enabled yet.
What is the reason that the debugger can't accesss the CPU anymore in such a situation? We do not experience this with other ARM processors.
Is there any other way to get access again, without need to change the boot mode?
Thank you for your hint. I have read through the article.
But unfortunately my example was a bit misleading. The WFI instruction is not "necessary" to produce the problem. The instruction was just there because it was in the "hello world" example.
In our productive software, we do not have an operating system and we never put the CPU into wait mode.
You can remove the WFI instruction from the example and the problem still appears.
It must be something different. We have had the problem in different situations during our development.
One assumption is that the CPU is stalled when a peripheral is accessed when e.g. the clock is not enabled for this peripheral.
I recommend you to check the following blog from a colleague that explains different ways to regain debug access executing WFI that you may find helpful.
Hope it helps!