• State Accepted Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 6 replies
  • Subscribers 351 subscribers
  • Views 26465 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

EDSCR err bit set after a write to EDITR

kka

Hi,

I have a very similar question to the resolved entry "reason for ARMv8 EDSCR err bit set".

So I try to follow that to give the state information.

Cortex-57

JTAG TCK = 3,788MHz.

ARM_STATE_AARCH64 is set

Before Halt state:

EDPRSR = 0x1

EDSCR = 0x03007C02

After Halt state:

EDPRSR = 0x1

EDSCR = 0x03006113

After Write to EDITR with opcode 0xd503201f for a NOP instruction:

EDPRSR = 0x11

EDSCR = 0x03006153

EDSCR differs from the resolved entry in bits HDE=1, RW=0100, EL=1

And Aarch64 has no thumb mode instruction, this does not solve my problem.

Any help is appreciated.

Parents
  • +1 Arm Employee Badge in reply to kka

    Yes, sounds like something isn't quite right.

    Is debug properly enabled on the target ?

    This might give you some hints :

    https://developer.arm.com/docs/265510992/10/how-do-i-enable-the-editr-register-in-an-armv8-a-processor

    though you may have to look through the OpenOCD code to see which bits it does and which bits you still need to do.....

    There are some debug authentication signals that may affect the behaviour here.

    For more on Debug Authentication, see the Arm Architecture Reference Manual v8-A, sec. H1.3 ' Required Debug Authentication', available here

    Ensure that DBGEN  signal is b1, and there are others, depending on which world you are in (secure/non-secure) as they have separately enabled debug capabilities (you may not be able to debug the Secure world, for example, if the SoC vendor has set  both SPNIDEN and SPIDEN = b0)

    Having said this, if debug authentication was the issue here, I wouldn't expect the core to halt and enter debug state!!

    Regards,

    Stuart

Reply
  • +1 Arm Employee Badge in reply to kka

    Yes, sounds like something isn't quite right.

    Is debug properly enabled on the target ?

    This might give you some hints :

    https://developer.arm.com/docs/265510992/10/how-do-i-enable-the-editr-register-in-an-armv8-a-processor

    though you may have to look through the OpenOCD code to see which bits it does and which bits you still need to do.....

    There are some debug authentication signals that may affect the behaviour here.

    For more on Debug Authentication, see the Arm Architecture Reference Manual v8-A, sec. H1.3 ' Required Debug Authentication', available here

    Ensure that DBGEN  signal is b1, and there are others, depending on which world you are in (secure/non-secure) as they have separately enabled debug capabilities (you may not be able to debug the Secure world, for example, if the SoC vendor has set  both SPNIDEN and SPIDEN = b0)

    Having said this, if debug authentication was the issue here, I wouldn't expect the core to halt and enter debug state!!

    Regards,

    Stuart

Children
  • 0 in reply to Stuart Hirons

    Ok, as you have said, here the initialization is missing some lines, which are relevant for resuming the PC, which are there in openOCD. But other than that the only difference was CTI unlock and this did not help with the problem either.

    My DBGAUTHSTATUS_EL1 register reads 0x000000FF, which I understand, that everything should be enabled.