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
nRF9160 with m4 MCU, camera, and LCD screen project
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>;};
- Edited
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.hI 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 can do!
- Edited
@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!
- Edited
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.
- Edited
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.
- Edited
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.
This is a reply to the post in https://community.jaredwolff.com/d/66-issue-entering-bootloader-in-new-v2-board asking about the JPEG encoding. I started to type this reply there and realized it might be better to have it here. Left a link there for it directing to here.
If you want to get setup I do have something kinda working, but with HTTP only, no HTTPS support yet.
I basically found some project of someone who made a JPEG compressor for M0 (and works with M4).
The M4 is not really optimized for this (takes a few seconds for a 160×120 color image), but I think if the FPU and some hardware support is combined it will work out faster.
Need to hold the whole raw image in SRAM (or external memory) for the JPEG compression, it jumps around the data while calculating things. A 160 × 120 image comes in at 38400 (160 * 120 * 2) bytes. The resulting JPEG comes in under 10000 bytes, plus some more SRAM used by the JPEG encoding engine itself. I wanted to do 320×200 but it takes more like 128000 SRAM for the raw image, and with the M4 having only 192k SRAM this does not look like it will work. Adding some external SRAM might work, but external SRAM access time will be slow, if you got any ideas it be cool to even be able to do a full 640×480 image!
Give me a little time to get organized and I will get a zip package setup and uploaded for ya to look at soon.
Here is what you need, if you have it already great!
If not, maybe you can sub some other things.
I will work on getting a guide made soon.
- Adafruit m4 Grand Central (need all that extra SRAM, and the camera support)
- Adafruit 1.8″ TFT screen
- https://www.adafruit.com/product/802
- An LCD screen makes it more fun, can download and view images too
- OV7670 camera, can find it on Amazon
- Refer to this guide to see which OV7670 board will work
- https://learn.adafruit.com/adafruit-ov7670-camera-library-samd51
“ if you got any ideas ” I was looking into compressing data before transmission but the memory in MCU processors stopped that. I did find that Maxim Integrated makes the MAX32651 and MAX32652 3MB flash, 1MB SRAM:
https://www.maximintegrated.com/en/products/microcontrollers/MAX32651-EVKIT.html The price on the huge low power MCU is $7@1K or $16@1
K2AAE
Oh thanks, I will keep those in mind.
My attention switched for a moment over to the ESP32 series, since thats what someone at work wants to work with, I have feelings in both directions with the ESP32 line, mostly reliability concerns if its used in a production environment, however the ESP32-CAM (easy to find on Amazon) has 4MB of PSRAM, plus it has some kind of hardware support for JPEG compression.
I get a fully compressed JPEG image from the camera’s buffer somehow, it has to have some hardware assistance for how “instant” the JPEG image is available.
This is another project I will post up soon, it is related to this since its still using the nRF9160 to push the image data to the web, however with the ESP32-CAM I can get a nice 1600 × 1600 image that is around 100k, give or take some bytes depending on the compression. It takes a few seconds to upload but the ESP32-CAM is nice in the way the JPEG is already done for you.