nRF9160 with m4 MCU, camera, and LCD screen project

I am going to start a thread here and update it with the progress of a nRF9160 project that I am working on to get some feedback and also provide a starting point for anyone else interested in doing something similar.

Feel free to move this thread to a “projects” thread or such, if one is made in the future.
I am not sure this is the right place for this thread as it is mixed up with troubleshooting questions.

I just got the package in the mail, very quick shipping, thank you, paid about $15 for import taxes (sales tax and handling fees) which is common when I order something from overseas that is over $100.

Going to open things up and do some testing.

I have also been on a project using the nRF9160 so I thought I would share, it is not quite ready to share with everyone yet, but I would like to.

Basically I am using the nRF9160 with the project “serial_lte_modem” and interfacing it with an m4 based "Adafruit M4 Grand Central” board with a 1.8” LCD and camera. I would like to be able to upload and download images with this setup.

I just got the code somewhat working to download and display BMP or JPEG images, I was able to make a 100K byte buffer in the m4 to hold the downloaded data. I am using the following libraries with the Arduino IDE to accomplish this. The LC screen is 180 × 128, and have tested with a 65k BMP file and up to 30K or so JPEG file. The JPEGs must not have “progressive” downloading data in them for it to work with this setup. A limitation of the TJpg_Decoder library used.

The nRF9160 toolchain and tools were used to upload the (slightly modified) serial_lte_modem to the nRF9160, after that moved to the Arduino IDE to do the rest.

and the other libraries mentioned in this guide
https://learn.adafruit.com/adafruit-ov7670-camera-library-samd51

I used the Adafruit guide above as a starting point then added in the following two libraries
https://github.com/vshymanskyy/TinyGSM
https://github.com/Bodmer/TJpg_Decoder

I had to add support for the nRF9160 into the TinyGSM library and would would like some assistance perfecting it, if you or anyone else has time, I can throw out a thread on your fourm about it, this might make the nRF9160 a little more easier for beginners to work with although it does turn the nRF9160 into a serial LTE modem, it is capable of so much more.

This is, however, the direction people at the office want to go so “anyone” can use the Arduino IDE to add sensors, etc to it.

I am attaching the H file that I made for TinyGSM to this message, it has many bugs still though and sometimes downloads don’t complete, etc, but it is a starting point that I am working on.

I had to modify the serial_lte_modem project slightly to make it more friendly for TinyGSM. I switched around the output of the XRECV command so it outputs the length of the data first before the actual data otherwise it is difficult to parse it. All data is passed through the UART in plain text, binary data is passed in text, this doubles the size of the data, however, with the USRT speed set to 921600 and the limits of LTE-M1 is around 300k bits, it does not seem to pose a bottleneck. I tried to double the UART speed to 1843200 but either the nRF9160 or the M4 is not happy with it, and besides I am getting close to the 3M “limit” where wire sizes and interference can be problematic.

Let me do some testing, make sure the serial_lte_modem project runs correctly on the board, and I will upload some HEX files for easy uploading.

I have been using the Actinius Icarus up to this point and they provide a “Artinius Programmer” utility, which can be downloaded from the "nRF Connect” application. I have found this easy to upload the nRF9160, but have to upload the app_signed.hex file if using their bootloader, as well as adjust the image to start at address 0xC000 (if I remember correctly, its using an older Zephyr bootloader).

Anyway I have more to write, but will do some testing first and post the results.

…ah it seems I can’t upload a file, I don’t see an “upload” button, let me organize a way to host files first then Ill post a link, in the mean time, if anyone would like to get their hands on the code in its current state please let me know.

Ill post things up here as I run into issues or suggestions, first off, after I put the headers on (pointing down so the match with the feather board that I have) the pin numbers are now not so easy to read. It does not look like there is much room on top for the pins on the silkscreen, but something like this might be nice to have in the documentation.

https://cdn-learn.adafruit.com/assets/assets/000/046/244/original/adafruit_products_Feather_M0_Basic_Proto_v2.2-1.png?1504885373

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!

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>;	

};

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

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!

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.