Sysprogs forums › Forums › VisualGDB › ANSI/XTerm Control Sequences in raw terminal ?
Tagged: terminal
- This topic has 15 replies, 2 voices, and was last updated 5 years, 7 months ago by support.
-
AuthorPosts
-
August 16, 2018 at 16:12 #21690NoybParticipant
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-sequencesAugust 16, 2018 at 19:22 #21695supportKeymasterHi,
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
August 17, 2018 at 07:39 #21698NoybParticipantThanks, 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.August 18, 2018 at 21:59 #21717supportKeymasterHi,
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
August 20, 2018 at 09:07 #21720NoybParticipantGot 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.
August 20, 2018 at 13:35 #21724NoybParticipantTried 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.
August 20, 2018 at 17:20 #21725supportKeymasterHi,
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.
August 20, 2018 at 20:00 #21728NoybParticipantNot 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.
August 20, 2018 at 20:11 #21730supportKeymasterThanks 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.
August 22, 2018 at 12:29 #21738NoybParticipantSo between the ARM ITM output on the SWO pin and your raw terminal, there is only Segger able to do something about it ?
August 22, 2018 at 17:07 #21739supportKeymasterHi,
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).
August 27, 2018 at 14:27 #21800NoybParticipantCould it be integrated into the “raw terminal” ?
August 27, 2018 at 16:35 #21801NoybParticipantAugust 28, 2018 at 05:16 #21809supportKeymasterHi,
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.
August 28, 2018 at 10:03 #21818NoybParticipantNo, 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 :
-
AuthorPosts
- You must be logged in to reply to this topic.