Efficiency is at the heart of the ARM® architecture. ARM cores are commonly used in products where power consumption and battery life are critical considerations, but this can pose additional challenges for a debugger. For DS-5 v5.21, DSTREAM support for debug over power-down has been enhanced, giving improved “out of the box” debugger stability for power-critical ARM implementations.
Many ARM® Cortex® cores are designed to be powered down when they are not needed. Alongside the in-built efficiency of the ARM architecture, this enables very effective power management. Individual cores or entire clusters of cores (particularly in ARM® big.LITTLE™ implementations) can power down when they are not needed, providing substantial reductions in power consumption. However, when a core powers down its memory-mapped debug registers may also power down, and that causes problems for a debugger.
Cores have two independent power domains. The main domain serves the core itself, but there is a smaller power domain that supports only a small number of critical debug registers. If the main core domain is powered down but the debug domain is kept powered up, power consumption is still substantially reduced but a debugger can still read information about the core’s power state. The debugger can then make an informed decision about which operations are currently possible for that core, and which other registers are available. The debugger can correctly display the core’s current power state and debug availability.
However, control of the power domains is implementation specific, and it is not uncommon to find that a core’s debug domain becomes powered down. Sometimes the two domains are linked – so that when the core powers down, the critical debug registers also become unavailable. Sometimes the debug power domains are linked to the overall power domain for a cluster of cores. In this implementation, debug domains remain available until all the cores in a cluster have been powered down. In this case, access to one core’s debug registers may be affected by the power state of a different core in that cluster.
When critical core debug registers become unavailable through power-down, the debugger is unable to determine the power state of the core. The debugger will be unable to determine which operations are currently available for that core, and may attempt to access core registers that are not currently accessible. The result is likely to be a loss of control of the core, but in some cases one of the SoC’s internal busses may become locked by a hung transaction.
In most SoCs, there is a power control block containing registers which show the current state of various power domains. Therefore it is possible to hand-craft support for individual SoCs, enabling the debugger to read and then interpret information from the SoC’s power control block. Unfortunately, there are two drawbacks with this method:
Firstly, because the debugger has to read information from the SoC’s power control block and interpret it before accessing core debug registers, there’s a risk of race conditions. The longer the delay between the information being read and being interpreted and acted upon, the greater the risk that the core’s power state will change. This means that the additional debugger functionality has to be implemented as close to the SoC as possible – in DSTREAM. Making changes to the DSTREAM firmware is a specialist task that can only be carried out by the ARM UK debugger engineering teams, it cannot be scripted by an ARM FAE or a debugger user. Obviously, the greater round-trip delays of lower cost “JTAG wiggler” probes (where processing is carried out on the host instead of inside the probe) may prohibit this kind of functionality
Secondly, the ARM UK engineering teams will need information about the power control block in the SoC – how to access the registers and how to interpret their contents. This information may not be easily available, and it may be considered confidential – and this can introduce implementation delays.
For DS-5 v5.21, DSTREAM implements a number of enhancements for debug over power-down. Provided that the registers in a core’s debug power domain have tie-off values (this means that debugger accesses during power-down fail cleanly, and result in an error rather than a hung transaction on the debug bus), DSTREAM now performs additional interpretation of register access failures. DSTREAM is able to intelligently interpret some register access failures as a core power-down, thereby keeping debug control of the core and correctly displaying the core’s power state in the DS-5 display. This removes the need for the ARM UK engineering teams to hand-craft support for individual SoCs, and the need to collect difficult or confidential information.
In DS-5 v5.21, this enhanced power-down support is implemented for ARMv7 cores. Enhanced support for ARMv8 cores is partly implemented, and will be completed in future releases of DS-5.
Paul, excuse me. I read this blog. It seems that my question https://community.arm.com/tools/f/discussions/8902/dstream-target-message-could-not-determine-target-state is related with this blog. If you have free time, can you help to take a look? Thanks.
Hi,
If you’re using DS-5 debugger and DSTREAM to debug code running on Juno, then DS-5 support for debug over power-down should work automatically, there’s nothing extra that you need to do. DSTREAM will automatically detect when cores power down, and DS-5 will correctly show the power status of each core you’re connected to.
DS-5 support for power-down on Juno is good “out of the box” because DSTREAM contains custom functionality for Juno. The key advantage of the enhancements in DS-5 v5.21 is that they allows us to provide excellent support for debug over power-down on a wider range of targets without having to add custom, target-specific functionality to DSTREAM.
Thanks for your blog.
Can i use Debug over power down in juno board?" if it is available, how can i do it?