[ABANDONED] Debugging issues in secure monitor mode

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [ABANDONED] 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. SEGGER J-Link GDB Server V6.16c Command Line Version
    2. JLinkARM.dll V6.16c (DLL compiled Jun 16 2017 18:16:10)
    3. -----GDB Server start settings-----
    4. GDBInit file: none
    5. GDB Server Listening port: 2331
    6. SWO raw output listening port: 2332
    7. Terminal I/O port: 2333
    8. Accept remote connection: yes
    9. Generate logfile: off
    10. Verify download: off
    11. Init regs on start: off
    12. Silent mode: off
    13. Single run mode: off
    14. Target connection timeout: 0 ms
    15. ------J-Link related settings------
    16. J-Link Host interface: USB
    17. J-Link script: none
    18. J-Link settings file: none
    19. ------Target related settings------
    20. Target device: ATSAMA5D27
    21. Target interface: JTAG
    22. Target interface speed: 1000kHz
    23. Target endian: little
    24. Connecting to J-Link...
    25. J-Link is connected.
    26. Firmware: J-Link V9 compiled Jun 16 2017 16:15:10
    27. Hardware: V9.40
    28. SAM-ICE found !
    29. S/N: 29425334
    30. OEM: SAM-ICE
    31. Feature(s): RDI, GDB
    32. Checking target voltage...
    33. Target voltage: 3.28 V
    34. Listening on TCP/IP port 2331
    35. Connecting to target...
    36. J-Link found 1 JTAG device, Total IRLen = 4
    37. JTAG ID: 0x5BA00477 (Cortex-A5)
    38. Connected to target
    39. Waiting for GDB connection...Connected to 127.0.0.1
    Display All


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

    Can you help with it?

    Kind regards,
    Isidoro
  • 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? segger.com/products/debug-prob…y/monitor-mode-debugging/

    You can evaluate it with our IDE Embedded Studio for free: segger.com/products/development-tools/embedded-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: segger.com/purchase/trade-in-program/

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • 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
  • 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).

    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.

    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:

    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
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • 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
  • 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
  • Hi Isiora,

    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.

    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.

    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.

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi Nino,
    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.

    Thanks for your kind support,
    Isidoro
  • Hi Nino,

    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.

    Kind regards,
    Isidoro
    Images
    • MonitorMode.JPG

      89.95 kB, 1,153×195, viewed 305 times
  • Hi Isiora,

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

    Yes.

    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.

    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.

    Best regards,
    Nino
    Images
    • Capture.PNG

      114.59 kB, 1,322×935, viewed 329 times
    Files
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi Nino,

    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.

    Kind Regards,
    Isidoro
  • Hi Nino,

    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?

    Kind regards,
    Isidoro
  • Hi Isiora,

    Keep in mind that this is *not* a support forum.
    Quote from our TOS:
    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.

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.