I am currently running into a build issue, have not dug into it quite yet, but I think it is related to my use of UART2.
This is from v1.4.99-dev1 of what was downloaded with the nRF connect application.
Glad to see the support for the board is already included.

I am attempting to build nrf/applications/serial_lte_modem, attaching the two files I dropped in to customize the build for the use case, to reroute UART2 and enable the MCU bootloader.

The build failure happens when I change these below options.

#
# SLM-specific configurations
#
CONFIG_SLM_LOG_LEVEL_INF=y
# Enable GPIO wakeup if sleep is expected
#CONFIG_SLM_GPIO_WAKEUP=y
# Use UART_0 (when working with PC terminal)
#CONFIG_UART_0_NRF_HW_ASYNC_TIMER=2
# Use UART_2 (when working with external MCU)
CONFIG_SLM_CONNECT_UART_2=y
CONFIG_UART_2_NRF_HW_ASYNC_TIMER=2

hm… this drag drop does not seem to work for uploading…
Basically make those changes to the prj.conf file and attempt to build with this command.

west build -b circuitdojo_feather_nrf9160ns -p

    aldras The first thing I need to do is route the UART signals to the correct GPIO pins, and for that I will need to know which ones they are, a diagram like above (sorry if it exists and I missed it) would be really great!

    You have a great point here. I just haven’t gotten to creating one. 😅 I always look at the schematic as they’re in the same order.

    aldras you may have to delete your build folder if you’re migrating your code from an earlier NCS version. Also you may need to update/create an .overlay for your project.

      Ah I was going to edit that post, while I was editing it to add the error output I think your post disabled the edit feature and I encountered an “you don’t have permission” when I hit the “save changes” button…

      Is there some rule setup not able to edit posts after someone replys?

      Anyway, here is the output… I think this is related to the DTS.

      In file included from /opt/nordic/ncs/v1.4.99-dev1/zephyr/include/arch/arm/aarch32/arch.h:20,
                       from /opt/nordic/ncs/v1.4.99-dev1/zephyr/include/arch/cpu.h:19,
                       from /opt/nordic/ncs/v1.4.99-dev1/zephyr/include/kernel_includes.h:38,
                       from /opt/nordic/ncs/v1.4.99-dev1/zephyr/include/kernel.h:17,
                       from /opt/nordic/ncs/v1.4.99-dev1/zephyr/include/init.h:11,
                       from /opt/nordic/ncs/v1.4.99-dev1/zephyr/include/device.h:22,
                       from /opt/nordic/ncs/v1.4.99-dev1/zephyr/include/drivers/uart.h:26,
                       from /opt/nordic/ncs/v1.4.99-dev1/zephyr/drivers/serial/uart_nrfx_uarte.c:11:
      zephyr/include/generated/devicetree_unfixed.h:3596:38: error: 'DT_N_S_soc_S_peripheral_40000000_S_uart_a000_P_current_speed' undeclared here (not in a function); did you mean 'DT_N_S_soc_S_peripheral_40000000_S_uart_9000_P_current_speed'?
       3596 | #define DT_N_NODELABEL_uart2         DT_N_S_soc_S_peripheral_40000000_S_uart_a000
            |                                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

        Yeah I blew away the entire build folder with rm -rf build.
        The issue I think is there is something missing in the device tree…

          This does build without issues on the following boards, so there must be something different in the board configuration…

          west build -b nrf9160dk_nrf9160ns
          west build -b actinius_icarus_ns

            I have added a circuitdojo_feather_nrf9160_ns.overlay file with the following contents into the serial_lte_modem folder as well, does not appear to help. I will try to dig into the board definition files, but I am not very familiar with working with DTS and such.

            &uart1 {
            status = “okay”;

            current-speed = <115200>;
            tx-pin = <10>;
            rx-pin = <11>;

            };

            &uart2 {
            compatible = “nordic,nrf-uarte”;
            current-speed = <921600>;
            // for CTS RTS support
            /*
            tx-pin = <4>;
            rx-pin = <2>;
            rts-pin = <3>;
            cts-pin = <0>;
            hw-flow-control;
            */

            // without CTS RTS support
            tx-pin = <7>;
            rx-pin = <5>;	

            };

              Ok, I resolved the build issue, due to the odd naming of the “actinius_icarus_ns.overlay” I followed this convention and attempted to name the overlay for this board “circuitdojo_feather_nrf9160_ns.overlay” which is NOT correct, the correct name is “circuitdojo_feather_nrf9160ns.overlay”

              The really important missing part was the UART “current-speed” definition, that was missing and was not included in the DTS when it was generated. This causes build errors later on when it is not found in the DTS file.

              If this is above anyone’s head, don’t worry, the important thing is to remember to include the UART “current-speed” in the overlay file, an example is below. To use hardware flow control with RTS CTS, just uncomment and modify the pins to match your needs.

              &uart2 {
              	compatible = "nordic,nrf-uarte";
              	current-speed = <921600>;
              	// for CTS  RTS support
              	/*
              	tx-pin = <4>;
              	rx-pin = <2>;
              	rts-pin = <3>;
              	cts-pin = <0>;
              	hw-flow-control;
              	*/
              
              	// without CTS RTS support
              	tx-pin = <7>;
              	rx-pin = <5>;	
              };

              The important thing is to make sure you get the overlay filename right. You can actually see that your overlay is used in the build results as it flys across the screen before your eyes, look for the line “Found devicetree overlay” and it should display your overlay file, it needs to match the board name with a “ns.overlay” appended to the end of it.

              west build -b circuitdojo_feather_nrf9160ns -p
              -- west build: generating a build system
              Including boilerplate (Zephyr base): /opt/nordic/ncs/v1.4.99-dev1/zephyr/cmake/app/boilerplate.cmake
              -- Application: /opt/nordic/ncs/v1.4.99-dev1/nrf/applications/serial_lte_modem_circuitdojo_feather_nrf9160
              -- Using NCS Toolchain 1.4.0 for building. (/opt/nordic/ncs/v1.4.99-dev1/toolchain/cmake)
              -- Zephyr version: 2.4.99 (/opt/nordic/ncs/v1.4.99-dev1/zephyr)
              -- Found Python3: /opt/nordic/ncs/v1.4.99-dev1/toolchain/bin/python3 (found suitable exact version "3.8.2") found components:  Interpreter 
              -- Found west (found suitable version "0.7.2", minimum required is "0.7.1")
              -- Board: circuitdojo_feather_nrf9160ns
              -- Cache files will be written to: /Users/drassala/Library/Caches/zephyr
              -- Found dtc: /opt/nordic/ncs/v1.4.99-dev1/toolchain/bin/dtc (found suitable version "1.4.7", minimum required is "1.4.6")
              -- Found toolchain: gnuarmemb (/opt/nordic/ncs/v1.4.99-dev1/toolchain)
              -- Found BOARD.dts: /opt/nordic/ncs/v1.4.99-dev1/zephyr/boards/arm/circuitdojo_feather_nrf9160/circuitdojo_feather_nrf9160ns.dts
              -- Found devicetree overlay: /opt/nordic/ncs/v1.4.99-dev1/nrf/applications/serial_lte_modem_circuitdojo_feather_nrf9160/circuitdojo_feather_nrf9160ns.overlay
              -- Generated zephyr.dts: /opt/nordic/ncs/v1.4.99-dev1/nrf/applications/serial_lte_modem_circuitdojo_feather_nrf9160/build/zephyr/zephyr.dts
              -- Generated devicetree_unfixed.h: /opt/nordic/ncs/v1.4.99-dev1/nrf/applications/serial_lte_modem_circuitdojo_feather_nrf9160/build/zephyr/include/generated/devicetree_unfixed.h

                I am now running into a bootloader issue, I am attempting to upload the compiled serial_lte_modem with the below commands, and I don’t think the bootloader is working, or something is not enumerating correctly.

                I am going to make a seperate thread for this issue, not to duplicate this thread, but trying to keep individual issues in seperate threads to make searching easer, please see this thread. That thread is here…

                https://community.jaredwolff.com/d/66-issue-entering-bootloader-in-new-v2-board

                  aldras The important thing is to make sure you get the overlay filename right.

                  This was a good catch. The Zephyr team preferred it to be with no underscore as all the nRF9160 boards are the same way. The Icaraus is the odd man out. I guess they didn’t check it thoroughly before merging.

                  aldras I am going to make a seperate thread for this issue, not to duplicate this thread, but trying to keep individual issues in seperate threads to make searching easer, please see this thread. That thread is here…

                  Let me know if the suggestions I sent work. Chat more on that thread.

                    jaredwolff Yes, it was a driver issue, thank you for pointing me in the correct direction! Maybe add one more BOLD (*) point next to the “newtmgr -c serial image upload build/zephyr/app_update.bin”" command for people like me who skip ahead and often miss simple things!

                      @aldras Where in the documentation were you referring to this? There are a few places with this command.

                      aldras ! Maybe add one more BOLD (*) point next to the “newtmgr -c serial image upload build/zephyr/app_update.bin”"

                        @aldras by the way, I tried uploading a picture and appears to be working ok. It will show up as Markdown when you do.

                        Working on other files. Stay tuned.

                        (Update: uploading files works. Best to upload a .zip file if you have multiple text files or source code. Or, for source code, simply use the markdown for source code.)

                          jaredwolff
                          Ah just noticed the post on the thread, referring to this page.
                          https://docs.jaredwolff.com/nrf9160-programming-and-debugging.html

                          Maybe a * near the MacOS command
                          “newtmgr conn add serial type=serial connstring=‘dev=/dev/tty.SLAB_USBtoUART,baud=1000000’”
                          to recommend installing the drivers if the tty.SLAB_USBtoUART is not showing up, or a reminder to do so, along with some kind of note that even if one tty.USB device is showing up the drivers will need to be installed since two VCPs should be enumerating, or at least that is how it went in my case. The installation will require a restart too.

                            aldras I’ve updated that page with a note underneath. I actually mentioned the issue in the Mac setup section. So I just copied that over. Thanks!

                              Reporting back on progress here, am beginning to use the Feather nRF9160 in the development platform so I went to program it and tried many times with the bootloader.

                              Not knowing if it was a pin routing issue or some other issue I tried quite a few different pin mapping combinations (for UART2) but could not get any response after loading with the bootloader.

                              Of course I didn’t notice the fine print “IMPORTANT: updates above 192kB will not work with the current version of the bootloader. Examples like the asset_tracker require a programmer.” on the page
                              https://docs.jaredwolff.com/nrf9160-programming-and-debugging.html

                              It appears the program I am attempting to load, serial lte modem, is about 202Kb in side, just above that limit. Pulled out the nRF9160DK and loaded it with nrfjprog, but in doing so I wiped out the bootloader (oops). I will try to recover it later, but the good news is I got the pin layout fixed for UART2 so I would like to report some things about it.

                              I am using the following two pins for UART2 communication and here is the routing that I discovered.
                              The GPIO numbers appear to refer to the actual GPIO numbers on the MCU, so P0.03 is 3, etc, and it appears to be a little different than the silkscreen numbers.

                              Here is the pin mapping from the overlay file (circuitdojo_feather_nrf9160ns.overlay):

                              &uart1 {
                              	status = "okay";
                              
                              	current-speed = <115200>;
                              	tx-pin = <0>;
                              	rx-pin = <2>;
                              };
                              
                              &uart2 {
                              	compatible = "nordic,nrf-uarte";
                              	//current-speed = <921600>;
                              	current-speed = <115200>;
                              	// for CTS  RTS support
                              	/*
                              	tx-pin = <4>;
                              	rx-pin = <2>;
                              	rts-pin = <3>;
                              	cts-pin = <0>;
                              	hw-flow-control;
                              	*/
                              
                              	// without CTS RTS support
                              	tx-pin = <3>; // Feather nRF9160 D7 (as marked on the silkscreen)
                              	rx-pin = <1>; // Feather nRF9160 D5 (as marked on the silkscreen)
                              };

                              This appears to follow the Actinius Icarus, however I never was able to find the schematics for the Icarus. Something that I would like to have if anyone knows where to get them. I can’t find it on their website, is it buried?

                              Anyway, this time around I ran into those two issues, one with the pin mapping, and the other with the bootloader loading. It appeared to load correctly but did not do anything when reset. For reference here are the two commands I used, one for the bootlaoder, the other for nrfjprog, for reference.

                              I am also going to attach the two bin files here for you to look at. You should receive serial output on the two pins D5 and D7 upon powerup/reset, nothing will come through the USB connection. Baud rate is 115200.

                              /opt/nordic/newtmgr conn add serial type=serial connstring=‘dev=/dev/tty.SLAB_USBtoUART,baud=1000000’
                              /opt/nordic/newtmgr -c serial image upload build/zephyr/app_update.bin

                              /usr/local/bin/nrfjprog -f NRF91 –program build/zephyr/merged.hex –sectorerase

                              The compiled project, and all related is here, nRF SDK version 1.4.99-dev1.
                              https://www.drassal.net/filestore/serial_lte_modem_circuitdojo_feather_nrf9160_20210128.zip
                              (Still can’t get a file to upload, dragging it into here just copies the text of the filename it seems)
                              If you would like to look, see if you can get the file build/zephyr/app_update.bin to work with the bootloader. Confirmed mixed.bin works with nrfjprog. No rush on this though, since I have a work around now with nrfjprog.

                              By the way, I really do like this antenna, nice find!
                              Need to do some more testing but this flexible LTE antenna is really neat.

                              Next bump I ran into.
                              I wanted to power the nRF9160 from one of the header pins, I don’t want to push 3V3 through the 3V3 pin since I am not sure the Feather M0 that I am using can handle the load of the nRF9160. What I wanted to do is tie the two “USB” pins together, and I noticed there is a diode that prevents powering FROM the USB pin, from the direction of the diode it only OUTPUTS the USB power from the nRF9160’s USB connector to the USB pin on the header.

                              Note, USB pin refers to JP2 pin 3, 5V0 tagged on the schematic.

                              What I resorted to is using a micro USB connector and plugging it in, this connector is connected to the “USB” pins on the Feather M0 to power the Feather nRF9150’s 3V3 regulator.

                              Not sure if it is a good idea to remove that diode, or maybe provide a couple pads on the bottom to solder bridge to bypass the diode if someone wants to backfeed power into the “USB” pin on the header to provide power to the Feather nRF9160’s 3V3 regulator.

                              Correct me if I am wrong here, but it appears the only way to power the Feather nRF9160’s 3V3 regulator is through the micro USB connector (or battery connector). I don’t dare feed 5V0 into that battery connector, I don’t think the charging IC will be happy with me.

                                One more note, the “enable” pin, JP2 pin 2, also can’t be tied to the Feather M0, it might be opposite to the function of the M0’s enable pin. It appears to cut power, I didn’t really investigate this, I just removed the connection from the Feather nRF9160 to the Feather M0 on the “enable” pin.

                                More and more I am isolating more pins, might just be better to fully isolate the two boards and only connect the needed power, reset, and UART pins…

                                If it is not apparent already, I am using one of the Feather Tripler boards…
                                https://www.adafruit.com/product/3417

                                  Was running into some funny problems (nRF9160 self-resetting for some reason), so I went ahead and isolated all pins except the necessary power, reset, and UART pins. This is the better way to do it anyway so I don’t have signals traveling between the MCUs that I am not sure about.

                                    Terms and Conditions | Privacy Policy