• State Suggested Answer
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 119 subscribers
  • Views 341 views
  • Users 0 members are here
Options
Related

hardware breakpoint not take

bradn

My application creates a hardware break point after translation has been setup and the MMU has been enabled.  When running inside ADS the break point exception is taken as expected.  However when a FPV model form the command line the break point exception does not occur.

The following is some of the debug info from TarmacTrace

638024 clk cpu0 R DBGBVR0_EL1 00000000:00000024
638356 clk cpu0 IT (319211) ffff000040003650:000040003650_NS d69f03e0 O EL1h_n : ERET

638473 clk cpu0 IT (319220) 00000020:000040400020_NS 314d8d56 O EL0t_n : ADDS w22,w10,#0x363,LSL #12
638473 clk cpu0 R cpsr 00000000
638473 clk cpu0 R X22 0000000050F44AD9
638474 clk cpu0 IT (319221) 00000024:000040400024_NS b174c12b O EL0t_n : ADDS x11,x9,#0xd30,LSL #12
638474 clk cpu0 R cpsr 00000000
638474 clk cpu0 R X11 7D29EE085EAFBC1C
638475 clk cpu0 IT (319222) 00000028:000040400028_NS 70c56aac O EL0t_n : ADR x12,0xfffffffffff8ad7f
638475 clk cpu0 R X12 FFFFFFFFFFF8AD7F

Any ideas why the hardware break point would work inside ADS but not from the command line, and any tips to resolve the issue ?

The ADS version I'm using is developmentstudio_platinum-2025.a-1

Thanks.

Parents
  • 0 Arm Employee Badge

    Hi Brad

    My name is Stephen and I work at Arm.

    Sorry, I can't immediately explain the issue you are seeing, but here are some suggestions:
    1) check that any FVP model "-C" parameters are the same in both scenarios
    2) check any necessary barrier instructions (e.g. ISB) are present after the write to the debug registers
    3) collect TarmacTrace in both scenarios and compare them
    4) try a simpler code execution case where there is no change of EL

    Stephen

Reply
  • 0 Arm Employee Badge

    Hi Brad

    My name is Stephen and I work at Arm.

    Sorry, I can't immediately explain the issue you are seeing, but here are some suggestions:
    1) check that any FVP model "-C" parameters are the same in both scenarios
    2) check any necessary barrier instructions (e.g. ISB) are present after the write to the debug registers
    3) collect TarmacTrace in both scenarios and compare them
    4) try a simpler code execution case where there is no change of EL

    Stephen

Children
  • 0 in reply to Stephen Theobald

    Hi Stephen, thanks for the reply. I was able to debug the issue a bit more.  As it turns out when running under the debugger reserved combinations  of HMC, SSCE, SSC, and PMC in DBGBCR<n>_EL1 do not behave correctly.

    The specific clause in the ARM ARM of interest is here is section D2.8.7.2 Reserved DBGBCR<n>_EL1.{SSCE, SSC, HMC, PMC} Table D2-12:

    "All combinations with HMC set to 0, SSCE set to 0, and SSC set to 0b01 or 0b10. When Secure state is not implemented."

    The observed behavior outside of the debugger was correct.

  • 0 Arm Employee Badge in reply to bradn

    Hi again Brad

    Thanks for your reply.  To investigate this further, we'll need some additional information from you.
    When you say "when running under the debugger", do you mean "when running on the FVP with the Arm DS Debugger connected via Iris"?
    Please can you explain your two scenarios in more detail and what you are trying to achieve overall.
    What are the values programmed into DBGBCR_EL1 and DBGBVR0_EL1?
    Were there any unexpected differences in the TarmacTrace collected in both scenarios?
    In what way do the "reserved combinations  of HMC, SSCE, SSC, and PMC in DBGBCR<n>_EL1 do not behave correctly"?  For Iris-based debug, those values shouldn't have any effect on a hardware breakpoint. 

    This may be a tricky issue to solve in a public forum.  I suggest that you open a (private) Support Case using the link below. Please reference this thread so that the team have some history.

    Stephen