I have a strange problem here. I have a idle loop in the RTOS I'm running:
Basically it does a WFI waiting for Systick (or another interrupt) to occur. This I have done successfully on several other NXP CM3/CM4 processors without problem (of course without the DSB/ISB).
However, on the RT1062 I see a problem with this. The idle loop above will not execute the WFI the first 5 seconds the system runs (because of the os_time > 500). I have a interrupt driven output routine that shows the systick timer registers, a counter that shows how many systick has occured and the current CPU clock frequency (uisng CLOCK_GetCpuClkFreq()).
The log from that:
From this it is clear that the systick runs perfectly ok before the 5 seconds has elapsed (and the WFI is called the first time). But, after the WFI has been called the first time, the systick interrupt will be extremely slow. When measuring a GPIO output that toggles on the systick IRQ, I can see it changes from the correct 10 mS to 7124 mS (might be 7124/2, I'm not sure) once the first WFI has been executed. The CPU clock is the same 600 MHz, the configuration of the Systick (CTRL) is the same (0x07) so the clock source is still the core clock.
What am I doing wrong here ?????
EDIT: I have a feeling that the systick stops while the CPU is waiting in the WFI instruction ?
EDIT: Same result if I change the SysTick clock from "internal" to "external" (100 KHz from the 24 MHz xtal osc)
So, I think I can answer my own question :smileyhappy:
It seems that the clock is stopped to SysTick while the CPU is "resting" in the WFI.
If I do a
CLOCK_SetMode(kCLOCK_ModeRun);
before it all starts, it seems to work perfectly as expected. If I measure the current consumption of my board, I can see that it wakes up periodically at 10 mS interval. If I remove the WFI, I can see a steady consumption that is significantly higher than when doing the WFI.
So I think this is the solution :smileyhappy:
Hope it eventually will help someone else....
Thank you very much, that helped me. I ran into that problem early last year, and while I made a workaround, I looked for an answer from time to time. And now I found your solution, which works. The problem occurs with a RT1052, RT1062 and RT1064, but not on a RT1010, RT1015 and RT1020.