• State Not Answered
  • Replies 10 replies
  • Subscribers 63 subscribers
  • Views 1695 views
  • Users 0 members are here
Attachments (4) Download All
Nordic Case Info
  • Case ID: 265484
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nrf9106 non secure application - unable to debug with JLink

stes

Dear Nordic DevZone team,

 I have spent some frustrating hours trying to find the difference between configuring my tiny application with nrf9160dk_nrf9160ns or my custom board stamp_nrf9160ns:

The application only switches the state of on LED every second. It works fine when running it as a secure application.

When I configure it as a non-secure application, I am not able to debug it using JLink. Below is the difference between the boards nrf9160dk_nrf9160ns and stamp_nrf9160ns. The basic assignment of flash memory looks the same, but the PC is very different... Could you please give me a hint where to look for the difference or is there anything the the nrf9160dk_nrf9160ns  pulls in which is hidden somewhere in the nrf Connect SDK?

Please let me know if you need any further information!

GOOD CASE:

west build -b nrf9160dk_nrf9160ns

0x1c77c <main+68>

[191/196] Linking C executable zephyr/zephyr_prebuilt.elf
Memory region Used Size Region Size %age Used
FLASH: 32256 B 48 KB 65.62%
SRAM: 5552 B 64 KB 8.47%
IDT_LIST: 40 B 2 KB 1.95%
[196/196] Linking C executable zephyr/zephyr.elf
[18/159] Performing build step for 'mcuboot_subimage'
[1/167] Preparing syscall dependency handling

[162/167] Linking C executable zephyr/zephyr_prebuilt.elf
Memory region Used Size Region Size %age Used
FLASH: 37220 B 48 KB 75.72%
SRAM: 17960 B 192 KB 9.13%
IDT_LIST: 88 B 2 KB 4.30%
[167/167] Linking C executable zephyr/zephyr.elf
[146/159] Linking C executable zephyr/zephyr_prebuilt.elf
Memory region Used Size Region Size %age Used
FLASH: 15204 B 441856 B 3.44%
SRAM: 6088 B 192 KB 3.10%
IDT_LIST: 56 B 2 KB 2.73%
[159/159] Generating zephyr/merged.hex

ser@ubuntu:~/test/application$ python ../nrf/scripts/partition_manager_report.py --input build/partitions.yml
(0x100000 - 1024kB):
+------------------------------------------+
| 0x0: mcuboot (0xc000) |
| 0xc000: EMPTY_0 (0x4000) |
+---0x10000: mcuboot_primary (0x78000)-----+
| 0x10000: mcuboot_pad (0x200) |
+---0x10200: mcuboot_primary_app (0x77e00)-+
| 0x10200: spm (0xc000) |
| 0x1c200: app (0x6be00) |
| 0x88000: mcuboot_secondary (0x78000) |
+------------------------------------------+

NOT SO GOOD CASE:

west build -b stamp_nrf9160ns
0x28a8
PC: 0x7e60

-- west build: building application
[1/159] Preparing syscall dependency handling

[10/159] Performing build step for 'spm_subimage'
[2/195] Preparing syscall dependency handling

[190/195] Linking C executable zephyr/zephyr_prebuilt.elf
Memory region Used Size Region Size %age Used
FLASH: 32256 B 48 KB 65.62%
SRAM: 5520 B 64 KB 8.42%
IDT_LIST: 40 B 2 KB 1.95%
[195/195] Linking C executable zephyr/zephyr.elf
[18/159] Performing build step for 'mcuboot_subimage'
[1/167] Preparing syscall dependency handling

[162/167] Linking C executable zephyr/zephyr_prebuilt.elf
Memory region Used Size Region Size %age Used
FLASH: 37068 B 48 KB 75.42%
SRAM: 17872 B 192 KB 9.09%
IDT_LIST: 72 B 2 KB 3.52%
[167/167] Linking C executable zephyr/zephyr.elf
[146/159] Linking C executable zephyr/zephyr_prebuilt.elf
Memory region Used Size Region Size %age Used
FLASH: 14992 B 441856 B 3.39%
SRAM: 6048 B 192 KB 3.08%
IDT_LIST: 56 B 2 KB 2.73%
[159/159] Generating zephyr/merged.hex


user@ubuntu:~/test/application$ python ../nrf/scripts/partition_manager_report.py --input build/partitions.yml
(0x100000 - 1024kB):
+------------------------------------------+
| 0x0: mcuboot (0xc000) |
| 0xc000: EMPTY_0 (0x4000) |
+---0x10000: mcuboot_primary (0x78000)-----+
| 0x10000: mcuboot_pad (0x200) |
+---0x10200: mcuboot_primary_app (0x77e00)-+
| 0x10200: spm (0xc000) |
| 0x1c200: app (0x6be00) |
| 0x88000: mcuboot_secondary (0x78000) |
+------------------------------------------+

  • 0

    Sorry, one remark: The hex-number below the west build lines are the content of the Program Counter after the merged.hex has been loaded. The NOT SO GOOD part has the initial PC and the one I end up with when I tried to run the program... It will remain at 0x7e60, even for single-stepping

  • 0

    Would you be able to upload the board folder stamp_nrf9160ns in zipped format? Then I can test it myself and try to reproduce the issue.

    Best regards,

    Simon

  • 0 in reply to Simon

    stamp.zip2538.application.zip

    Hi Simon, please find attached the stamp_nrf9160_support which contains my board files. It would be great if you could show me what I did wrong in this setup.

    Let me quickly explain the overall setup of my project: I have a west repository which contains my application (application.zip). This west repository fetches the stamp_nrf9160_support repository and the Nordic sdk-nrf.

    In the stamp_build.sh you will find the command line for the secure and non-secure application. When I build the secure image, I flash the zephyr/zephyr.elf file and I can see the application blink. When I use the debugger from vscode, the debugger stops after uploading the file, I can set breakpoints and debug the application.

    When I choose the non-secure for debugging (zephyr/merged.hex), the application is build and loaded to the board. But I do not see the application source code after uploading the file and I am neither able to set breakpoints nor to debug the application...

    Do you think it is possible to use the sdk-nrf like this? Being a sub-part of a project?

    Best

    Stefan

  • 0 in reply to stes

    Thanks, I'll take a look at it.

    I tested your board and was not able to make it work, neither with the secure nor non-secure version. I tested it on an nRF9160 DK I created a new version of the board stamp_nrf9160 that worked fine. I've not gotten time yet to figure out exactly what's causing your board folder to fail.

    Could you test the board I made and see if you're able to run the secure and non-secure versions of it. If you are able to do that, could you slowly, step by step, modify it to look the same as your stamp_nrf9160 board. For every change you make, test it for both the secure and nonsecure version and see if it still works. Then you will find out exactly what is causing it to fail.

    2337.stamp_nrf9160.zip

    If you're not able to figure it out, please get back to me and I'll take a closer look at it.

    Best regards,

    Simon

Related