How to configure new hardware in a nRF5340 sample project

[Mike527]

I have an nRF5340 DK board.  I have followed the online installation instructions and *believe* I have successfully installed (win 10) nRF Connect and Segger Embedded Studio (not to mention chocolatey, ninja, python, west, and all the rest).  I can build and flash from either west and SES.  I can execute any number of the sample programs. 

As a next step, I want to add new hardware interfaces to an example.  The example I chose the zephyr\samples\threads.  Following the "nRF Connect SDK Tutorial - Part 2" I created a local project and got it running.   To add a new HW interface I decided to add uart1 (I need use a uart to talk to another board) .  Here's some code.

static int uart_init(void)
{
  int err;
  struct uart_data_t *rx;

  uart1_device = device_get_binding(DT_LABEL(DT_NODELABEL(uart1)));
  if (!uart1_device) {
    printk("UART binding failed");
    return -ENXIO;
  }

My program always hits the "UART binding failed" case above.  This is almost certainly because I don't understand how all of this device tree stuff works and how to configure it.  Reading the "Part 2 Tutorial", I thought that maybe I could just add a local overlay file and put the following text in it:

&uart1 {
status = "okay";
current-speed = <115200>;
rx-pin = <44>;
tx-pin = <45>;
/delete-property/ rts-pin;
/delete-property/ cts-pin;
};

This didn't seem to work...nor did anything else I tried.  Maybe I need to edit the Kconfig.  Or the prj.conf.  Or dts file.  Or dtsi file. 

Nordic has walkthroughs for modifying sample applications - developer.nordicsemi.com/.../gs_modifying.html

...but these all seem to guide me right to the point where I'm ready to configure my example for new hardware interfaces...and go no further.

I've tried reading the documentation for the device tree and in any practical sense, I am still profoundly ignorant of how this all works.  I get that Nordic is doing this because it allows Zephyr to run on many different hardware platforms....which is cool.  It is also very confusing ...not so cool. 

Question:  What am I doing wrong?  Is there a better tutorial that shows real examples of how to change the device tree to enable/disable all the various HW interfaces on the DK?  

MikeB

[Simon]

I'm not sure why it didn't work for you. Could you try the following sample:

6862.hello_world.zip

Build and flash using the following commands:

west build -b nrf5340dk_nrf5340_cpuapp -d build_53
cd build_53 
west flash

Make sure the stuff you put in the overlay file is present in build_53/zephyr/zephyr.dts and that CONFIG_SERIAL=y in build_53/zephyr/.config

Best regards,

Simon

[Mike527]

Hello Simon,

Thanks for your response.

I tried your example and build instructions and the binding does indeed succeed.

I then tried to compare my example project with yours.  I was build my project is in SES instead of the command line (which probably doesn't make much difference).  I noticed that my project is built as non-secure.

I tried building your project as non-secure using:

west build -b nrf5340dk_nrf5340_cpuappns -d build_54

When I flash this it also failed to bind to the UART and generated:

*** Booting Zephyr OS build v2.4.99-ncs1 ***
Hello World! nrf5340dk_nrf5340_cpuapp
UART binding failed

For sanity I went back to and tried this all again.  I get this when build with "ns"

*** Booting Zephyr OS build v2.4.99-ncs1 ***
Flash regions Domain Permissions
00 01 0x00000 0x08000 Secure rwxl
02 63 0x08000 0x100000 Non-Secure rwxl

Non-secure callable region 0 placed in flash region 1 with size 32.

SRAM region Domain Permissions
00 03 0x00000 0x08000 Secure rwxl
04 63 0x08000 0x80000 Non-Secure rwxl

Peripheral Domain Status
00 NRF_P0 Non-Secure OK
01 NRF_CLOCK Non-Secure OK
02 NRF_RTC0 Non-Secure OK
03 NRF_RTC1 Non-Secure OK
04 NRF_NFCT Non-Secure OK
05 NRF_NVMC Non-Secure OK
06 NRF_UARTE1 Non-Secure OK
07 NRF_UARTE2 Secure SKIP
08 NRF_TWIM2 Non-Secure OK
09 NRF_SPIM3 Non-Secure OK
10 NRF_TIMER0 Non-Secure OK
11 NRF_TIMER1 Non-Secure OK
12 NRF_TIMER2 Non-Secure OK
13 NRF_SAADC Non-Secure OK
14 NRF_PWM0 Non-Secure OK
15 NRF_PWM1 Non-Secure OK
16 NRF_PWM2 Non-Secure OK
17 NRF_PWM3 Non-Secure OK
18 NRF_IPC Non-Secure OK
19 NRF_VMC Non-Secure OK
20 NRF_FPU Non-Secure OK
21 NRF_EGU1 Non-Secure OK
22 NRF_EGU2 Non-Secure OK
23 NRF_DPPIC Non-Secure OK
24 NRF_REGULATORS Non-Secure OK
25 NRF_DCNF Secure SKIP
26 NRF_CTRLAP Secure SKIP
27 NRF_SPIM4 Non-Secure OK
28 NRF_WDT0 Non-Secure OK
29 NRF_WDT1 Non-Secure OK
30 NRF_COMP Non-Secure OK
31 NRF_LPCOMP Non-Secure OK
32 NRF_PDM0 Non-Secure OK
33 NRF_I2S0 Non-Secure OK
34 NRF_QSPI Non-Secure OK
35 NRF_NFCT Non-Secure OK
36 NRF_MUTEX Non-Secure OK
37 NRF_QDEC0 Non-Secure OK
38 NRF_QDEC1 Non-Secure OK
39 NRF_USBD Non-Secure OK
40 NRF_USBREGULATOR Non-Secure OK
41 NRF_P1 Non-Secure OK
42 NRF_OSCILLATORS Non-Secure OK
43 NRF_RESET Non-Secure OK
44 NRF_GPIOTE1 Non-Secure OK

SPM: NS image at 0x8000
SPM: NS MSP at 0x20008758
SPM: NS reset vector at 0x96d1
Ê*** Booting Zephyr OS build v2.4.99-ncs1 ***
Hello World! nrf5340dk_nrf5340_cpuapp
UART binding failed*** Booting Zephyr OS build v2.4.99-ncs1 ***

I get this when built without "ns"
Hello World! nrf5340dk_nrf5340_cpuapp
Was able to get binding UART_1

I've been building my project as "ns"...I suppose I was thinking that I would ignore security and build as non-secure. Is this an incorrect assumption.  I would think this should work with or without the "ns" What's happening here?  

I'm not sure this is my original problem....but will pass on what I'm seeing so far.

Mike

[Mike527]

Hello Simon,

I can successfully build my project from west and process the overlay file.

Evidently the command:    west build -b nrf5340dk_nrf5340_cpuapp -d build_53

uses a default  "nrf5340dk_nrf5340_cpuapp.overlay" file.  

When building from my SES project, I was specifying the overlay file via the CMakeList.txt file:

# SPDX-License-Identifier: Apache-2.0

cmake_minimum_required(VERSION 3.13.1)
set(ThreadsEx_DTC_OVERLAY_FILE
${CMAKE_CURRENT_SOURCE_DIR}/ThreadsEx.overlay
)

find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
project(threads)

target_sources(app PRIVATE src/main.c)

The problem I was having was that 2.2.2 of the Part 2 Tutorial indicates to modify the CMakeList.txt

I substituted my project name for the <image_name>...but this wrong. 

How do I know what the <image_name> is?  (I'm sure this is a stupic question).

Mike

[Simon]

The code

set(<image_name>_DTC_OVERLAY_FILE
    ${CMAKE_CURRENT_SOURCE_DIR}/<name_overlay>.overlay
)

is used if you want to set an overlay file of a child image from the application. A child image can be mcuboot, or spm. E.g. if you build using nrf5340dk_nrf5340_cpuappns, the child image SPM will get included (zephyr/samples/threads/build/zephyr/merged.hex will contain both the application and SPM image).

If you then do 

set(spm_DTC_OVERLAY_FILE
    ${CMAKE_CURRENT_SOURCE_DIR}/whatever_name.overlay
)

This will be the same as adding it here: sdk-nrf/samples/spm at master · nrfconnect/sdk-nrf · GitHub. The stuff in the overlay file will then be applied to the SPM image.

If you just want to add an overlay file to your applicatiion, you can just add it like this: zephyr/samples/threads/nrf5340dk_nrf5340_cpuapp.overlay (no need to add anything to the CMakeLists.txt file). If you then build using the same name (nrf5340dk_nrf5340_cpuapp), the stuff in that overlay file will get applied to the application image. It is important to build with the same name as the name of the overlay file.

(I have not tested it, but I think it should work using the name whatever_name, for the SPM, since you explcitly set it).

Hope this clarifies stuff.

Best regards,

Simon

[Mike527]

Hey Simon,

OK...the above helped me better understand the overlay file.  I now understand that the default overlay is the nrf5340dk_nrf5340_cpuapp.overlay and have made some successful modification of sample programs.

Back to the subject of this thread:  I still need to configure 2 uarts (in addition to the console) on my dev kit.  I'm searching the sample code for examples and decided to build the ncs\v1.5.0\nrf\samples\peripheral\lpuart example.  I can successfully build this example and can see the uart pins toggle correctly when executing it. I then attempted to build this example to be interrupt driven. I thought I could do this by editing the file below and set the CONFIG_NRF_SM_LPUART_INT_DRIVEN value to yes (per the comment):

I'm building in SES (mainly because I'm using the debugger to set breakpoints) and reloaded the project and cleaned/rebuilt the solution.  I changed the above file and also the boards\nrf5340dk_nrf5340_cpuapp.conf file in the sample project.   I couldn't hit the ISR breakpoints...or the init driven initialization path.  (i.e. it doesn't look like the CONFIG_NRF_SM_LPUART_INT_DRIVEN symbol is being processed as enabled).

How do I configure this example to be interrupt driven?  Do I need to go into the Kconfig and change something?  

Mike

[Simon]

The sample is optimized for low power and not debugging. You need to uncomment the configs, as specified in nrf\samples\peripheral\lpuart\prj.conf. I think ucomment CONFIG_NO_OPTIZATION=y is the most crucial for debugging.

Try to apply this patch to an umodified NCS v1.5.0:

1004.lpuart_debug.patch

Best regards,

Simon