See also:
forum.segger.com/index.php/Thr…nd-possible-improvements/
forum.segger.com/index.php/Thr…-possible-improvements-2/


1. again: why a start/stop button would be a good idea and add value (i.e. make the sampling feature usable):
Here is a gif, so you can see the problem (besides the big inconvenience that this procedure is); the timelines will be out of sync:
edit: the bigger issue here is that power and data timelines are not correctly synced.



=> But why don’t I just disable the auto scroll (aka the missing pause button)?

• First, because the result it is not stable
  
• Second, because if the buffer is full, the timelines will move
  

=> but what if I just increase the buffer size

• this only delays the problem
  
• buffer is always allocated in RAM. So as long as Ozone is open, it will occupy RAM, even when not debugging or sampling.
  

2./11. another example of the zoom problem. I still cannot tell you how to reproduce it. maybe use ozone longer than just for a quick test?





And more: Data and Power, or the time grid, may not be in sync after starting a session with sampling on
edit: I think the problem here, maybe also in other cases, is the scrollbar on the timeline. when it's present, the grids won't line up anymore.
Also notice how the timeline is not starting at 0s, but with the time of the first datapoint of the last run



And another issue:
changing the sampling rate, makes data and power async and the old power samples are lost. after a while it kind of gets back into sync, but the noise changes.
edit: the change in noise is the change of the sampling rate, that just happens at some point seconds after I change the frequency settings in GUI.



2. I already mentioned this in the first thread: sometimes while using the timeline, typically with sampling frequency set to max, Ozone gets really laggy, not only the timeline as shown in the gif, but everything in Ozone. Here is an example:
Furthermore there may be gaps in the sampled data. After stop/halt Ozone will react normally again, but the power sampling waveform will rapidly add data.
With the other problem above (change of power sampling frequency while running) it seems to me, there is maybe a major buffering issue either in Ozone or with J-Link.
USB speed has a noticeableinfluence, because it is happening a lot more often with an USB isolator (Full Speed, i.e. 12MBd), but it also happened without



The timeline feature is nice and it's the main reason I bought an Ultra+ and the main reason I would recommend it to others, but not in this condition, obviously.
The more I'm trying to use it, the worse it gets. I cannot test the code timeline, but my expectations are low.
Maybe you should rename the window to something like: "Timeline (pre-alpha, use at own risk, results may vary)".


14. even the video about the timeline feature is not working (the other videos work)
see segger.com/products/development-tools/ozone-j-link-debugger/




15. power sampling frequency setting
The setting can be set to e.g. 100kHz on the dropdown control but no sampling is happening, because internally it is set to off.
Reproduce: have working session with power sampling on, stop session, create new project with wizzard, start new session, power sampling is still set to e.g. 100kHz, but it wont start until you set the frequency again.


16. stop/sleep mode of target locks J-Link
when I have a target and I put it in stop/sleep mode without leaving the debug module on, J-link locks up. No error message, I cannot stop the debug session, I have to power-cycle the probe.
And yes, I'm aware that without the debug module J-Link cannot sample data, but it shouldn't lock up either.


17. after all these bugs possible improvements, another one for the wish list:
with many variables the bubbles on the cursor position become hard to distinguish, even without the bad default colors. Maybe add letters in front of the entries in the legend and the bubbles, so they can be matched if needed. Even better, add a tag column in the sampling table (with a,b,c .. as default) so I can (re)name them myself.
Also a colored bar could improve the visibility of the color itself, because the one pixel wide border is a bit thin.



18. wish: power sampling independent of debug session
The power sampling should be able to run all the time. So I can see the current of the target without debugging. Useful e.g. when I go to a sleep mode with debug module off and want to see if and how the target wakes up again. Or if I want to look at the startup behaviour.
The "J-Link / J-Trace supplies power to the target" setting should be a checkbox next to the sampling frequency so I can turn on/off the target at any time without a debug session. Also a "issue reset" button would be handy, so I can observe what happens after a non-POR.
Since it is a feature of the debug probe, it should not depend on a running debug session with the target. The RAM for the buffer is already blocked all the time, so why not fill it with data all the time.


19. more thoughts on timeline behaviour
The timeline should (selectable) either run all the time (see 18 why) with real time timestamps or with time synced to target run time, so it stops when the target is halted. In both variants, if I stop or change the frequency of any of the sampling features, while the target keeps running, there should be a gap in the data and not that weird behaviour that is happing right now, where data gets deleted and time correlation is lost.


20. Setting "J-Link / J-Trace supplies power to the target" behaviour
this setting is not working as I would expect it to work. If I set it to "yes", it will supply power once the debug session starts if it was off before. But after I stop the session it will stay on. If I then set the setting to "no", nothing changes until I power-cycle the probe; only then power is turned off. This is an issue if the behaviour of my target board depends on the POR.
Suggestion: make a checkbox as mentioned in 18 for any time user controlled power independent of debug session and another one that sais "supply power only while debugging" that turns on power only for the duration of the debug session. If power is already on, add a customizable time where it gets turned off before the start of the debug session, so everything can get a POR, or not if time=0.


21. wish (maybe a bit out of scope but just let me dream a bit about a more universal debug tool)
use unused pins on the debug probe and sample them as logic data that will endup in the timeline

2. I already mentioned this 6 month ago. Y-axis behaviour is terrible. I'm not talking about the missing y-axis zoom (e.g. with alt + mouse wheel) but that the scale breaks.
Sometimes wrong i.e. very big or very small numbers may appear, probably due to EMI. What should normally only result in spikes, results in unuseability:
Y-axis shows a strange scale, auto scale doesn't work, but even a manual y-axis range can't be set. Please fix your timeline.

19. changing the sampling frequency with power sampling is sometimes useful to reduce the noise
2. to reproduce just try sampling the values from the image, e.g.: (tested with XMC4500, if relevant)
Fit height will result in a scale with numbers ending in 'P' like in the image. I just realized that means peta, so this it probably working.
edit: no, only partially, see the following example:

So fit height works for the grid and waveforms, but the scale is broken when big numbers are involved.

edit2: no, not even fit height works. e.g: here, "visible" values should be around 0



Manually setting the y-range will not work. e.g. -10..10 will result in 0..20. so will 10..30. Moving the grid along the y-axis with the mouse is also not possible then.

A few comments on the UI:
+ thumbs up for optional names at cursor, thicker boarder and better default colors.
- long expressions are problematic, because the color boxes may end up far away from the shorter names. I suggest moving them to the right next to the checkboxes or something like that. And/or allow me to choose my own names. In this example "Vbat" would be a much better, and shorter(!), description for what I want to plot, instead of the long expression. Would keep the legend smaller too.
- value boxes may overlap time marker and since the grid is not moveable by mouse in y-direction beyond min/max values, i cannot manually circumvent this by moving the waveforms down, like in the middle of the timeline window, so that the boxes won't overlap.


While I appreciate the graphical improvements, I would rather see a fix of y-axis range and time-axis zoom behaviour, because these problems really make everyday usage very annoying if not impossible.

Is this also the solution for the still not working watched data expressions? Just calculate it on the target ?!
This is exactly what I don’t want or can’t do, because it costs time. My time to code and flash it every time I want to change the calculation and the time for the calculation itself needed on the target, which I possibly don’t have, e.g. on a small Cortex M0 w/o FPU. That is what I have a capable debugger for, or at least that is what I thought.

Reminder for problems with watched data:



With Auto Fit Height I often don't have enough margin, as you can clearly see in last posts picture, that's why I'm mentioning it.

y-axis zoom would be a great new feature, yes. setting the range by typing in numbers is really tedious.

Same goes for unrestricted y-axis movement. (why limit it in the first place?) this would also solve the overlap inconvenience.

with "y-axis range" I mean what I wrote in post 4, and this is a real problem, because it makes the whole recorded data unusable.

what is wrong with time-axis zoom is what you see in the third GIF in post 1.

Found another problem:
y-axis will move down with the min value.



An another:
time-axis (relative to data) will move when scrolling the samples list. While this may be a “feature”, it is very irritating. Just start the time-axis at 0 when I start debugging and leave it at that.
Maybe add a right click menu entry “set origin here”, so users can change the origin if they really want to. But don’t change it just because I scroll down the list.
If you want to show the point selected* in the list in the plot (this is of cause a great feature), do it in the same way as if I would move my mouse in the timeline. The benefit of that would be that I can also see the value boxes.
(*I didn't even select anything)


If the sampling would work smoothly I wouldn't need to change the sampling frequency and let it run on max or 10kHz all the time. But this doesn't always work, as mentioned before. Often Ozone then gets really laggy, so I only set the sampling frequency to a high value when needed and only for a short period of time. This is of cause an unpleasant experience because Ozone is unresponsive, but the only way to achieve the highest possible sampling rate.

Then I don't understand your intentions. Why adapt it with negative growing values but not with positive growing values? Don't change it at all, unless I enable Auto Fit Height or something.

I don't see the full benefit of this approach, but maybe there is one. So let me word it as wishes:

• add second time scale, that displays the time relative to the start of debugging or add option to choose how the time scale works (=relative to cursor / start of debugging / reset of sampling)
  

• do not auto select a value from the list, only select when I click on a row, so I can scroll the list without the time scale moving.
  

• use debug-time, i.e. the time since start of debugging, as the time stamp for all sampling.
  right now the time-scale is not synced to the data, as it is just relative to the sampling cursor, which isn't fixed. And the time stamp of a sampling point is just relative to the first list entry. So if the list gets reset, which will happen when I add or remove a variable, or the buffer is full, I loose time information. It would be much more useful to have everything in reference to the start of the debug session, with the option for setting a custom time origin of cause.
  

It is not the power sampling (I think, I don't use it much), but the variable sampling. I'll send you something if I have something, but it is not so easy to reproduce on a demo board with only a small programm running.

Just so you are aware of the problems I encounter, here are two more examples: (Not easy to reproduce, but will happen from time to time)

• I added a new variable to sample during a running session. time stamps are strange now, values too.
  
  

• Another example would be that sampling will sometimes stop after adding a new variable.
  

Finally, another wish:
22. don't reset the sampling when I change an expression, just recalculate (unless the sampled variables change)
e.g. when I have two variables, one that goes from 0..1 and one from 0..1000, which I only realize after they got sampled. Then I may want to add "/1000" in order to scale the waveform, so I can see the small values as well. But that needlessly resets the sampling and removes the data.

13. expressions again (in watched data):
broken operators:


expressions are not saved/loaded properly. after I close and reopen ozone, it looks like this:

I'm not talking about changing what is sampled, but about the calculations that are done with that data.

I imagine it like this: You store the data of the sampled addresses in arrays/lists, one for each address, and the calculated results in additional arrays/lists, one for each expression. and then you can simply recalculate the expressions if they change, as long as the addresses being sampled don't change.