When I use jscope to monitor variables on Renesas RZ/T2L, I encounter some problems.

1. The value of HSS curve switchs betweend 0 and the correct value periodicaly, which shown in the below.

The monitored value show in the figure is const.

2. The value of RTT curve switch bwtweend two variables crossly.


At the begining, the first variable with blue curve is const, while the second variable with red cuve is incremental.
After a few seconds, the curves cross each other. The blue curve tracks the second variable in error, and red curve tracks the first variable. Then, they track correctly. The two cases appear alternately.
If I stop sampling and retart sampling, everthing is ok within a few seconds, then it repeats the abnormal sense descibed above.
So I think this is the bug of the J-Scope instead of jlink driver or MPU.

All of the variables used in test are located in SRAM without cache.

3. If the elf file changed on disk, J-Scope will pop-up a window to promot user to "Reparse symbols".
After the the parsing processbar reaches to end, the J-Scope will crash immediatly.

Thank you for your reply.

According to Renesas RZ/T2L - SEGGER Knowledge Base, I have set all of the test variales, RTT buffers and RTT control block at System RAM without cache which starts at 0x1000_0000.
1. HSS


These const variables swtich certain value with 0.
test.elf in attachment has these variables.
I also test HSS function on STM32F407 wthout cache which works correctly.
Therefor, maybe it is a bug on MCU? Or maybe it is the effect of cache or other MCU mechanism? However, I have set the attribute of system RAM to no-cache. I have no idea about this.
2. RTT

After many tests,I find out that the bug is related to the RTT buffer size.
In my test(RZ/T2L), the threshold of RTT buffer size which will lead to the bug is between 15kB and 16kB.(I also test on STM32F407, the threshold is about between 7k and 8k.)
The size of RTT buffer is set to 32k in test.elf, and the abnormal condition will appear at about 17 seconds after start sampling.

Beside theses bugs, there are some user experience related issues.
3.
If the curve is a little bit more complex and the time axis sacle is a little bit more large，the j-scope gui will freeze.
The example code can reproduct the issue.UM08028 J-Scope - SEGGER Knowledge Base
In the example code, the variables switch between 100 (or -100) and 0.
If a set the time axis scale eauql or bigger than 1s/Div, the action of dragging curve, zooming curve, or clicking any button can not response in time.
The current figure is shown below.

If the axis scale is more bigger, the GUI window will be "not responding", and I have to kill the process in "Task Manager".
4.
The parser of elf built for RZ/T2L(which is provided in attachments) is significantly slower than elf built for STM32.

The process bar will pause at 76% for seconds.
Whereas the process bar for parsing elf for STM32 whose size is about 1MB larger than the test.elf is very smooth, and the wait time is also shorer than elf for RZ/T2L.
I can not find out which compiler flags may effect the parser speed, or it maybe a bug for J-Scope?

According to Renesas RZ/T2L - SEGGER Knowledge Base, I have set all of the test variales, RTT buffers and RTT control block at System RAM without cache which starts at 0x1000_0000.

I am sure that I have set the correct config. Because when I set the RTT buffer at TCM or did turn on cache on system RAM , I got nothing.

And after my test, I think the abnormal behaviour of RTT funcion is a bug of jscope which is related to a bigger size of RTT buffer.
If I use a RTT buffer smaller than 15 kB, the RTT function works correctly.
If the RTT buffer is bigger than 16kB, the curves will cross each other which was described above.

As for HSS, If I set the sample rate to 50 Hz, it looks like working correctly. If I set the sample rate upper than 100Hz, the data will turn into 0 periodicity.
So, I guess the real sample rate is between 50 and 100Hz. If the set rate bigger than real rate, J-Scope can not get the true data in some samples and make the assumption these datas are zero.
If my guess is ture, is the supported real sample rate lower than 100Hz normal?
Otherwise, can you test the .elf in my last post to check whether the issue can be reproduced and find what makes it malfunction。