This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SWO and variables reading

Note: This was originally posted on 27th February 2012 at http://forums.arm.com

Dear all,

I would like to create a SWV application, and my question is the following: how many variables can I read via SWO communication?

I mean, without considering the overflow packet that could be sent in case of huge information traffic, is there a physical limit regarding this topic?

If I've understood weel, DWT_COMPx registers, with x={1, .., 4} is used in order to store the variable address that I would like to monitor, and DWT_MASKx are also used in order to raise a valid new SWO packet.

Does this mean that it's possible to check only for four variables, or should I set the mask register in order to detect ranges of variables?
With the latter case I could be able to monitor a very large number of items.

Am I wrong or is this the right approach?

Thank you very much!
Parents
  • Note: This was originally posted on 28th February 2012 at http://forums.arm.com

    In most cases, the SWO will be running at a relatively slow frequency (compared to the processor), e.g. 1Mbit is possible with commerical debug adaptor.  There are FIFO in the trace system, but as you can imagine, the FIFO size is limited so if you have several data packeting coming out in a short period of time, the FIFO will be full and new packets will be dropped and wont be output. (A FIFO overflow packet will be generated so you will know that some trace data are lost).

    As a result, you cannot trace a big range of memory. For example, avoid capturing the stack memory space because you can have lots of read & write to the stack in very short time. Capturing a small address range is okay, but it all depending on how often the variables are accessed. And you can program the DWT to output the address as well as the data, so that the debugger can tell which address the data come from. So the general answer is - yes, you can use capture address range to monitor large number of variables, but the increase in data traffic could fill up the SWO bandwidth.

    Another factor you need to consider is that most debug tools are designed to capture access to variables, and not an address range. So even if you programmed the DWT to capture an address range, the information might not be able to be handled by the debug tool.

    regards,
    Joseph
Reply
  • Note: This was originally posted on 28th February 2012 at http://forums.arm.com

    In most cases, the SWO will be running at a relatively slow frequency (compared to the processor), e.g. 1Mbit is possible with commerical debug adaptor.  There are FIFO in the trace system, but as you can imagine, the FIFO size is limited so if you have several data packeting coming out in a short period of time, the FIFO will be full and new packets will be dropped and wont be output. (A FIFO overflow packet will be generated so you will know that some trace data are lost).

    As a result, you cannot trace a big range of memory. For example, avoid capturing the stack memory space because you can have lots of read & write to the stack in very short time. Capturing a small address range is okay, but it all depending on how often the variables are accessed. And you can program the DWT to output the address as well as the data, so that the debugger can tell which address the data come from. So the general answer is - yes, you can use capture address range to monitor large number of variables, but the increase in data traffic could fill up the SWO bandwidth.

    Another factor you need to consider is that most debug tools are designed to capture access to variables, and not an address range. So even if you programmed the DWT to capture an address range, the information might not be able to be handled by the debug tool.

    regards,
    Joseph
Children
No data