Hello SEGGER Team,
I am really enjoying using JLink PLUS and Ozone for debugging embedded targets, thank you.
Recently I've started to implement a bare metal application for Raspberry Pi 3B+ (BCM2837, Cortex-A53, aarch64, at the moment single core).
Yes, I know, SEGGER don't support officially this platform, but I've successfully managed to establish a full debug session using JLink and Ozone, and I am very happy of that. The only thing I had to write was a small little stub in the JLinkScript file for RPi 3B+:
void InitTarget(void) {
CORESIGHT_CoreBaseAddr = 0x80010000;
JLINK_ExecCommand("CORESIGHT_SetCTICoreBaseAddr=0x80018000");
}
The reason I am writing a post here is that in recent Ozone (3.38c) the debugging of this target is very, very slow. Stepping to next lines takes 1-2-3 seconds, resetting the target even more. It's simply unusable. Registers are taking long to update, putting breakpoints slow, memory update is slow. I am working on Xubuntu 24.04 LTS, but on Windows 10 it works even slower.
[Target interface speed is constantly 15MHz, I am using short JTAG cables, the ELF file is very small (100K). Based on experience with other processors (iMX6, STM32, others) it should work MUCH faster]
I've tried going to older verions of Ozone and to my surprise I finally found version 3.34 (pure) that is working fast again! Everything works instantly. Stepping is instant, resetting is instant. No lagging. Everything refreshes amazingly fast. Love it.
So my conclusion is - there is definitely some performance degradation between Ozone versions 3.34 and newer (3.34a is already slower).
I've attached JLinkLog files from version 3.34 and 3.38c. I have separated with blank spaces crucial moments when stepping in code to next lines.
As you can see, for 3.38c, the first STEP is maybe even fast, but all other are slower and slower.
What brings my attention is that the biggest slowdown happens right after the `JLINK_ClrBPEx` function call:
...
TF18006C0 046:381.787 JLINK_ReadRegs_64(NumRegs = 1)
TF18006C0 046:381.792 SP (32) = 0x7FFE0
TF18006C0 046:381.797 - 0.011ms returns 0
TF18006C0 046:381.808 JLINK_FindBP(Addr = 0x0008068C)
TF18006C0 046:381.814 - 0.007ms returns 6
TF18006C0 046:381.820 JLINK_ClrBPEx(BPHandle = 0x00000006)
TF18006C0 046:381.827 - 0.008ms returns 0x00
TF5BF97C0 046:825.348 JLINK_IsHalted() <---------------- 500ms difference, SLOW!
TF5BF97C0 046:825.391 - 0.043ms returns TRUE
TF5BF97C0 046:825.395 JLINK_ReadRegs_64(NumRegs = 1)
TF5BF97C0 046:825.413 CPSR (41) = 0x200003C9
...
Where for Ozone 3.34 there is no big lag at all:
...
TC30006C0 027:397.701 JLINK_ReadRegs_64(NumRegs = 1, Indexes:
TC30006C0 027:397.705 194)
TC30006C0 027:397.711 -- AARCH32_R13=0x3F215040
TC30006C0 027:397.718 - 0.017ms returns 0
TC30006C0 027:397.727 JLINK_FindBP(Addr = 0x0008067C)
TC30006C0 027:397.733 - 0.005ms returns 4
TC30006C0 027:397.737 JLINK_ClrBPEx(BPHandle = 0x00000004)
TC30006C0 027:397.743 - 0.006ms returns 0x00
TC71537C0 027:402.091 JLINK_IsHalted() <--------------- 5ms difference, fast!
TC71537C0 027:402.124 - 0.033ms returns TRUE
TC71537C0 027:402.127 JLINK_ReadRegs_64(NumRegs = 1, Indexes:
TC71537C0 027:402.130 41)
TC71537C0 027:402.158 -- CPSR=0x200003C9
...
Maybe something has changed in respect to putting and clearing breakpoints in Ozone recently?
Since stepping in the code involves putting and clearing a temporary breakpoint then maybe that's the issue?
I have even tried swapping libjlinkarm.so library shipped with Ozone with other versions:
- For Ozone 3.38c I replaced it with libjlinkarm.so.7.96.8 (older) and it is still slow.
- However for Ozone 3.34 I replaced it with libjlinkarm.so.8.10.12 (newer) and it is still fast!
So it looks for me more likely like a bug in recent Ozones.
Please, take a look on that and fix it if possible.
I know that for wide number of developers a lag of 1-3 seconds or more is not a problem, but the whole reason I am keeping buying JLink Plus for corporations is exactly to not wait that 1-3 seconds each time when I step over the code. 
Kind regards
Adam
PS: I would simply keep using version 3.34 and forget about 3.38c, but it has problems with updating 64 bit registers (for example version 3.34 can't set 64-bit PC correctly, leaving upper 32 bits with garbage), but for that I have also a small workaround in jlinkscript
void AfterResetTarget(void) {
JLINK_CPU_WriteReg(33, 0x80000);
}
(altough it just solves the problem of setting PC after reset, updating other registers from window is still buggy and leaves garbage in upper halfs, that's why I need to update my Ozone to newer one)
At my daily job I just want to open O-Zone, hit CTRL+ALT+B and set my breakpoint, without any use of mouse. Is that possible? If not, do you have plans to implement it?