I'll attach an strace log:
strace -o trace.txt -f /opt/SEGGER/JLink/JLinkGUIServerExe
showing a
* succesful open and close of a telnet connection (line 2545 ..)
* 10s wait (line 2665 ..)
.. it then seems to close the server socket in line 2765
* a failed telnet connection
server is now stuck in a 100% CPU loop while calling pselect6 for the already closed server socket.
The problem can also be reproduced using telnet:
Good case:
$ /opt/SEGGER/JLinkGUIServerExe &
$ telnet 127.0.0.1 19022
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
J-Link GUI server;V8.12b;
Bad case:
$ /opt/SEGGER/JLinkGUIServerExe &
<<< WAIT 10 seconds >>>
$ telnet 127.0.0.1 19022
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Connection closed by foreign host.
-> JLinkGUIServerExe now takes 100% CPU.
As a workaround, the processes can be killed with killall JLinkGUIServerExe.
Another workaround is to simply rename the JLinkGUIServerExe file:
sudo mv /opt/SEGGER/JLinkGUIServerExe{,_bak}
Surprisingly, this does not have any effect on the Ozone session..
Hi!
I'm using Ozone 3.38c with a J-Link Pro under Arch Linux, installed from AUR.
Since a few versions, I noticed that Ozone starts one or more JLinkGUIServerExe processes that take 100% CPU after a short while.
What is the purpose of this process?
SystemView 3.12, STM32H743ZI with FreeRTOS
.. hard to describe:
1) When opening the Recorder Configuration Dialog, and have a IP Connection configured, the Dialog shows "Serial Number" instead of "IP or Nickname". The correct "IP or Nickname" is only shown after selecting "USB", and then re-selecting "IP".
2) The same is true for the input field of the RTT group. You have to select "Auto", and "Address" again, before the field is visible.
3) When switching between "Address" and "Search Range", it seems that the same variable is shared for both settings.
Example:
* Click on Address, enter "0x2001c2f4"
* Click on Search Range, I would expect an empty field, or at least the range that was set last time.
SystemView 3.12, STM32H743ZI with FreeRTOS
In SystemView 2.52, there was an option to use an "Existing Session".
So it was possible to run Ozone and SystemView at the same time, and it also solved the RTT Block search issues (see my other bug report).
Is this feature gone for good? Or is there a way to do it in 3.12?
Best regards,
Thomas
SystemView 3.12, STM32H743ZI with FreeRTOS
Hi!
I've placed my RTT buffers in DTCM RAM to keep AXI and cache contention down.
(The actual address is 0x2001c2f4)
Unfortunately, the "Auto" search function does not find my buffers.
I have to enter a manual search range of "0x20000000 131072".
Could you add the DTCM area to the auto search?
best regards,
Thomas
Cool!
I just installed Ozone_Linux_V310h_x86_64.deb and updated my JLink using JLink_Linux_V672a_x86_64.deb
Everything seems to work now, DBGMCU registers can be read out correctly and trace still works.
Thanks for the great fix!
We can now enable ETF by default for all our debug sessions!
I think, SystemView 3.12 has the same problem.
The .deb installs fine in Ubuntu 20.04, but gives this Error:
SystemView: error while loading shared libraries: libQtGui.so.4: cannot open shared object file: No such file or directory
Any updates?
Best regards,
Thomas
Ozone 3.10f (Linux):
Paste this into source view, and observe wrong behavior:
void syntax_highlight(void)
{
char c = '"';
// ^ All text shown in red from here on
//
}(The forum software gets it right 
)
best regards,
Thomas
We are still experiencing this problem. Do you have any update?
Best regards,
Thomas
Hi Nino!
I just found out that it was my fault.
Ozone shows the data and function entries as expected!
Sorry for the noise 
best regards,
Thomas
Hi!
Therefore we suggest that you correct the HAL-init to use the right address space (see above).
I think you may have posted the wrong screenshot. Perhaps you meant chapter 59.5.8. ?
But, unfortunately, 0xE00E1000 also reads as zero.
You should be able to reproduce that result on your side.
The work-around/hack is not recommended.
I was not yet able to find a work-around..
Of course, I could fake the HAL_GetREVID function, but we have a mix of Rev. V and Y in the field, so a real solution is needed.
We recommend getting in contact with ST, since this is an error in their HAL which should be fixed in the ST sorces.
ST has an open bug tracker on GitHub.. but what exactly should I report?
Best regards,
Thomas
Do you have any update on this topic?
Ozone 3.10d
In C, it's possible to have two distinct global static variables or functions with the same name in different source files.
For example:
a.c
static int foo;
static void bar(void)
{
}
b.c
static int foo;
static void bar(void)
{
}
In this case, the "Global Data" and "Functions" View lists only one of them (depending on the order in the linked .elf file).
I would expect that all variables and functions are shown with their according source file in the "Scope" column.
Do you have any update on this topic?
Or do you have an example work-around script?
It's not entirely clear how I could write one myself..
Hi!
I haven't checked on 2) yet.
But regarding ETF-Trace:
Does that mean, that the Timestamps checkbox does not work for ETF?
Then I think that the combined Data sampling/Instruction trace window is a little bit misleading..
I was confused for a few hours, until I connected a scope and noticed the bogus time measurements.
If it's not on the same timeline, data samples and trace really should not be shown to be correlated.
Googling for 0x5C001000 turns up some interesting results..
This might be relevant to you:
https://xor-gate.org/post/stlink-arm-ap-access/
"On the STM32H743 there is an APB-AP on APSEL 2 which I suppose may be present on other STM32's as well. Through this AP you can access the DBGMCU at its documented address 0xE00E1000. However, if you use the standard ST-Link memory access commands they will clobber AP2's CSW.DbSwEnable bit. This then prevents accesses to the DBGMCU via AP0 (and presumably the CPU) at 0x5C001000. Access can be restored by manually setting AP2's CSW.DbSwEnable with the new Write AP Reg command."
Hi!
Setup:
I am using Ozone 3.10b and a STM32H743 @ 480MHz.
I've set up ETF trace according to wiki.segger.com/STM32H7#Tracing_on_ST_STM32H743
In the trace settings dialog, I set the source to Trace Buffer, and CPU Frequency to 480000000.
I'm using the .pex file from
https://wiki.segger.com/images/b/b8/ST…TraceBuffer.zip
Problem:
After the OnTraceStart() hook of the pex-File is run, the DBGMCU->IDCODE register at 0x5C001000 reads 0x00000000 instead of the expected 0x20036450.
This can also be seen in Ozone's memory view. OK without trace, 0 after OnTraceStart.
The problem is only resolved by a power cycle. A reset is not sufficient.
This is problematic, because the IDCODE register is used by ST's HAL code to enable errata workarounds:
https://github.com/STMicroelectro…tm32h7xx.c#L229
https://github.com/STMicroelectro…l_adc_ex.h#L579
https://github.com/STMicroelectro…_ll_adc.h#L2572
best regards,
Thomas
