ARM Technical Support Knowledge Articles

What can cause a STICKYERR in a CoreSight Debug Access Port (DAP)?

Applies to: CoreSight

Answer

STICKYERR (as defined in the ARM Debug Interface v5 Architecture Specification) can come from error signals returned from the Debug Bus or slave debug component to the Access Port (AP), or from the Debug Port (DP) trying to access an AP which is not present (for example, powered down or not present at that address), or from protocol errors in Serial Wire.

To investigate  unexpected assertion of STICKYERR, consider the following:

If the processor in the SoC design was delivered with a CoreSight Design Kit, ensure that any portable tests in the Integration Kit have been successfully ported to the SoC level and run in simulation. This is a good test of the basic hook-up of the Debug Port to the external pins of the SoC.

Check that the correct handshake protocol has been performed for CDBPWRUPREQ -> CDBGPWRUPACK and for CSYSPWRUPREQ -> CSYSPWRUPACK, and that these signals have not subsequently been illegally deasserted while debug is in progress. Also, check that power and clocks have been restored to the Debug and System domains before the corresponding 'ACK' signal was asserted. Check that power or clock have not been illegally removed from the domain(s) being accessed during the debug session.

Check that the DP was accessing an existing AP when the error occurred. Note that different variants of the DAP may have APs present at different positions on the DAP bus by default, and that implementations may have their own unique combination of APs on the DAP bus at arbitrary positions within the possible range of 0 - 255.

Check the documentation of the processor or CoreSight component being accessed when the problem occurs - some components (such as Cortex-A8) document specific conditions under which an error will be returned on the Debug APB bus for an access to a debug register.

Check for general issues with the target processor coming out of reset or power-down. Are all such signals timed correctly with regard to the clock and with regard to each other, and are they asserted for any relevant minimum duration?

Rate this article

[Bad]
|
|
[Good]
Disagree? Move your mouse over the bar and click

Did you find this article helpful? Yes No

How can we improve this article?

Link to this article
Copyright © 2011 ARM Limited. All rights reserved. External (Open), Non-Confidential