feather nrf9151 and HTTPS example

marjonz

I’ve followed the instructions in https://docs.circuitdojo.com/nrf9151-feather/using-vscode.html and need to build the “https” example. When generating the build, I run into the following error:

[81/140] Building C object secure_fw/partitions/crypto/mbedcrypto/nrf_security_src/core/nrf_oberon/CMakeFiles/oberon_psa_core.dir/66173395ffa9d10a661b85151fba34bd/library/pninja: error: mkdir(secure_fw/partitions/crypto/mbedcrypto/nrf_security_src/cy_src/core/nrf_oberon...r/C_/nrf_workspace/feather02/modules/crypto/oberon-psa-crypto/library/pninja: error: mkdir(secure_fw/partitions/crypto/mbedcrypto/nrf_security_src/core/nrf_oberon/CMakeFiles/oberon_psa_core.dir/C_/nrf_workspace/feather02/modules/crypto/oberon-psa-crypto/library): No such
 file or directory

ninja: build stopped: .
FAILED: modules/trusted-firmware-m/tfm-prefix/src/tfm-stamp/tfm-build tfm/bin/tfm_s.elf tfm/bin/tfm_s.bin tfm/bin/tfm_s.hex tfm/bin/tfm_s_signed.bin tfm/bin/tfm_s_ns_signed.bin tfm/api_ns/interface/li
b/s_veneers.o tfm/api_ns/interface/src/tfm_attest_api.c tfm/api_ns/interface/src/tfm_crypto_api.c tfm/api_ns/interface/src/tfm_fwu_api.c tfm/api_ns/interface/src/tfm_its_api.c tfm/api_ns/interface/src
/tfm_platform_api.c tfm/api_ns/interface/src/tfm_ps_api.c tfm/api_ns/interface/src/tfm_tz_psa_ns_api.c tfm/api_ns/interface/src/tfm_ioctl_core_ns_api.c C:/nrf_workspace/feather02/nfed/samples/https/bu
ild/circuitdojo_feather_nrf9151/https/modules/trusted-firmware-m/tfm-prefix/src/tfm-stamp/tfm-build C:/nrf_workspace/feather02/nfed/samples/https/build/circuitdojo_feather_nrf9151/https/tfm/bin/tfm_s.
elf C:/nrf_workspace/feather02/nfed/samples/https/build/circuitdojo_feather_nrf9151/https/tfm/bin/tfm_s.bin C:/nrf_workspace/feather02/nfed/samples/https/build/circuitdojo_feather_nrf9151/https/tfm/bi
n/tfm_s.hex C:/nrf_workspace/feather02/nfed/samples/https/build/circuitdojo_feather_nrf9151/https/tfm/bin/tfm_s_signed.bin C:/nrf_workspace/feather02/nfed/samples/https/build/circuitdojo_feather_nrf91
51/https/tfm/bin/tfm_s_ns_signed.bin C:/nrf_workspace/feather02/nfed/samples/https/build/circuitdojo_feather_nrf9151/https/tfm/api_ns/interface/lib/s_veneers.o C:/nrf_workspace/feather02/nfed/samples/
https/build/circuitdojo_feather_nrf9151/https/tfm/api_ns/interface/src/tfm_attest_api.c C:/nrf_workspace/feather02/nfed/samples/https/build/circuitdojo_feather_nrf9151/https/tfm/api_ns/interface/src/t
fm_crypto_api.c C:/nrf_workspace/feather02/nfed/samples/https/build/circuitdojo_feather_nrf9151/https/tfm/api_ns/interface/src/tfm_fwu_api.c C:/nrf_workspace/feather02/nfed/samples/https/build/circuit
dojo_feather_nrf9151/https/tfm/api_ns/interface/src/tfm_its_api.c C:/nrf_workspace/feather02/nfed/samples/https/build/circuitdojo_feather_nrf9151/https/tfm/api_ns/interface/src/tfm_platform_api.c C:/n
rf_workspace/feather02/nfed/samples/https/build/circuitdojo_feather_nrf9151/https/tfm/api_ns/interface/src/tfm_ps_api.c C:/nrf_workspace/feather02/nfed/samples/https/build/circuitdojo_feather_nrf9151/
https/tfm/api_ns/interface/src/tfm_tz_psa_ns_api.c C:/nrf_workspace/feather02/nfed/samples/https/build/circuitdojo_feather_nrf9151/https/tfm/api_ns/interface/src/tfm_ioctl_core_ns_api.c
cmd.exe /C "cd /D C:\nrf_workspace\feather02\nfed\samples\https\build\circuitdojo_feather_nrf9151\https\tfm && C:\ncs\toolchains\0b393f9e1b\opt\bin\cmake.exe --build . -j 1"
ninja: build stopped: subcommand failed.
[10/20] No configure step for 'mcuboot'
FAILED: _sysbuild/sysbuild/images/https-prefix/src/https-stamp/https-build C:/nrf_workspace/feather02/nfed/samples/https/build/circuitdojo_feather_nrf9151/_sysbuild/sysbuild/images/https-prefix/src/ht
tps-stamp/https-build
cmd.exe /C "cd /D C:\nrf_workspace\feather02\nfed\samples\https\build\circuitdojo_feather_nrf9151\https && C:\ncs\toolchains\0b393f9e1b\opt\bin\cmake.exe --build ."
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: 'C:\ncs\toolchains\0b393f9e1b\opt\bin\cmake.EXE' --build C:/nrf_workspace/feather02/nfed/samples/https/build/circuitdojo_feather_nrf9151

 *  The terminal process terminated with exit code: 1. 
 *  Terminal will be reused by tasks, press any key to close it. 

 *  Executing task: nRF Connect: Generate config circuitdojo_feather_nrf9151/nrf9151/ns for c:\nrf_workspace\feather02\nfed\samples\https

My settings are as follows:
Board target: circuitdojo_feather_nrf9151/ns
Base configuration files (Kconfig fragments): prj.conf
Extra Kconfig fragments: sysbuild/mcuboot.conf
Optimization level (size, speed, or debugging): Use project default
Build directory name: build/circuitdojo_feather_nrf9151
System build (sysbuild): Use sysbuild
… everything else is either empty or default

SDK: 3rd Party (nrf Connect SDK v3.0.1)*
Toolchain: nRF Connect SDK Toolchain v3.0.2 **(There was no 3.0.1)

What am I doing wrong or missing please?

jaredwolff

Looks like you’re missing part of the SDK. Did you run the west update command? That’s critical.

marjonz

jaredwolff I’ve nuked everything and starting again from scratch. Takes a while to update. I will update this thread with my progress (for the next guy that might come along).
One thing I noted after redoing the process is, this one should be considered a step, and not a side note (i.e. mandatory):
Note: you may have to open the folder you created during the west init before running the west update command. (next step)

EDIT: It finally built just now. Yeah, I missed that step from above that I mentioned, and the build didn’t really like it.
If I’m being picky, the path is also now different from the original, not sure if you refactored your project directories, but after following the steps, nrf9160-feather-examples-and-drivers/samples/blinky seems to be nfed/samples/blinky (or whichever example I was trying to build/use)

marjonz

The next bit of problem is probe-rs in WSL isn’t picking up the feather board:

> /mnt/c/nrf_workspace/project/nfed/samples/https/build$ probe-rs download --chip nRF9151_xxAA --binary-format hex ./merged.hex
 WARN probe_rs::probe::cmsisdap::tools: error listing devices with nusb: Os { code: 2, kind: NotFound, message: "No such file or directory" }
 WARN probe_rs::probe::stlink::tools: listing stlink devices failed: Os { code: 2, kind: NotFound, message: "No such file or directory" }
 WARN probe_rs::probe::list::linux: Make sure you have reloaded udev rules after setting everything up
 WARN probe_rs::probe::list::linux: Read more under https://probe.rs/docs/getting-started/probe-setup/
Error: No connected probes were found.

I following the link you gave to installing rustup, which I had to install an Ubuntu 24.04 in WSL to get running.

jaredwolff

If you navigate that build folder, it’s most likely deeper in. For instance in my setup it’s nfed/samples/test/build/circuitdojo_feather_nrf9151/merged.hex (Depends on how you configured it. I would do a quick folder search for merged.hex)

Also, make sure that when you set up the build, that you enabled sysbuild or else you won’t get a bootloader and a merged.hex

marjonz

jaredwolff It’s built, and if you look at the snippet, I’m trying to program the file (built) from that folder. The problem is WSL or probe-rs does not pick up the feather board. It also does not show up in Device Manager (I assume because it has nothing programmed in it) in Windows. But shouldn’t at least the CMSIS-DAP on the RPi chip enumerate itself so that it can flash the target?

jaredwolff

You’re getting a “file not found error”. I would address that first.

probe-rs list should show all available probes. Windows needs to pass through the USB device for this to work. (I don’t support or test this so you’re a bit on your own here) Otherwise you’ll need to install probe-rs on the windows side to program.

jaredwolff

Did you install the udev rules? https://probe.rs/docs/getting-started/probe-setup/

Not exactly sure how WSL works but those are required for the programmer to work on Linux

marjonz

jaredwolff Yep. Problem is device manager in Windows does not even enumerate it when plugged in. The lights on the board light up, blue and greed and red I think, but it does not show up as a USB device in Windows even. Is this board broken?

marjonz

For the next guy

Instructions in installing usbipd : https://learn.microsoft.com/en-us/windows/wsl/connect-usb
This will be needed to pass the CMSIS DAP device from Windows to the the WSL instance (in my case I used Ubuntu 24.04). After installing the usbipd msi installer,
1) Open a Windows PowerShell as an administrator
2) Run usbipd list. The device should show up, in my case it was 14-3 2e8a:000c CMSIS-DAP v2 Interface, USB Serial Device (COM5)
3) The run usbipd bind --force --busid 14-3 (where the busid is the one listed in the list for the CMSIS DAP device). Keep this shell open.
4) Open another Windows PowerShell (if you don’t have wsl already), Run wsl
5) In the first Windows PowerShell, run usbipd attach --wsl --busid 14-3 to pass the device through to the WSL running instance.
It should show something similar to:

PS C:\WINDOWS\system32> usbipd attach –wsl –busid 14-3
usbipd: info: Using WSL distribution ‘Ubuntu-24.04’ to attach; the device will be available in all WSL 2 distributions.
usbipd: info: Loading vhci_hcd module.
usbipd: info: Detected networking mode ‘nat’.
usbipd: info: Using IP address 172.18.16.1 to reach the host.

6) Now check in the WSL PowerShell: probe-rs list.

marjonz

So looks like the “https” example posts “a value” (something) of type cJSON? Am I able to see the data in the server, given the path? I spun up an apache server with the corresponding path accessible externally. I’m not quite sure what to expect when the program runs? I kind of expect a file being created on the given path, is this correct?

jaredwolff

It encodes JSON. (cJSON is the name of the library)

Should be something like

{
"do_something": false
}

Make sure you have the appropriate path set with CONFIG_CLOUD_PUBLISH_PATH and the host set with CONFIG_CLOUD_HOSTNAME. The example is using the ACME certs (that works with Lets Encrypt). If you’re attempting to publish to another host you will have to set the root cert accordingly.

marjonz

jaredwolff so I’ve updated the CONFIG_CLOUD_PUBLISH_PATH to exist in my server’s /var/www/html/api/v1/yourpath, and changed the CONFIG_CLOUD_HOSTNAME with public DDNS name of my current IP (and punched through my firewall and assigned the public port, which I’ve assigned to CONFIG_CLOUD_PORT, to my internal server’s port 443). Everything in my server seems accessible via browser. I’m confused as to, how do I know if the example is working correctly or not? Will it create a file on that given CONFIG_CLOUD_PUBLISH_PATH?

marjonz

Correct me if I’m wrong here, so:
1) I need to install Node.js in my server, to
2) Install the “json-server” application to run a json server
3) Create a database file for the json server that matches the endpoints specified in the example https project
Is this correct?