Monday, December 11th 2017, 4:54am UTC+1

You are not logged in.

  • Login
  • Register

isiora

Beginner

Date of registration: Dec 6th 2017

Posts: 4

1

Wednesday, December 6th 2017, 6:06pm

Debugging issues in secure monitor mode

Hi,

I'm working on a ATSAMA5D2 platform and I have problems in debugging code that runs in secure monitor CPU mode. Stepping in the code I received the following message on JLinkGDBServer console:


ERROR: _RegNumber2RegIndex: Illegal CPU Mode
Reading all registers
WARNING: Register with index 74 could not be read. Reason: CPSR indicates a non-valid CPU mode.
WARNING: Register with index 75 could not be read. Reason: CPSR indicates a non-valid CPU mode.
WARNING: Register with index 76 could not be read. Reason: CPSR indicates a non-valid CPU mode.
WARNING: Register with index 77 could not be read. Reason: CPSR indicates a non-valid CPU mode.
WARNING: Register with index 78 could not be read. Reason: CPSR indicates a non-valid CPU mode.
WARNING: Register with index 79 could not be read. Reason: CPSR indicates a non-valid CPU mode.
WARNING: Register with index 80 could not be read. Reason: CPSR indicates a non-valid CPU mode.


Since gdb should be unaware of the CPU mode, I think that the issue is related to JLinkGDBServer.

For your info, below I report the startup message:


Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
SEGGER J-Link GDB Server V6.16c Command Line Version

JLinkARM.dll V6.16c (DLL compiled Jun 16 2017 18:16:10)

-----GDB Server start settings-----
GDBInit file: none
GDB Server Listening port: 2331
SWO raw output listening port: 2332
Terminal I/O port: 2333
Accept remote connection: yes
Generate logfile: off
Verify download: off
Init regs on start: off
Silent mode: off
Single run mode: off
Target connection timeout: 0 ms
------J-Link related settings------
J-Link Host interface: USB
J-Link script: none
J-Link settings file: none
------Target related settings------
Target device: ATSAMA5D27
Target interface: JTAG
Target interface speed: 1000kHz
Target endian: little

Connecting to J-Link...
J-Link is connected.
Firmware: J-Link V9 compiled Jun 16 2017 16:15:10
Hardware: V9.40
SAM-ICE found !
S/N: 29425334
OEM: SAM-ICE
Feature(s): RDI, GDB
Checking target voltage...
Target voltage: 3.28 V
Listening on TCP/IP port 2331
Connecting to target...
J-Link found 1 JTAG device, Total IRLen = 4
JTAG ID: 0x5BA00477 (Cortex-A5)
Connected to target
Waiting for GDB connection...Connected to 127.0.0.1


I have also tried the v6.22a, but the results were the same.

Can you help with it?

Kind regards,
Isidoro

SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 430

2

Thursday, December 7th 2017, 10:05am

Hello Isidoro,

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.

Are you using an eval board or custom hardware?
Did you use the monitor mode example from our website as base? https://www.segger.com/products/debug-pr…mode-debugging/

You can evaluate it with our IDE Embedded Studio for free: https://www.segger.com/products/developm…mbedded-studio/

Should you want to upgrade the SAM-ICE to a original J-Link we suggest using our trade-in program with your SAM-ICE device: https://www.segger.com/purchase/trade-in-program/

Best regards,
Nino

isiora

Beginner

Date of registration: Dec 6th 2017

Posts: 4

3

Thursday, December 7th 2017, 3:29pm

Hi Nino,

thanks for your reply.

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
Thank you and kind regards,
Isidoro

SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 430

4

Thursday, December 7th 2017, 3:56pm

Hi Isidoro,

Sorry for this misunderstanding. I just read monitor mode and not *secure* monitor mode (ARM and their naming conventions ^^ ).

It looks that somehow the CPSR register either can't be read or is interpreted wrongly as usually the J-Link also "does not care" on what mode the CPU is in (as long as it is a valid one).

Quoted

The platform ATSAMA5D2x (I'm using the SAMA5D2 Xplained Ultra Evaluation Kit)


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 :whistling:

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


Understandable and we hope to be able to persuade you :thumbsup:

Best regards,
Nino

isiora

Beginner

Date of registration: Dec 6th 2017

Posts: 4

5

Thursday, December 7th 2017, 10:34pm

Dear Nino,

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.


Kind regards,
Isidoro

isiora

Beginner

Date of registration: Dec 6th 2017

Posts: 4

6

Friday, December 8th 2017, 11:22pm

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.

Kind regards,
Isidoro