Re: Emulation of 'System OFF' mode in ARM nRF51 SoCs

["Philippe Mathieu-Daudé" <philmd@linaro.org>]

Hi Chris,

On 14/6/23 04:27, Chris Laplante wrote:
> Hi all,
> 
> I am working on improving nRF51 emulation. Specifically I want to implement the special "System OFF" mode. System OFF is a power saving mode. In this mode, the system can only be woken up by a reset or a handful of peripherals (most notably, GPIO via high/low level detection on configured pins). System reset is triggered upon wakeup.
> 
> I've been digging into the QEMU mailing list and source code and have come to the conclusion that deep sleep and low power modes are not implemented. There seems to be support for turning off ARM CPU cores, e.g. as used by imx6_src.c. But that doesn't apply here because I only have one CPU.

What problem are you getting with a single CPU?
The "arm/arm-powerctl.h" API should work well.
If you scheduled a timer, I expect it to awake
your CPU on expiration. You can also use a QMP
command to toggle a GPIO and trigger an IRQ.

You can use the qtest API to test your code,
see some tests in tests/qtest/ using:
- qtest_set_irq_in()
- qtest_qom_set_bool() for GPIO

Regards,

Phil.

> So ultimately what I think I will try to implement is what the nRF51 reference manual calls "Emulated System OFF mode". From the reference manual:
> 
>      If the device is in debug interface mode, System OFF will be emulated to secure
>      that all required resources needed for debugging are available during System OFF...
>      Since the CPU is kept on in emulated System OFF mode, it is recommended
>      to add an infinite loop directly after entering System OFF, to prevent the CPU from
>      executing code that normally should not be executed.
> 
> Does anyone have any guidance on how to implement this? I don't particularly care about fidelity. As long as a GPIO level trigger can break the CPU out of the infinite loop (which the reference manual tells users to add) and jump into the reset vector, it will be good enough for my use. I don't really care about masking out other interrupt sources, for example.
> 
> Thanks,
> Chris
>