iMX6 still runs hot with DVFS

Before the addition of DVFS to the WEC2013 image, our iMX6 with just a temperature monitoring program running was at 68C. With 1.3b4 the temperature has only dropped to 58C and the current consumption is just a few mA less.

Is this expected behaviour with DVFS and is there any way to reduce the power consumption and (heat generation) further?

Please consider that DVFS is disabled by default. To enable it you need to enable it using the registry key described here:
https://developer.toradex.com/knowledge-base/apaliscolibri-imx6-dvfs-on-windows-embedded-compact
Temperature may depend on external factors like enclosure etc., but you should see quite a difference in power consumption.
In image 1.3b4 you can also enable debug messages on the serial console to see if the DVFS implementation is actually changing the CPU speed.
If it doesn’t, it may be that some threads are using CPU intensively. If those are low-priority threads they may not be noticeable in terms of performances (they will release CPU to high-priority ones when needed), but will impact power consumption.

Thanks Valter, I’ll try that.

Will DVFS affect the values returned by QueryPerformanceCounter() and QueryPerformanceFrequency()?

Those function should return values in uSeconds in rev 1.3b4 and newer, so the value will not be impacted by frequency changes.

I have found that enabling DVFS adversely affects the millisecond timing of external interrupts so I’ve have had to disable it. Disabling the GPU as per your link has had a useful effect, the SoC is now running around 46C in open air.

What do you mean with “millisecond timing”? Interrupt latency will be higher if the interrupt is handled when the CPU is running at minimum clock speed (80Mhz), you may reduce the effect by setting minimum CPU frequency to a value that grants the latency you can accept.

Using QueryPerformanceCounter() to determine external interrupt pulse edge timings with millisecond accuracy is rock-solid without DVFS but the timings are both too long (by around 40ms) and too variable with DVFS enabled.

QueryPerformanceCounter should be reliable and return values in uS, do you experience something different? Interrupt latency may increase when DVFS is enabled because the code that changes CPU frequency needs to lock the CPU while changing freq/voltage.
If you don’t always need to do this low-latency activity you can check this:

https://developer.toradex.com/knowledge-base/apaliscolibri-imx6-dvfs-on-windows-embedded-compact#control-dvfs-from-application

and keep the CPU working at the highest frequency (so disabling DVFS) only when you are performing that specific task, in this way you can lower temperature and save power for the rest of the time, at least.

If we measure the rising and falling external interrupt times in uS with DVFS disabled, we can measure consistent incoming pulse widths of 75ms +/- 1ms. If we enable DVFS, the pulse width measurement is around 114ms with a variation of around 10ms.

Unfortunately the interrupt timings are a primary I/O mechanism for our application and need to be accurate and consistent to within a few ms all of the time, so we can’t turn the DVFS on and off dynamically.

it’s 75 microseconds or 75 milliseconds? If it’s microseconds, DVFS can explain some additional jitter, if it’s milliseconds then the time difference is too big and if you have a way to let me reproduce the issue on our EVB I would like to check what’s happening. I can’t promise a quick fix, but will update you on this.

We have incoming pulses for which we use interrupts to pick up the rising and falling edges. We use QueryPerformanceCounter within the C++ event handler to calculate the pulse lengths. On both a PXA270, and now on an iMX6 without DVFS, we can read repeated pulses of 75ms duration with jitter of no more than 1ms. If we turn on DVFS, the same incoming pulses are measured at around 114ms duration with around 7ms jitter. I’m not sure how that could be reproduced on your EVB.

So it’s really milliseconds?
On the EVB I can generate input pulses on a GPIO pin.
If you can share a code sample that measures them I can test it here.