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):
But of course that has no effect
Any help?
thanks
Dan
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):
But of course that has no effect
Any help?
thanks
Dan