Hello,
we are using a JTrace PRO + Ozone 3.28, with a custom STM32H730IB board.
We are using a the 4-pins trace interface, with a low CPU frequency so that the trace can be working without issues (TRACECLK is 30MHz or so).
We also use the provided .pex file (ST_STM32H743_Traceconfig.pex) and load it in the Ozone project.
The problem is that the trace is only working before hitting the first breakpoint. We have the following behavior:
- if "Reset & Run" mode is used, the trace not working (we have the orange LED on the JTrace but the instruction trace stays empty)
- if "'Reset & Break at symbol" (main()) is used, the trace is working only before the main() breakpoint is hit. Then, when we click Continue, the Instruction trace counter stays at the same value and we don't get any more trace after that.
However, in both cases, the Trace packets counter is increasing in the JTrace control panel, so the trace packets are actually sent by the target and received by the JTrace adapter, but somehow not parsed / read by Ozone.
It is not linked to a clock configuration issue on the MCU side - we ended up by removing all the clock configuration from our code and the behavior stays exactly the same.
We can share the .elf file and Ozone project but obviously not publicly.
Thanks,
Florent
we are using a JTrace PRO + Ozone 3.28, with a custom STM32H730IB board.
We are using a the 4-pins trace interface, with a low CPU frequency so that the trace can be working without issues (TRACECLK is 30MHz or so).
We also use the provided .pex file (ST_STM32H743_Traceconfig.pex) and load it in the Ozone project.
The problem is that the trace is only working before hitting the first breakpoint. We have the following behavior:
- if "Reset & Run" mode is used, the trace not working (we have the orange LED on the JTrace but the instruction trace stays empty)
- if "'Reset & Break at symbol" (main()) is used, the trace is working only before the main() breakpoint is hit. Then, when we click Continue, the Instruction trace counter stays at the same value and we don't get any more trace after that.
However, in both cases, the Trace packets counter is increasing in the JTrace control panel, so the trace packets are actually sent by the target and received by the JTrace adapter, but somehow not parsed / read by Ozone.
It is not linked to a clock configuration issue on the MCU side - we ended up by removing all the clock configuration from our code and the behavior stays exactly the same.
We can share the .elf file and Ozone project but obviously not publicly.
Thanks,
Florent