[ABANDONED] Feature wishlist and possible improvements 3

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

  • [ABANDONED] Feature wishlist and possible improvements 3

    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

    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.
  • 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.
  • 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 ().

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


    SEGGER - AlexD wrote:

    19. (...) For the time being I recommend not changing the sampling frequency during recording. The benefit of doing so is questionable anyway.
    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.
  • As stated before: The wrong calculation of float expressions will be fixed in a subsequent release.

    As stated before: We will not add aliases for the legend since Ozone is designed to display what is there.

    As stated before: Y-axis zoom is on the list of future improvements. If I get it right this will solve quite a few of the things you observe with Y-Axis ranging.

    What's wrong with Y-Axis adapting to values growing into the negative? This is intended.

    Same goes for the connection between data sampling window and timeline window: This is intended, as you can see in the Ozone user's manual, section 4.6.7. Since you can read the value in the data sampling window there is no need for a value box. As you can see in section 4.22.6 of the Ozone user's manual, the value boxes are connected to the hover cursor, and this is not in place in the scenario you describe.

    We are not aware of power sampling at high frequencies slowing down Ozone, as you describe. Please provide a reproducer on an evaluation board (Ozone project, ELF file, Board details) and describe how to reproduce the issue.

    I am sorry that our requirements do not always fully meet your expectations. Of course it is up to you if you apply the work-arounds we offer.

    Though we are always grateful for customer feedback, please understand that we may come to the conclusion that a feature proposed by a customer shall not be implemented, e.g. because we do not find it useful at all, or the benefit is limited to a too small part of the audience of Ozone users.
    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.
  • SEGGER - AlexD wrote:

    What's wrong with Y-Axis adapting to values growing into the negative? This is intended.
    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.

    SEGGER - AlexD wrote:

    Same goes for the connection between data sampling window and timeline window: This is intended, as you can see in the Ozone user's manual, section 4.6.7. Since you can read the value in the data sampling window there is no need for a value box. As you can see in section 4.22.6 of the Ozone user's manual, the value boxes are connected to the hover cursor, and this is not in place in the scenario you describe.
    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.

    SEGGER - AlexD wrote:

    We are not aware of power sampling at high frequencies slowing down Ozone, as you describe. Please provide a reproducer on an evaluation board (Ozone project, ELF file, Board details) and describe how to reproduce the issue.
    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.
  • If I get you right, the growing into the negative range is reproducible on your desk. Could you please provide a reproducer project on an eval board for that? We'd require the ELF file, the Ozone project and whatever else is required to run the reproducer plus a step-by-step instruction on how to reproduce the behavior. You may open a support ticket for providing the reproducer. The link for opening a ticket can be found below.

    22. If you modify an expression at runtime Ozone needs to dump the data already sampled anyway because the data sampled for the previous expression does not fit to the new expression. There is a technical limitation which does not allow Ozone to change parts of the addresses sampled during data sampling - only the whole set of addresses can be changed. Since adding a new expression may change the addresses to be sampled the whole data needs be reset, the new set of addresses is calculated and sampling started anew.
    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.
  • SEGGER - AlexD wrote:

    22. If you modify an expression at runtime Ozone needs to dump the data already sampled anyway because the data sampled for the previous expression does not fit to the new expression. There is a technical limitation which does not allow Ozone to change parts of the addresses sampled during data sampling - only the whole set of addresses can be changed. Since adding a new expression may change the addresses to be sampled the whole data needs be reset, the new set of addresses is calculated and sampling started anew.
    I'm not talking about changing what is sampled, but about the calculations that are done with that data.

    Source Code

    1. var SetOfAddressesToSample = GetAddressesToSample();
    2. if (SetOfAddressesToSample == SetOfAddressesBeingSampled) RecalcualteExpressions();
    3. else RestartSamplingWithNewAddresses(SetOfAddressesToSample);
    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.
  • Hi Fraengers,

    22: This is not a feature we assume as being widely requested in the community of our customers. Therefore we will not pursue this idea any further.

    Apparently you are in particular interested in quite a few non-mainstream features and feel aware on how they could be implemented. Therefore you may be interested in the J-Link SDK: This allows you to integrate J-Link into your own application. For a 1st impression please refer to this site: segger.com/products/debug-prob…nk/technology/j-link-sdk/. Of course, your own application can be written such that it runs in parallel with Ozone, sharing the same link to the target.

    Your application probably needs to access information from an ELF file. SEGGER also offers a library for that purpose: segger.com/products/development-tools/elflib/.


    In case you are interested, please contact our sales office.

    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.