[SOLVED] Multicore Debugging with multiple instance and Cross Trigger Interfaces

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] Multicore Debugging with multiple instance and Cross Trigger Interfaces

    Hi,

    I am fairly new to JTag Debugging and for our companies project, we are currently using it to debug one of our systems.

    In this regard, the system uses an IMX6Q7 CPU (Cortex A9) with 4 cores running baremetal. The scenario is to attach to a running system (with a JLink Ultra+) not to interrupt the system as a whole.

    So far, I was successful in attaching with Ozone to different cores by using a JLinkScript file setting the CORESIGHT_CoreBaseAddr variable in the InitTarget() function, if I want to debug anything but core #0.

    However this works only with one core and while I can open multiple Ozones and even attach to the various cores (3 work simultaneously so far), they all halt independently.

    I know that there is no native support for setting up Coresight ECT/CTM/CTI, however I do have the addresses of the for Cross Trigger Interfaces (CTI) the CPU is providing. According to the manual, the interfaces allow the configuration of the matrix (CTM) to halt and restart Cores simultaniously on trigger events (somehow).

    The internet is rather empty when it comes to a description how this is exactly set up. I do know that the Interfaces need to be unlocked with an ACCESS word, which can be found on the website of ARM or in a Linux Kernel reference. However beyond that I don't know anything. It would be good to know if anybody has knowledge or experience to clear up the questions about...
    • ...what and which registers I need to write to of each CTI to achieve my goal or connecting trigger events
    • ...how trigger events map to something like a breakpoint in Ozone (or are they just the same)
    • ...how to put this into the JScriptFile, since I have no clue which function to use to write those values
    It's a long shot to ask in the forum, but I thought I'd try.

    Thanks to anyone who can help.
  • Hi Andreas,

    Thank you for your inquiry.
    Yes CTI and multi core stuff is usually not well documented anywhere and the only reference that provides reliable information is the generic manual by Arm.
    Unfortunately at the current point in time J-Link does not offer support for CTI, so it would not be possible to use it, even if your manage to configure them via a JLinkScript.

    The reason for this is that when the debugger issues a halt on such a CTI enabled system, you would expect that the CTI handles the halt. However as for J-Link there is currently no logic implemented, it will issue a normal debug interface halt, which ignores CTI settings and only the core you are connected to is halted.

    But we already have general CTI support for J-Link and Ozone on our roadmap and it is currently planned to be available by the end of the year.
    There will most likely be a Wiki article explaining how to use, configure and interface things with J-Link and a sample setup for a chip/board.

    Then it should definitely be possible to set something like this up.

    Best regards,
    Nino
    Please read the forum rules before posting: Forum Rules

    Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi Nino,

    thanks for your answer. I have already searched the forum and it seems like the CTI feature has been postponed quite a few times from 2019 to end of 2020 to now end of 2021. It being essential for every day debugging, I don't see how such a feature can simply be missing in the catalogue.

    It seems like you have quite some knowledge regarding this feature and also the resources. As far as I can tell, if I could set it up, I could even trigger it. While you say that Ozone doesn't have the capabilities to do so, software running in privileged mode directly on the CPU can.

    To be specific, I am trying to catch an error that happens on one core and lasts for about 30ms. Detecting this state, I could trigger a halt from another core. I was hoping to use a global variable seen from both CPUs as a watchpoint, however since the core in question doesn't access the variable (and is possibly in an unknown state), triggering via breakpoints/watchpoints or IRQs is out of the question. What remains is - to date - ECT/CTI/CTM.

    If you could give me some general examples how CTM/CTI is configured and how such a trigger is done for CTI, I'd be grateful.

    Otherwise debugging such a case is just for the big league debuggers instead. Or even OpenOCD, which seems to have some knowledge about the topic (no idea how to configure it through).

    Have a great day.
  • Hello Andreas,

    Not sure where you get the impression from that we have currently resources free to implement CTI support.
    Our schedule is quite packed at the moment with paid projects so we have to prioritize and manage our resources accordingly.
    While CTI is an important feature for multi core debugging it makes up only ~0.1% of our customer base. So demand is extremely low compared to other features the majority of our customer requires for day to day business.

    As said adding CTI support is on our todo, but due to the low demand and no sponsors for the implementation we can't name a fixed time schedule. Right now it is planned to be available by the end of this year. But that plan can also change so it might also be later than that.

    Should you or your customers be willing to to co-finance/sponsor the development of this feature so we can prioritize it higher, feel free to drop us an inquiry via our support channel in my signature for a quote.

    In terms of CTI examples we currently do not have any implementation samples that we could share. For reference we recommend to use the Arm Coresight manual and the iMX6 reference manual.
    Other documentation is not known or available to us as well.
    It might be also worth to try contacting NXP support for your "on CPU approach" as they might have code snippets or similar available that could be used for reference.

    Best regards,
    Nino
    Please read the forum rules before posting: Forum Rules

    Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.