• Locked Locked
  • Replies 13 replies
  • Subscribers 119 subscribers
  • Views 6829 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
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

Pietsuro Botsutoshi
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!
  • Note: This was originally posted on 26th March 2012 at http://forums.arm.com

    Ciao Joseph, thank you again for your support.

    Considering the available documentation, 0x0000000D and 0x0000000E values for DWT_FUNCTIONx are set as reserved.
    Am I reading an old release?

    In any case, I'm not able to read SWO packets with only write information for the registered variable, but only tons of local timestamps (with value 1999999).

    This is my activation flow:

    • DWT_CTRL = 0x400003FE
    • DWT_COMP0= 0x2000017C
    • DWT_MASK0 = 0x00000001
    • DWT_FUNCTION0 = 0x0000000D
    • DEMCR = 0x01000000
    • SELECTED_PIN_PROTOCOL_REGISTER = 0x00000002
    • TPIU_ACPR= (72000000 / 500000) - 1
    • ITM_LOCK_ACCESS_REGISTER = 0xC5ACCE55
    • ITM_TCR = 0x0001000F
    • ITM_TPR = 0x0000000F
    • ITM_TER = 0x00000000
    • TPIU_FFCR = 0x00000100
    The address of the variable to read is 0x2000017C and it represents an unsigned short value, so 2 bytes-length.

    Any idea?

    Thank you again.
  • Note: This was originally posted on 26th March 2012 at http://forums.arm.com

    Ciao Joseph,

    great reply, thank you again.

    And now just a hint request...anyhow things are getting more clear in my mind now, so thank you very much.

    I'd like to monitor several variables with SWO, but for more than two of them I get overflow packets.

    Ok, I know this is a "physical" protocol limit, but can you please list a collection of tips or must-do-do in order to achieve best possible performances for this type of task?

    For instance, is it better to use a single DWT_COMP register with DWT_MASK greater than 0 or to assign to every variable to monitor each specific DWT_COMP component?
    Any suggestion regarding prescaling settings?

    Thanks for the cooperation!
  • Note: This was originally posted on 28th March 2012 at http://forums.arm.com

    Ok, and that's clear.

    Now, a question regarding the synch packet.

    Considering the documentation, I could have at least 47 bits set to 0 followed by a single 1 bit.

    The reported example shows the minimum synch packet format, 7 bytes length.
    I think that the first one represents the header, and the remaining 6 bytes the payload.

    I would like to understand this aspect: if I had 6 bytes set to 0 (48 bits) then I could have the first bit of the next byte set to 1 in order to detect the complete frame.

    But at this point, I can only have a 0x80 value (in order to complete the byte, 7 dummy bits se to 0) or is it possible to retrieve any other information?

    For example the byte that concludes the 0b0s series could be defined as 0xFF, where the most significant bit is the one with synch meaning, and the other 7 bits that represent any other information? Or, and I hope for this solution, I can only get values like 0x80, 0x40, 0x20, 0x10, 0x08, 0x04, 0x02, 0x01?

    Thank in advance Joseph!
  • Note: This was originally posted on 6th March 2012 at http://forums.arm.com

    Dear Joseph,

    thank you very much for your support, and now a question regarding how to set variables for checking read and write operations.

    I would like to register several definitions (don't take care about packet overflow, I want only to understand how this task can be implemented) and let's suppose this is my current situation:

    • variable A, 2 bytes length @0x2000017C
    • variable B, 1 byte length @0x20000190
    • variable C, 2 bytes length @0x20000146
    • variable D, 1 byte length @0x20000144
    • variable E, 2 bytes length @0x2000023E
    Now, if I've understood correctly, DWR Comparator Register (0-3) are the registers to set in order to perform variable monitoring.
    But how can I set them?

    I think I should use the mask registers (Mask Register0-3) but I'm not able to understand how I should set their values.

    Could you help me?

    And what about DWT_FUNCTION(0-3) registers?

    Thank you in advance!!!
  • Arm Employee Badge
    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
  • Arm Employee Badge
    Note: This was originally posted on 9th March 2012 at http://forums.arm.com

    Hi,

    Sorry for the delay. It has been a very busy week.

    In your case, variable C and D are very close to each other, so we can set up one comparator to be trigger on both variables:

    First, set TRCENA bit in DEMCR to 1 to enable the trace subsystem including the DWT.

    • variable A, 2 bytes length @0x2000017C[list]
    • DWT_MASK0 = 1 (half word size)
    • DWT_COMP0 = 0x2000017C
    • DWT_FUNC0 - depends on what you want to capture from SWO, for example[list]
    • 0x02 - emit data on read/write
    • 0x03 - emit PC and data on read/write
    • see ARMv7-M architecture reference manual for details of this register
    [/list]
    • variable B, 1 byte length @0x20000190
      • DWT_MASK1 = 0 (byte size)
      • DWT_COMP1 = 0x20000190
      • DWT_FUNC1 -again, depends on what you want to capture
      • variable C, 2 bytes length @0x20000146, variable D, 1 byte length @0x20000144
        • DWT_MASK2 = 2 (word size, or 4 bytes)
        • DWT_COMP2 = 0x20000144 (cover 0x20000144 to 0x20000147)
        • DWT_FUNC2 -again, depends on what you want to capture
        • variable E, 2 bytes length @0x2000023E
          • DWT_MASK3 = 1 (halfword size)
          • DWT_COMP3 = 0x2000023E
          • DWT_FUNC3 -again, depends on what you want to capture[/list]You can increase MASK register to increase the capture range, but you need to make sure the address is aligned to the boundary of the corresponding size.
            Also, the more data address range to be capture by each comparator, you might end up with much more trace traffic and you will need to filter out unwanted information, and potentially lost information due to trace overflow.

            regards,
            Joseph
        • Arm Employee Badge
          Note: This was originally posted on 23rd March 2012 at http://forums.arm.com

          Hi,

          Regarding DWTx_MASK:
          0 = 1 byte
          1 = 2 bytes
          2 = 4 bytes
          3 = 8 bytes
          4 = 16 bytes , ..., etc

          > DWT_COMPx = address of the variable to monitor (if several variables are contiguously defined, then here the lower address)

          Please note that you need to have the address value being multiple of the compare address size. For example, if DWTx_MASK is set to 4 (16 bytes), then the address value should be multiple of 16.

          You can use DWT to halt the processor when the PC match a certain value. In that case you need to set the Func field in DWTx_FUNC to 0x4.
          But for monitoring variables using SWO you use function 1 - 3, and 12-15, with DWTx_COMP being the address value of the variable(s).

          You can setup the DWTx_MASK to capture multiple variables in an address range, but by doing so you will need to emit the address values as well so that you can tell which variable of that address range is being accessed. Also, if you try to capture a large address range you can easily get buffer overflow in the trace system.

          In most cases, since there are only maximum of 4 comparators in DWT, a debugger will limit the number of software variables that you can monitor to 4 to make it easier to handle.

          If you want to generate a packet when a byte in 0x2000017C is written to, then
          • DWT_CTRL = 0x400003FE
          • DWT_COMP0 = 0x2000017C (address to monitor)
          • DWT_MASK0 = 0x0000000 (1 byte to monitor)
          • DWT_FUNCTION0 = 0x0000000D (emit data for write transfer) / 0x0000000E (emit PC & data for write transfer)
          regards,
          Joseph
        • Arm Employee Badge
          Note: This was originally posted on 26th March 2012 at http://forums.arm.com

          Hi,

          I forgot to mention that function 0xC to 0xF are available from Cortex-M3 r2p0. The chip that you are using could be from Cortex-M3 r1p1, which might not have the capability to generate data trace on data write only.  For r1p1 or earlier versions of Cortex-M3, you can only use function 0x0 to 0xB.

          You can find the r2p0 TRM from here : http://infocenter.arm.com/help/topic/com.arm.doc.ddi0337g/DDI0337G_cortex_m3_r2p0_trm.pdf

          regards,
          Joseph
        • Arm Employee Badge
          Note: This was originally posted on 27th March 2012 at http://forums.arm.com

          Not much really, apart from trying to run the SWO as fast as possible.

          If you use separated comparators (one comparator for one variable), you don't need to emit the address offset.
          If you use one comparator for multiple variables, you will need to emit the address offset so that you can tell which access is which data, so it will take more bandwidth.

          Also, if you have the timestamp is enabled it will also need more data bandwidth. So if the bandwidth is limited, then don't enable the timestamp packet generation.

          regards,
          Joseph
        • Arm Employee Badge
          Note: This was originally posted on 28th March 2012 at http://forums.arm.com

          Hi,

          In general you won't consider the first byte of sync packet as header.
          Before trace stream is synchronized you won't know where the start is,
          so you look for continuous of 47 bits 0 an then a 1 to tell where the trace start.

          I am out of office at the moment and will be back next week.
          If it is not urgent I get back to this when I am back.

          regards,
          Joseph
        • Arm Employee Badge
          Note: This was originally posted on 10th April 2012 at http://forums.arm.com

          Hi,

          Sorry for the delay. I was having a very busy schedule last week.

          Try think of it as bit stream
          The sync packet is 47 bit of 0 followed by a 1.
          Depends on your synchronization situation before you get the first byte, you might have already missed 7 bit of zeros which was merged into last bytes.

          Then you get 1 byte of zeros (8 bits), so you get minimum of 4 bytes of sub sequence zeros.
          Then you will get things like
          xxxxxxx1, or
          xxxxxx10, or
          xxxxx100, or
          ...
          10000000

          If MASK size is set to 0x2 (word size), the address value set in COMPx must be multiple of word size.
          So your solution does not work.
          regards,
          Joseph
          P.S. I am out of office next two weeks.