Thank you for your inquiry.
Such an issue is not known to us.
You seem to be using a SAM-ICE which is not supported through SEGGER but directly by ATMEL.
So unfortunately I am not allowed to spend much time with this case.

You're confusing the monitor mode debugging with the secure monitor cpu mode. It's quite a common mistake, so do not worry.
The platform ATSAMA5D2x (I'm using the SAMA5D2 Xplained Ultra Evaluation Kit) uses an ARM Cortex-A5 that implements the ARM security extensions.
The secure monitor mode is an ARM cpu mode that is entered in, for example, via an explicit smc call. There are other ways to enter the secure monitor mode, but we don't need to go into this.
So, please, evaluate my inquiry once again.

Regarding the product, please consider that:

I have successfully registered my SAM-iCE on your site. I have received an email that confirms that registration of the product was Ok (SN 29425334): "The authenticity of you J-Link has been confirmed. Registration is now completed."

I also updated the firmware of the unit and I got the update from your site. So I don't think that sam-ice and j-link be so different.

I can consider to upgrade my j-link to an other model only if I can be sure that this problem is not there

Quoted

Fantastic, we have a couple of this available so we should be able to reproduce your setup.
Could you provide us with an example project where this issue is reproducible?
What GDB Client were you using in your setup?
What is the OS of your host PC where the setup is running at?

Once we can reproduce the issue here we will see if the behaviour can be improved/fixed.

Quoted

I also updated the firmware of the unit and I got the update from your site. So I don't think that sam-ice and j-link be so different.

It is less of an question of "can we offer support?" but more a "are we legally allowed to offer support?" in this case.
So please understand that we are obliged to draw a line eventually.
But looking to improve our software like the GDBServer is a completely other story

Quoted

I can consider to upgrade my j-link to an other model only if I can be sure that this problem is not there

I agree with you.
However, I will send you a simple asm file able to show you the problem. Let me find the time to prepare it .
The GDBServer client is "GNU gdb (Atmel build: 487) 7.10.1.20160210-cvs".
I have also tried the ARM toolchain including the client "GNU gdb (GNU Tools for ARM Embedded Processors 6-2017-q2-update) 7.12.1.20170417-git". Same results.
The host and target configuration parameters are: --host=x86_64-linux-gnu --target=arm-none-eabi.
The host OS is Ubuntu 16.04.3 LTS 64-bit.

Someone in my company should be have also a J-link not OEM SAM-ICE, if I'm right; so the legal issue about the support could be gone, in any case.

example project reproducing the issue

Hi Nino,

attached (jlink.zip) you find an example project that may help you to investigate the issue.
At line 98 of monitor.S you find the smc call. Proceeding step by step, and after executing it, the cpu enters in secure monitor mode and jumps via monitor vectors table to sm_call entry.
There you find a simple "mov r1, lr". As soon as it enters the secure monitor mode, you can observe the messages from GDBServer telling that CPU mode is invalid.
Moreover, executing the "mov r1, lr", you should able to see a strange and incorrect result: in r1 there is the value of r0, and not the value of lr. This doesn't happen if you not proceed step by step, but set a breakpoint in the "subs pc, lr, #0" line, showing a faulty action of the debugger.

Thank you for providing the project.
First i tried to reproduce the behaviour with Embedded Studio under windows loading your assembler file in a example project.
But there was no error showing that a register could not be read.

Quoted

Moreover, executing the "mov r1, lr", you should able to see a strange and incorrect result: in r1 there is the value of r0, and not the value of lr.

This was reproducible for me in my setup. You can avoid this if you turn off instruction set simulation.
For this you can use the exec command SetAllowSimulation. More information can be found in the J-Link user manual.
If you turn it off the values will always be as expected.

Quoted

This doesn't happen if you not proceed step by step, but set a breakpoint in the "subs pc, lr, #0" line, showing a faulty action of the debugger.

What faulty action are you seeing with your setup exactly? What result are you expecting and what are you getting?

Does disabling instruction set simulation solve the issue?
In the meantime I will try to copy your setup completely to see if the issue is only GDBServer related.

Quoted

What faulty action are you seeing with your setup exactly? What result are you expecting and what are you getting?

I'm again referring to the 'mov' instruction. I will try as soon as possibile your suggestion.
I see the error in the JLinkGDBServer output in eclipse.
So, are you able to enter secure monitor mode and stop, with a breakpoint, at "subs pc, lr, #0"?
In your setup, are you able to see in the register list 'spsr_mon'? I have never seen it.

I confirm you that using a jlink script file to set SetAllowSimulation to 0, the register r1 shows correctly after the 'mov' statement.
But I continue to be unable to read correctly the registers r8 and the following ones.
I attached a snippet of two windows (JLinkGDBSever and Eclipse) to show you exactly what I see.
In the code I changed 'mov r1,lr' in 'mov r8,lr' to put into play the register r8.
Let me to remember you that the error messages show up only after the cpu has changed mode via smc.

Quoted

So, are you able to enter secure monitor mode and stop, with a breakpoint, at "subs pc, lr, #0"?

Yes.

Quoted

In your setup, are you able to see in the register list 'spsr_mon'? I have never seen it.

The Register is available, screenshot from Embedded Studio is attached.

Attached is also the project I used so you can reproduce it on your machine.
Embedded Studio also works under Linux so you can test it there as well.

Quoted

Let me to remember you that the error messages show up only after the cpu has changed mode via smc.

Unfortunately that error messages were not reproducible on our side.
We looked into recreating your setup but this would exceed the time effort of regular forum support.
So please understand that we can't investigate this behaviour further.

thank you very much. I truly appreciated your support and effort.
I will try your project as soon as possible and I will inform you of any progress.
I also will test with JLink Pro, to see if any difference exists.

your setup using Embedded Studio works on my desk too (with SAM-ICE).
But it seems to me that ES doesn't use JLinkGDBServer. If so, the two setups are incomparable.
What can we do in order to obtain further support from you?

Quoted

This forum is not monitored by SEGGER technical support personnel. Do not expect to receive technical support via this forum.

If you do not agree with this do not use the forum for support requests.

Unfortunately we can't spend more time trying to find a reproduction scenario where the issue is reproducible.
For us to take another look at this we would need a reproduction scenario that can be setup within 5 minutes as this is a niche feature which seems to be working when using Embedded Studio.
It is still not clear if this issue is J-Link related at all.
The reproduction scenario would be best if its on a windows system so we can find the source of the issue faster, if there is any from our side.
Alternatively you could send us a Linux VM for VMware with a fixed setup where this is reproducible out of the box.