Ozone Power Graph does not stop with code execution

AndersHedberg · Mar 21st 2024, 7:50am

Hi, this is basicly the same problem that was seen and solved in [SOLVED] Ozone Power Graph - start/stop recording when debugging

I am using the Segger Trace Pro Cortex-M with the STM32H7 Segger demo board with the demo project for that board loaded into Ozone. When recording power at 200kHz, the power recording does not stop when hitting a breakpoint, it just continous until I set the sampling frequency to Off.
Latest software version of Ozone (downloaded 2024-march-20), and the latest software in the trace unit as it updated itself with the J-link commander. The board is powered through the smaller trace connector as in the description on the wiki.

This is the first time I try this so I might do something wrong, but would appreciate any help.

Maybe a related or unrelated issue is that I doesn't really see all trace data plotted in Power Graph, just maybe the latest 6-10 blink changes closest to the stop, until i hit paus or a breakpoint is set during runtime and hit. How long time should I expect the trace buffer to last with this setup with an 8Gb buffer setting? or is this the setting for the power recording buffer only?

Regards, Anders H.

SEGGER - AlexD · Mar 22nd 2024, 10:24am

Hi Andres H.,

we are not aware of such an issue with the power tracing. I just tried and failed in reproducing the described behavior with Ozone V3.32a on a SEGGER Cortex-M trace reference board V1.0. Power sampling stops as expected when reaching a break point or when manually halting target execution.

Could you please provide details? Does this happen all the time on your set-up or only sporadically? Which steps do you perform in order to reproduce the issue? Could you share the exact project you are using here (i.e. upload a ZIP file containing everything required to reproduce the issue)?

Could you please provide an Ozone-log and a J-Link log of a debug session where you reproduce the issue? Creating an Ozone log is documented in section 8 of the Ozone user's manual, details on how to create a J-Link log can be found here: wiki.segger.com/J-Link_DLL#Enable_J-Link_Log_File.

Is your 2nd question related to power tracing or is it related to instruction tracing? For instruction tracing, please note that the streaming trace data is stored in a circular buffer of ~64 Mbyte. Due to the protocol transferring the trace data from the target to the PC this buffer can accommodate ~16 million addresses up to ~100 million addresses, each address being the equivalent to one instruction you see in the instruction trace window. Having that buffer size configurable beyond that 64 MByte limit is on our internal wish-list but as of now I cannot comment on when this will be released.

Does that answer your question?

Best regards
-- AlexD

AndersHedberg · Mar 28th 2024, 4:45pm

Thanks for the answer, I'll try to repoduce it later and upload it.

For my 2:en question - The J-Trace PRO Cortex-M is advertised as an limitless streaming trace (I mean instruction tracing), which I thought only was limited by writes to disk (or PC memory) if the USB/Ethernet speed is enough and the internal 64 Mbyte buffer was only for handling the burstiness of ETM trace data etc.? (here it's claimed to be possible to use terabytes of data, ) It seems that in this timeline view I do not get all streamed instructions, but only the last part of the stream, i.e I can not zoom out and move left and still see all the function call stacks.
I'll try to repeat this as well and document it.

SEGGER - AlexD · Apr 8th 2024, 2:02pm

Hi AndersHedberg,

the instruction trace that is displayed in the Ozone instruction trace window is limited to 64 MBytes of raw trace data. So even though terabytes of trace data reach the PC (and are evaluated e.g. for profiling purposes) only the last 64 MBytes of the trace data are displayed in the instruction trace window or the Timeline window.

Lifting that limitation is already on our internal wish-list for future improvements but at this point in time I cannot comment on when this will be released. We also found that setting a break point in the right spot and analyzing the instructions executed shortly beforehand does normally lead to the root cause way faster than browsing through an immense wad of trace data.

Does that answer your (2nd) question?

Best regards
-- AlexD

Share