[Solved] Ozone is assigning TRACE pins when resuming from breakpoints

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

  • [Solved] Ozone is assigning TRACE pins when resuming from breakpoints

    I'm using the J-Trace for Cortex-M with Ozone on Mac OSX, debugging an STM32F427 over SWD. This setup has worked well for me for many months (when the software was called J-Link Debugger, as well).

    However I decided to enable SWO in Ozone, which is causing problems and now I can't get Ozone to disable SWO. The issue is that the TRACECK pin (PE2) is tied to a critical component in my hardware design. It seems that once SWO has been enabled on a J-TRACE unit, Ozone enables the TRACECK pin when it hits or resumes from a breakpoint even if SWO is subsequently disabled.

    As outlined in ST's reference manual for the STM32F4xx
    a debugger host can set the TRACE_IOEN and TRACE_MODE bits in theMCU Debug component configuration register (DBGMCU_CR)to enable Synchronous mode. When I use the Memory view to view address 0xE0042004 (DBGMCU_CR), it does indeed change from 0x00000000 to 0x000000E0 when I resume from a breakpoint. At point pin PE2 (TRACECK) starts outputting a digital stream. 0x000000E0 corresponds to the TRACE_MODE and TRACE_IOEN bits.

    That seems OK if I were to want to use the extended TRACE pins, but the problem is that even when I turn SWO off in Ozone using:
    Edit.SysVar (VAR_SWO_ENABLED, 0);

    Ozone continues to set the DBGMCU_CR when resuming from a breakpoint. I've tried changing all the system variables (SWO clock speed, RTT, etc), and none of them make a difference.

    There is an SWO mode which I'd like to use that uses just one extra pin (TRACESWO, or PB3). This is Asynchronous mode. It seems that Ozone is forcing use of Synchronous mode once SWO has been enabled.

    To be clear: Prior to enabling SWO in Ozone, I was able to debug and use breakpoints without any errors. It was only after I enabled SWO in Ozone that Ozone began setting DBGMCU_CR to 0x000000E0. Disabling SWO doesn't reset Ozone to the previous behavior and I cannot find a way to make Ozone go back to how it was working before!

    Creating a new project, uninstalling/reinstalling Ozone and J-link software, and even using a complete clean hardware board has no effect. The J-TRACE and Ozone continue to set the TRACECK pin to its alternative function even if I never enabled SWO in my code or in the install of Ozone.

    I can debug just fine in the GNU ARM plugin for Eclipse, but I prefer Ozone's real-time display of variables.

    I've added this to my code when it starts (hoping Ozone might "detect" this and stop enabling Synchronous mode):

    C Source Code

    1. *((volatile int *)(0xE0042004)) = 0x00000000;


    But of course that has no effect


    Any help?


    thanks
    Dan
  • Hello Dan,

    Might it be possible that the Instruction Trace Window or the Code Profile Window is opened?
    These windows activate trace, which will indeed set the TRACE_MODE and TRACE_IOEN bits and configure the pins.

    When activating SWO Ozone will print ">> Output via SWO active" in the Terminal, otherwise SWO is not enabled.
    Anyhow, SWO would only set the trace pin config to asynchronous mode.

    SWO and Trace will also not work in parallel.

    Best regards
    Johannes
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    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.
  • Ah yes, closing the Code Profile window prevents Ozone from initiating Trace when it resumes from a breakpoint.
    Thank you, it's working well now.
    And I appreciate the distinction between Trade and SWO modes.

    Cheers,
    Dan