Posts by fraengers

    https://forum.segger.com/index.php/Thre…-is-set-to-Max/

    XMC4500 Relax Kit

    I made similar observations (win10, ozone 3.36, j-link ultra+ v5.1). quick example:
    I have these variables:

    I want to sample D7.dbga[1-3] or dbgb[1-3] or dbgc[1-3]
    All variables are in the same memory (DTCM of a STM32H745 in this case)
    Sampling with max frequency results in requests send every ~20us on the SWD lines running at 25MHz.

    observations:

    sampling D7.dbga[1-3]
    =>GUI very laggy, many sample points missing


    sampling dbgb[1-3]
    =>GUI laggy, some sample points missing

    (but one time this also ran smoothly)


    sampling dbgc[1-3]
    => ok


    sampling <artificial>::dbgb[1-3] (result of "graph" in context menu of GlobalData pane)
    =>GUI very laggy, many sample points missing


    sampling (<artificial>::D7).dbga[1-3] (result of "graph" in context menu of GlobalData pane)
    =>GUI very very laggy, many sample points missing


    sampling addresses directly
    =>GUI very laggy, many sample points missing


    btw.: changing the variables that are being sampled, while sampling on max, often results in breaking the sampling all together and I have to powercycle the probe and restart ozone.

    It says 1us@200MHz per event. For an ISR with 100 kHz, that means 20% of CPU load is only for SystemView events, that may be too much.


    Reproduce 1:

    • Start debug session with J-Link Edu
    • Enable power sampling (if not already enabled)
    • (there is no info that power sampling is not usable. there only may be a warning if the sampling frequency is set to anything >1kHz)
    • halt target
    • the X-axis (not Y, sorry, typo) cannot be moved to the right (manually by dragging or mouse wheel up, or automatically when zooming in on something on the left side of the plot)
      also the time cursor cannot be reset to somewhere else, it will always be at the right end of the plot
      it has nothing to do with trace, it happens also with tracing off
    • set power sampling to off, now it works normally

    Reproduce 2:

    • (I cannot reproduce on my work-PC right now)
    • Start debug session with J-Link Edu
    • Enable power sampling (if not already enabled)
    • Disconnect J-Link USB cable (or some other reason USB connection ist lost, e.g. a disturbance)

    Too bad.
    SystemView may be too much overhead.

    Playing around with tracebuffer and a J-Link Edu V11 I noticed two things. Both happen when power sampling is enabled.

    If you choose to not support power sampling for J-Link Edu/Base/Plus, please at least make in a way it is not disturbing normal operation (or just allow it with a limited sampling rate)

    And yes, I know (now) if I set sampling to “off”, it “solves” this problem. But since I didn't turn it on, or even use the power pane, this was not the first thing that came to mind.


    1. I cannot zoom into the code timeline, y-axis x-axis keeps getting reset

    2. if the connection is lost, waring messages pop up as long as the session is not stopped.

    I was not asking about the visuals in Ozone. But since you mentioned it, I don't think the round corners are a good idea and make it more difficult to read.


    I was wondering if only interrupt entries and exits can be viewed. To reduce data so a longer period of time can be displayed. I don't care what functions a called inside the interrupts or in the main loop. I'm more interested in the timing of the ISRs (when, how long, priority handling). With other debuggers I saw options like exception trace. Right now, I do it with IOs and a logic analyser. I was hoping to do something similar with the debugger, so I can also correlate it with sampled data.


    There is this ITM thing, where I can write to, e.g. to mark the start and end of an ISR, could this be displayed somehow?


    I am just wondering what a J-Trace can do for me, that I maybe don't know of, since tracing is new to me. More than a J-Link can do and besides tracing every single instruction, which is not so important for me.

    I there any way I can use Ozone or a J-Link/Trace to visualize interrupt entrys and exits (I don't have a RTOS)? Live or afterwards (if I can record for a few minutes).

    Or is there anything at all, that a J-Trace can do, to get me more live informations. (Besides profiling)

    Hello,

    I'm curently testing J-Trace with Ozone. As I already found out, there is only a limited amount of traced data visible in the timeline. And while the MCU is running, no data is visible at all.

    Can (a limited amount of) data be shown while the MCU is running?

    This is my use case: I want to record and analyse / display in the timeline, what my code is doing for a longer period of time, e.g. a few minutes. I cannot halt the MCU during this time. Is this possible at all?

    Hello,


    I have a few questions regarding the debugging of a STM32H745 dual core controller.


    1. Is simultaneous debugging of both cores fully supported/possible?

    It works, more or less, but I noticed some problems:

    e.g. sampling a variable for the timeline data graph with one Ozone instance connected to CM7, while another Ozone instance is connected to CM4, will result in zeros in the graph, and even worse, it will zero the sampled variable in memory.
    In the image you can see how "dwtval_avg" (on-chip calculated average of dwtval) gets reset


    I also had cases, where the debugger (J-link Ultra+ V5.1), lost its firmware while trying to start a debug session and needed to reload it.


    2. what does Ozone do when I click “Download & Reset Program” and why could it fail?
    e.g. right now, I cannot access the CM4, while CM7 works fine
    From console:

    2a. Does it reset/halt both cores or just one?

    2b. Does it write something to RAM? Because the error above mentions RAMCode

    2c. What could prevent the debugger from debugging? The core must be on, I guess, anything else?
    2d. What is the "T-bit of XPSR" and what does this warning/info mean?

    Hi,
    some issues with the GUI:


    1. copying data from memory window may not work correctly:
    reproduce:
    a. right click on a variable => show data (Ctrl + T), memory in memory window is selected in gray
    b. right click into gray area in memory window, gray selection turns blue (i.e. selected), context menu opens

    • x Copy (Ctrl + C) does not copy the selected data, but the first line of memory (i.e. 16B from 0x00000000)
    • x Copy Special => Copy Hex does the same
    • x Copy Special => Copy Text does the same, but with text
    • o Copy Special => Copy Hex as C initializer works
    • x Copy Special => Copy Binary does copy nothing (at least nothing I can see / paste into a text editor)

    2. Scroll bar of memory window is flawed:

    • The thumb size does not visually represent the length of the list it is scrolling, i.e. it is too big.
    • Dragging the thumb moves the content only every 4 pixel, leading to a very big step of about 2.68 million lines. I get that the list is very long (268 million lines) and moving to an exact memory position with this does not make much sense, but it could at least make the best use of it, i.e. move the content with every pixel.
    • Most important issue: Clicking above/below the thumb (= page up/down) does work and is a good way to scroll a bit further up and down than with the mouse wheel, but while doing so, the thumb jumps around weirdly and may end up under the cursor. The result: the next click will probably move the list by millions of lines.

    3. First character of a line in the console cannot be selected (besides by selecting the whole line by clicking on it)


    4. Window arrangement
    The windows can be arranged inside the main window, but there are two configurations. One for: if the main window is maximized, and one for: when it is not. Since I use Ozone with both, I need to (re)arrange the windows always two times. If this is supposed to be a feature, please make it disableable.


    5. Window arrangement
    Some window arrangements are not loaded correctly. More specific, after opening Ozone they will get loaded correctly, but after 1 second they get rearranged. Example attached.

    New Project Wizard => STM32H743VI => use attached elf file => apply suggested freertos plugin addition
    Console shows CM4 plugin was loaded.


    While you have already loaded the elf file, please observe the global variables view having a problem with structs/unions and bitfields and add it to your list, if this is not already there. (see image attached)

    PS: This board has problems too: timeouts, unknown errors with the file upload. Also I posted this answer already yesterday, but apparently it was not saved. Probably because an error message appeared on the bottom, out of screen, unnoticed, telling me that this post is too long. Which it wasn’t, but a pasted image gets counted with 1 char per pixel or something, so I hit the 10000 char limit …

    I want to suggest a more clear naming of the stack info column of the freeRTOS plugin or a change of the shown data, to avoid misconception.

    Right now it shows free stack / total stack, as I found out after too long of time. I expected it to show used space / total space.

    Personally I would prefer it to show stack usage instead of free space. At least it should have a properly named title.


    On a side note, a minor bug: While creating a new CM7 project (I didn’t test, if this is processor specific), the suggestion to add the freeRTOS plugin, adds the CM4 version.

    Project.SetDevice ("STM32H743VI");

    Project.SetOSPlugin ("FreeRTOSPlugin_CM4");

    ...I missed the logic of the default STM32Cube code. M7 will timeout until I am able to start the second debug session and M4 will end up in stop-mode.
    After fixing that, now both cores are running, but halting the CPU on either Ozone instance will only stop the M4, the M7 keeps running.

    How can I halt the M7 or both at once?

    Hello,

    I am trying to debug a dual core STM32H745 with Ozone V3.30d.
    While I can flash and step thought the code on the M7, it does not work on the M4. Flashing works, but I cannot debug.
    Console output after clicking Resume:

    Code
    T-bit of XPSR is 0 but should be 1. Changed to 1.

    Subsequent Resumes result in the same message.

    Is this essentially possible with Ozone?
    What am I missing?

    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.

    Code
    var SetOfAddressesToSample = GetAddressesToSample();
    if (SetOfAddressesToSample == SetOfAddressesBeingSampled) RecalcualteExpressions();
    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.

    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.

    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.

    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.

    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)

    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.

    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.