Search Results

Awesome, thanks!

Since upgrading to v6.72b the fonts have gone tiny on my 4k monitor. If I change the font via the menu from 10 to 12 it goes HUGE and then I change it back to 10 and it is normal. While I am here a menu option to hide the bottom log panel would be great. Cheers, Andre

Looks like this has been fixed in the latest beta version 6.53e. Thanks.

It looks as though v6.52e of RTTViewer cannot handle tab characters in the stream (\t). The results are undefined, as in the text may or may not appear. If I highlight the area on the rttviewer display I can copy it to a text editor and the data is all present. When highlighting the text some of it appears during the highlighting and i can make out the end of each line of text. I have attached a screen shot, but it is very easy to reproduce and was not present in previous versions (6.50 or so)

When I copy text off the current RTT viewer and attempt to paste it into a text editor i get weird characters visible. 0000:0150 33 0D 0A 0D 0A 4F 4B 0D - 0A  Any idea what could be causing the  character appearing between all the spaces in the words? It never used to do have this behaviour, and logging to file does not include the Â, but if i haven't starting logging it's not much help. I also used to be able to press Control+A and then copy to get the trace into an editor but this…

I think it means that it is receiving a non-ascii character in the stream - or interpreting it that way. I am using 6.50b and don't seem to see that issue - but i do have issues with attempting to use vt100 colour codes with rtt viewer showing WARNING: ANSI CSI SGR parameter 39 not supported. when trying to clear the colour formatting - i probably need to use the RTT specific defines, but it works fine for other terminals

I have been using the latest v6.42d and there is still a lot of lag in the RTT viewer compared to say v6.32i Actually I ran another test, 6.32i RTT Viewer is about 1000% faster than anything released after that - 6.42d and 6.43a are both hopelessly slow. I assume you are somehow buffering the data before writing it out to the display, whatever you used to do was perfectly adequete. I end up going back and using it even though the DPI support is kinda poor in that version.

I would like to 2nd this, it makes using the trace pretty hard as i have to wait 30secs after i hit a breakpoint before the RTT trace has caught up with the device. It takes at least 30secs, possibly 40-50secs, to get all the data out into the window, this has got worse since maybe v6.33, prior to that I had never noticed a delay in the window refresh.

Hi all, I'm using the latest J-Link package - 6.34F and since 6.34 was released the RTT Viewer doesn't heed the line feed settings from the Input->End Of Line. No matter what i change it to i have to send a CR and a LF. Previous versions it was enough for me to set it to Linux (LF). This is on Window 10. Regards, Barak.