ANSI/XTerm Control Sequences in raw terminal ?

Sysprogs forums Forums VisualGDB ANSI/XTerm Control Sequences in raw terminal ?

Tagged: 

Viewing 15 posts - 1 through 15 (of 16 total)
  • Author
    Posts
  • #21690
    Noyb
    Participant

    Is it possible to use ANSI/Xterm escape sequences to get advanced output from an STM32 board ?

    Trying to place the cursor at absolute position with “\033[row;colH” but to no avail.

    http://en.wikipedia.org/wiki/ANSI_escape_code
    http://www.xfree86.org/4.8.0/ctlseqs.html
    http://rtfm.etla.org/xterm/ctlseq.html
    http://gist.github.com/justinmk/a5102f9a0c1810437885a04a07ef0a91
    https://stackoverflow.com/questions/4842424/list-of-ansi-color-escape-sequences

    #21695
    support
    Keymaster

    Hi,

    VisualGDB already supports the ANSI escape codes. We have tested the following code with STM32 and it was properly outputting “t2st”:

     printf("test\n\x1b[1;2H2\x1b[1;1H");
     fflush(stdout);

    There was, however, a bug where the semihosting console state was not properly reset if the previous debug session contained invalid/incomplete escape codes. We have fixed it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2400.msi

    #21698
    Noyb
    Participant

    Thanks, just tested your last build, but still doesn’t work, even if previous text flushed things clean beforehand.

    Attachments:
    You must be logged in to view attached files.
    #21717
    support
    Keymaster

    Hi,

    Sorry, we have rechecked this and could not reproduce any problem. Please try switching the terminal to the hex mode and ensure that the ‘escape’ character is transmitted properly.

    E.g. try transmitting exactly the line shown in our previous post and verify that the HEX view shows the following output:

    74 65 73 74 0a 1b 5b 31 3b 32 48 32 1b 5b 31 3b 31 48
    #21720
    Noyb
    Participant

    Got this, that might explain things:

    01 74 01 65 01 73 01 74 01 0a 01 1b 01 5b 01 31 01 3b 01 32 01 48 01 32 01 1b 01 5b 01 31 01 3b 01 31 01 48

    It’s the following in ITM_SendChar that send the couple ’01 xx’ when ‘ch’ holds ‘xx’ :

    ITM->PORT[0U].u8 = (uint8_t)ch;

    Now looking at possible bad configuration of the trace register.

    • This reply was modified 5 years, 7 months ago by Noyb.
    #21724
    Noyb
    Participant

    Tried to force tpi.ffcr.enfcont to 0 but it is even worse. But I suspect there is something going on about the formatter but I cannot see what.

    #21725
    support
    Keymaster

    Hi,

    It looks like the software you are using to decode the ITM output doesn’t strip the channel number from the stream, thus prefixing every transmission with 01. Depending on the exact software, there might be a setting to do that and display just the raw output.

    #21728
    Noyb
    Participant

    Not using any software to do the decoding, just writing to ITM and using the appropriate ‘monitor SWO EnableTarget 24000000 0 0x01 0’ command into the VisualGDB properties, additional GDB commands, to enable the tracing from the probe.

    I do hack a few DBGMCU, ITM, TPI, DWT registers to get the ITM.port[O] working though, but I squeeze out everything to just keep the SWO output. Now if you tell me I have to decode the frames and filter out things, I’d be glad to have a few hints.

    • This reply was modified 5 years, 7 months ago by Noyb.
    #21730
    support
    Keymaster

     

    Thanks for the explanation. The “monitor” commands are handled by the gdb stub used together with VisualGDB (typically either the Segger GDB stub, or OpenOCD). We would advise checking the Segger gdb stub documentation (or OpenOCD source code) for options that might turn on the ITM output decoding.

    #21738
    Noyb
    Participant

    So between the ARM ITM output on the SWO pin and your raw terminal, there is only Segger able to do something about it ?

    #21739
    support
    Keymaster

    Hi,

    If you are using the Segger GDB stub, yes, the stub is responsible for reading the ITM-related registers and generating the output stream shown in the Raw Terminal window, hence it’s up to the stub to control the exact output format. Please check with Segger whether there is an option for removing the that. Another option would be to create a basic tool that will work like a proxy server between the gdb stub and the raw terminal, removing the extra symbols (you would need to know where exactly the Segger stub inserts the channel number bytes).

    #21800
    Noyb
    Participant
    #21801
    Noyb
    Participant
    #21809
    support
    Keymaster

    Hi,

    Yes, if you already have a tool that connects to the Segger’s telnet port and accepts TCP connections on another port, simply add its invocation to VisualGDB Project Properties -> Custom Debug Steps and then configure raw terminal to open on localhost:<port used by the tool>.

    Another option would be to modify the tool to print decoded output to stdout and simply use Custom Debug Steps -> Remote Console -> Use the following command.

    #21818
    Noyb
    Participant

    No, I don’t have such a tool that would interface between Segger’s telnet port and forward VisualGDB with a filtered stream. Obviously I’m not the only one expecting this :

    https://github.com/gnu-mcu-eclipse/eclipse-plugins/issues/311

    This project might help, but I have no clue how to interface it with VisualGDB :

    https://github.com/orbcode/orbuculum

Viewing 15 posts - 1 through 15 (of 16 total)
  • You must be logged in to reply to this topic.