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

Output data via SWO without debugger ?

Note: This was originally posted on 15th November 2010 at http://forums.arm.com

Hello,

i am using a Cortex-M3 (in my case a TI Stellaris LM3S9B92 Rev B1).
I would like to know, if it is possible to output data via SWO without a debugger ?
Do i need any clocks (via SWD) from outside (normally generated by the debugger) to output data via SWO (UART, not Manchester) ?

I already tried the following from inside Cortex-M3:

In setup:

#define TRCENA       0x01000000

#define DEMCR     (*((volatile unsigned long *)(0xE000EDFC)))
#define TRACE_ENABLE_REGISTER     (*((volatile unsigned long *)(0xE0000E00)))
#define TRACE_CONTROL_REGISTER       (*((volatile unsigned long *)(0xE0000E80)))
#define ASYNC_CLOCK_PRESCALER_REGISTER  (*((volatile unsigned long *)(0xE0040010)))
#define SELECTED_PIN_CONTROL_REGISTER   (*((volatile unsigned long *)(0xE00400F0)))

             DEMCR = DEMCR | TRCENA;

             TRACE_ENABLE_REGISTER = 0xFFFFFFFF;

             TRACE_CONTROL_REGISTER = 0x00000001;

             ASYNC_CLOCK_PRESCALER_REGISTER = 10;

             SELECTED_PIN_CONTROL_REGISTER = 0x00000002;

In main loop:

   if (DEMCR & TRCENA)
   {
     while (ITM_Port32(0) == 0);
     ITM_Port8(0) = 0x41;
   }


But i don't see any activity on SWO, nor is the line switched to output at all...

Best regards,

Martin
  • Note: This was originally posted on 15th November 2010 at http://forums.arm.com

    Hello Joseph,

    many thanks for your answer !


    The ITM has a lock register that you need to unlock before programming the ITM.
    After setting TRCENA, could you add
    #define ITM_LOCK_ACCESS_REGISTER  (*((volatile unsigned long *)(0xE0000FB0)))
    ITM_LOCK_ACCESS_REGISTER = 0xC5ACCE55;


    Unfortunately it is still not working. Is there perhaps some switch to enable SWJ, disable JTAG ?
    The pin where SWO is on behaves still like an input.
    Is there some clock on TCLK needed for at leats part of the functionality ?

    Best regards,

    Martin
  • Note: This was originally posted on 17th November 2010 at http://forums.arm.com

    Hello Joseph,

    first i want to say a big thank you, with your help i meanwhile have UART data on SWO.


    Yes, if the debug interface is in JTAG mode, there is a switching sequence to switch it to Serial Wire model.
    (http://infocenter.ar...d/Chdhfbhc.html)


    I was able to switch to SWD via Keil uVision4 (via start debug in SWD mode). When i reach SWD, i see data coming out of SWO.
    For testing purposes I call every 1 ms the following code:

         while (ITM_Port32(4) == 0);
         ITM_Port32(4) = field;

         while (ITM_Port32(8) == 0);
         ITM_Port32(8) = field;

    On my logic analyzer (decoding UART data, 7,27 MBaud = 80 MHz / 11) i see the following content (always 16 byte in a packet every 1 ms)

    01 23 F4 F5 F4 F5 42 F5 F4 F5 01 F5 00 00 00 3E

    I have an a 8 bit ctr which i fill 4 times into each byte of field (which is 32 bits wide, 4 * 8 bit = 32 bits), so i expected to see e.g. F4 F4 F4 F4 or F5 F5 F5 F5 as content.
    Because data bit 0 seems to be some kind of random, could it be, that i write to ITM_Port, just when it is not allowed (wrong timing) ?
    Is there some other register than i used inside the while, which i must use to synchronize ?

    23 seems to be SWIT, according to http://infocenter.ar...H.html#Chdhdjaa
    meaning Port is 4, length of data is 4, which is correct.
    But second transmission surprises me:
    42 meaning Port is 8, ok, but length is 2 bytes.

    Do you know what is the meaning of 01 at the beginning ? And it looks like again after 10 bytes. I read somewhere that FIFO is only 10 bytes. Could it have to do something with it ?

    Is the overall frame format somewhere explained ? What is the meaning of the 3 bytes 00 and following 3E ?

    How do i find the start of data ? Is it (only) via sync packet, which i must switch on or is there another mechanism ?

    I also tried to output to only one port. I see the following content:

    01 03 xx xx xx xx 01 00 00 00 00 00 00 00 00 02

    Again 16 byte packet, again same question on 01 at beginning and now after 6 bytes, again some 00 and some final byte.


    May I ask you why do you want to use the ITM without a debugger? :-)
    (I suppose you could use a UART for text output?)


    We already use the UART for debugging, but think the speed and built-in features (like the timestamp or channel info) could give us additional benefit for tracing.

    Again many thanks for your help.

    Best regards,

    Martin
  • Note: This was originally posted on 24th November 2010 at http://forums.arm.com

    Hi Joseph,


    From memory the Cortex-M3 has additional packets (for DWT) and the protocol details are documented in the ARMv7-M Architecture Referenence Manual.
    (ARM DDI 0403).  Please note that the ARMv7-M Application Level Architecture Referenence Manual (ARM DDI 0405) does not include this information.
    You'll need to register on ARM website to get this docment.


    many thanks for the hint to DDI 403. Jumping from one superseeded version to another, i think i know have used the right and latest one:
    DDI0403D_arm_architecture_v7m_reference_manual.pdf

    I am meanwhile able to generate and decode some of the fields, but i am still missing the overall structure.

    Example (same as above)
    01 03 xx xx xx xx 01 00 00 00 00 00 00 00 00 02

    I found out that the first byte contains an id (ATIDM[6:0] value), which i can program via TRACE_CONTROL_REGISTER.
    (http://infocenter.ar...h/Chdiicbc.html)
    03 seems to be SWIT, then four bytes, which i wrote to ITM_Port32.
    (http://infocenter.ar...H.html#Chdhdjaa)

    But then i am lost, what is the meaning of the second 01 ? Is it again an ATIDM ? Or SWIT ? Or something completely different ?
    And the multiple 00 and final 02 ?

    Can you help me here or perhaps point me to some additional documentation ?

    Best regards and many, many thanks,

        Martin
  • Note: This was originally posted on 17th December 2010 at http://forums.arm.com

    Hi Joseph,
    i just want to say a big thank you for your help !
    Not all my problems are solved till now, but your answers were a great help to get a big step forward !
    Best regards,
    Martin
  • Note: This was originally posted on 15th November 2010 at http://forums.arm.com

    Hi Martin,

    The ITM has a lock register that you need to unlock before programming the ITM.

    After setting TRCENA, could you add

    #define ITM_LOCK_ACCESS_REGISTER  (*((volatile unsigned long *)(0xE0000FB0)))
    ITM_LOCK_ACCESS_REGISTER = 0xC5ACCE55;

    and see if it helps?

    Joseph
  • Note: This was originally posted on 16th November 2010 at http://forums.arm.com

    Hi Martin,

    Yes, if the debug interface is in JTAG mode, there is a switching sequence to switch it to Serial Wire model.

    (http://infocenter.arm.com/help/topic/com.arm.doc.ddi0316d/Chdhfbhc.html)

    Depends on the TDO/SWO output connection design, I guess the pin is used as JTAG TDO unless the debugger switch it to serial wire debug mode.
    Unfortunately there is no way to control the switching by software. (It is not impossible, but I don't think any Cortex-M3 microcontrollers has such programmable register in the system level design to override the TDO/SWO usage.  It is just something that we don't expect users to do.).

    It you really want to, you can try to put two jumpers on your PCB to connect TMS and TCK to I/O port and switch it to serial wire mode by software. (Without a debugger connected of course).

    May I ask you why do you want to use the ITM without a debugger? :-)
    (I suppose you could use a UART for text output?)

    regards,
    Joseph
  • Note: This was originally posted on 18th November 2010 at http://forums.arm.com

    Hi Martin,

    Thanks for the update and information, and glad to know that you are making progress.

    From memory the Cortex-M3 has additional packets (for DWT) and the protocol details are documented in the ARMv7-M Architecture Referenence Manual.
    (ARM DDI 0403).  Please note that the ARMv7-M Application Level Architecture Referenence Manual (ARM DDI 0405) does not include this information.
    You'll need to register on ARM website to get this docment.

    regards,
    Joseph
  • Note: This was originally posted on 26th November 2010 at http://forums.arm.com

    Hi Martin, sorry for the delay. I am away on holiday right now and don't have the technical document with me so cannot check this for you at the moment. I will be back in office on 6-Dec. regards, Joseph
  • Note: This was originally posted on 6th December 2010 at http://forums.arm.com

    Hi Martin,

    Could you check bit 1 of TPIU's Formatter and Flush control register (0xE0040304)?
    If it is 1, try clear this bit to 0 and see if it help.

    regards,
    Joseph
  • Note: This was originally posted on 20th December 2010 at http://forums.arm.com

    You're welcome. :)