Feature wishlist and possible improvements 3

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

    • Feature wishlist and possible improvements 3

      See also:

      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

      The post was edited 16 times, last by fraengers ().

    • 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.
    • New

      Hi Fraengers,

      thank you for your suggestions. Please understand that I will not comment on the topics that were already discussed in the other threads.

      14. Thank you for notifying us. This will be fixed.

      15. I was able to reproduce that. This will be fixed in a future release.

      16. When handling devices with low power mode enabled, special care must be taken. Please refer to this WIKI article: wiki.segger.com/UM08001_J-Link…Guide#Low_Power_Debugging

      17. This is already addressed and will be improved in a future release.

      18. Thanks for the suggestion. I will take that into the next internal discussion round.

      19. Timeline window displays data from 3 different sources and each source handles timestamps differently. I see that this in some corner cases, including changing the sampling frequency, leads to unexpected behavior which is already addressed and will be resolved in a future release. For the vast majority of use cases the current implementation works fine, though. For the time being I recommend not changing the sampling frequency during recording. The benefit of doing so is questionable anyway.

      20. See 18.

      21. See 18.

      2. Changing the Y-axis range via the respective entry in the context menu should work. However, Ozone should handle the occasional spike correctly - which would result in a huge Y-axis range having the effect that the actual signal is displayed as a flat line. Could you please provide a reproducer application on an eval board so we can reproduce the issue with the wrong scale being applied locally?

      One last note: Having just a single issue in a thread will help us in handling your issue more efficiently. You may experience shorter delays in our responses in such cases.

      Best regards
      -- AlexD
      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.
    • New

      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)

      Source Code

      1. float f1 = -6.47146376e18f;
      2. float f2 = 1.3124069e18f;
      3. float f3 = -1;
      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.

      The post was edited 3 times, last by fraengers ().

    • New

      Hi fraengers,

      please have a look at the latest release (V3.28e) which offers a few improvements in the area of the timeline window.

      Best regards
      -- AlexD
      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.
    • New

      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.
    • New

      We won't implement aliases for expressions. Ozone is intended to display what is there, and if there are long expressions they will be displayed. You may instrument your code to provide the content of a long expression in a short-named symbol, and then use that symbol in Ozone.

      Value boxes may overlap time markers, that is correct. With Auto Fit Height you usually have sufficient margin on the top for displaying the markers where no value box is displayed.

      I know that you'd love to see a Y-axis zoom feature. I assume with the "y-axis range" you refer to the fit height behavior you observe with the very big or very small values introduced by EMI in your setup. I'm not sure I fully understand what's wrong with time-axis zoom. Could you please elaborate on that?
      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.