[SOLVED] High frequency interrupts accuracy and overhead

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

  • [SOLVED] High frequency interrupts accuracy and overhead

    Hi all,

    I am using Systemview on a NoOS STM32L4 @80MHz, jlink arm pro, win10, atollic IDE.
    I have followed the "How to instrument a NoOS application with SystemView" wiki to setup my system.

    I would have liked to measure the ADC-DMA that is interrupting every 18us, with the ISR lasting about 0.5us.
    I have measured above numbers using the mcu pin toggling.

    Is this feasible or would you not recommend using Sysview for such high frequency interrupts.
    If so, what overheads can I expect? Is there a published table with some info to guide me on this?

    Thanks
    Alex

    The post was edited 1 time, last by almost_linear: syntax, grammar. ().

  • Hello,

    Thank you for your inquiry.
    SystemView uses RTT for I/O so to get an idea about what overhead to expect you can check out our RTT page:
    segger.com/products/debug-prob…about-real-time-transfer/

    The typical overhead is ~1 µs per event for a CPU running at 168 MHz.
    We created an optimized assembler version of the RTT_Write function which in theory reduces the overhead to 1/4. But we did not conduct any measurements yet with that. The assembler version should also be part of the latest RTT Souces.

    Should you look into non intrusive trace techniques our J-Trace PRO can be used:
    segger.com/products/debug-probes/j-trace/

    Together with our free debug software Ozone and its timeline feature you can simply display the application progress graphically with cycle accuracy!

    segger.com/products/developmen…echnology/trace-features/


    Most STM32L4 support this trace technique and we also have some sample projects ready that work out of the box:

    segger.com/products/debug-prob…echnology/tested-devices/


    Best regards,

    Nino
    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.

  • Thanks for your quick reply Nino.

    I changed the RTT compilation to include the ASM RTT_Write() routines.

    Unfortunately Sysview does not seem to be measuring the correct length of the ADC-DMA, being a factor of 6 or so out.
    Should be measuring 0.5ms but currently measuring 3ms.
    However, the period between interrupts ADC-DMA is measured correctly at 18.125ms.

    Would the post mortem mode be more effective in my case?
    Can I somehow sacrifice real time behavior for a short measurement window and finer accuracy or better resolution?

    The jtrace looks interesting but I just exchanged my old jlink pro for a new one.
    Not sure if we have the budget for one of them right now.

    Thanks
    Alex

  • Hello Alex,

    Are your measurements ms or µs now? I am a bit confused by the different numbers from your initial post.

    almost_linear wrote:

    Would the post mortem mode be more effective in my case?
    It will still have the same overhead as using SystemView live.

    almost_linear wrote:

    Can I somehow sacrifice real time behavior for a short measurement window and finer accuracy or better resolution?
    The ASM versions is already the shortest that is technically possible. If you are looking for tracing without impacting real time behaviour at all only pin tracing via the Arm trace port is viable e.g. with J-Trace PRO.

    Best regards,
    Nino
    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.

  • Hi Nino,

    Thanks for your reply.

    I am measuring micro seconds. I made a mistake with the time unit in the last post.
    All time units should have been us not ms.

    Unfortunately Sysview does not seem to be measuring the correct length of the ADC-DMA, being a factor of 6 or so out.
    Should be measuring 0.5us but currently measuring 3us.
    However, the period between interrupts ADC-DMA is measured correctly at 18.125us.

    I am not so much worried about the overhead, as I am about the accuracy of the measurements.
    The ADC-DMA code i mention above that was instrumented with Sysview has a duty cycle of about 75% (25% used, 75% free), and sysview wont be used in production code.
    As I mentioned in the last post, I am seeing a large discrepancy in actual vs sysview measured code execution time.

    Currently using ASM version of RTT_write() but still seeing this discrepancy.

    Looking for some guidance on how to troubleshoot this.
    Do I need to populate the SEGGER_SYSVIEW_X_GetTimestamp() function instead of using the DWT (0xE0001004) cycle counter on its own?

    Thanks
    Alex

  • Hi Alex,

    almost_linear wrote:

    Do I need to populate the SEGGER_SYSVIEW_X_GetTimestamp() function instead of using the DWT (0xE0001004) cycle counter on its own?
    This is optional. The cycle counter is usually accurate enough.

    If I understand correctly you worry about the measurement of 3 us instead of 0.5 us.
    This is expected. As written on our website the overhead for a RTT write is ~1us. When entering and exiting an ISR you have two write commands. Now put in the mix that some more data are transferred than in the website sample and you get ~3 us.

    Faster than this is unfortunately technically not possible.

    Best regards,
    Nino
    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.