• State Accepted Answer
  • Locked Locked
  • Replies 3 replies
  • Subscribers 350 subscribers
  • Views 3661 views
  • Users 0 members are here
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

Cortex-M33 MTB configuration - when the MTB buffer is full

Mintancy
Hi everyone, I am exploring the MTB feature on Cortex-M hardware and doing experiments on Arm mps2+ FPGA board with the Cortex-m33 image, which enables the TrustZone technique. From what I learned, the MTB can be configured to record non-sequential branches of the execution. The record will be written directly to the allocated SRAM by the MTB unit automatically. During the experiment, I have several questions.
  1. When the MTB buffer is full, there are two ways to handle it. One way is to rewrite the buffer from the very beginning. Another way is to set a watermark, which will let the PE enter the Debug State. I checked the document that the Debug State means we need an external debugger or another core to handle. Since the board I use is single-core and I prefer not to use the external debugger, is there another way to notify the CPU without halting it when the MTB buffer is full?
  2. Based on the first question, I had several trials:
    1. I configured the DWT comparator to monitor the data address write, but it seems DWT cannot monitor hardware writing like what MTB does.
    2. I configured Non-secure MPU to set the MTB buffer region as RO, but it still cannot trigger a secure fault. I checked the document ARM CoreSight MTB-M33 page A2-26: The MTB-M33 ensures that trace write accesses have priority over AHB accesses. Is that the reason why the MPU can not constrain MTB writing?
    3. I also configured SAU to set the MTB buffer as secure, it still cannot trigger the secure fault when non-secure trace writing happens.
    4. Then I go back to the MTB document, it actually has the MTB_SECURE register that can partition the MTB buffer as secure or non-secure. But I don't know is that because the board or the image I use does not fully implement the MTB, I cannot modify the MTB_SECURE register except for the last two bits.
So at last, is there another way to notify the CPU without halting it when the MTB buffer is full? Like what Intel Processor Trace does.
I hope I describe the question clearly and I very appreciate if someone could give me any suggestion. Thank you so much! (edited) 
  • +1

    1. You can setup the Core to issue an exception when it enters debug mode. It should be vector 12.

    2.1/2.2: The MPU checks core bus accesses. Not DMA and not MTB.

  • 0 in reply to 42Bastian Schick

    Thank you for your reply! Now I have a better understanding of the MPU.

    For bullet 1, I checked that vector12 is the Debug Monitor Handler. I enabled it in 2.1 to handle the DWT match.

    But what the MTB watermark triggers is the Debug State. As Armv8-M architecture reference manual B11.4 Debug event behavior section describes, the Debug state is different from the DebugMonitor exception. The Debug state will halt the processor and only exits when the debugger clears the HALT bit or receives an external restart request, or on a warm reset.

    Some operations can trigger both debug halt and debug monitor exception, such as the breakpoint, watchpoint.

    I did not find any document explains that MTB WATERMARK can trigger the DebugMonitor exception. So I tried to set both the MTB WATERMARK and the DebugMonitor handler. And still cannot solve my question.

    We cannot handle the debug state via the single-core, right?

    Did I misunderstand the document or have the wrong tests?

    Thank you again.

  • +1 in reply to 42Bastian Schick

    I think I found the solution! The MTB WATERMARK will trigger an External debug request, which can be monitored by the DebugMonitor exception! Thank you so much!