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) |
+------------------------------------------+

[Simon]

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

[stes]

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

[Simon]

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

[stes]

Hi Simon, thank you very much. I will try your board!

[stes]

Hi Simon, the board you sent did not work at a first try. Could you please let me know how you tested the board in your environment? Did you use a sample application for verification?

Have you tried your board folder as a out-of-tree board?

Regards

Stefan

[Simon]

stes said:

Could you please let me know how you tested the board in your environment? Did you use a sample application for verification?

Have you tried your board folder as a out-of-tree board?

I tested it with the blinky application I got from you. I did not place it out-of-tree, but from ncs/zephyr/boards/arm. I'll try to run it out-of-tree tomorrow.