Search Result

Dear Nordic, We made an attempt to use the external flash in the LwM2M sample. We tried to follow this: docs.nordicsemi.com/.../nrf9160_external_flash.html As soon as we add: ' / { chosen { nordic,pm-ext-flash = &mx25r64; }; }; The sample stops working, it does not even start. We guess, it is related with MCUBoot issue or not having pm_static.yml file. Could you please tell us how the proper configuration shall look in this case? Regards, Marcin

My NCS version is 2.6.1, and the modem firmware version is 1.3.6 I found that delta upgrade often fails when testing the firmware of FOTA upgrade modem for 9160. Currently, I have discovered that there are some issues with the dfu_target _offset_get function in the dfu_target header file. According to the upgrade process, the first step is to use dfu_target_init, which requires passing in a parameter to determine the update type. When I successfully initialize with DFU_TARGET_IMAGE_TYPE_FULL_MODEM , I then use dfu_target _offset_get to read the flash area in the modem used to store the update firmware. Generally, a normal result is obtained, which is 0. Then, I continue to use dfu_target_write to loop through the modem and write the new firmware. I choose to write 2k each time. When I write 2 times, that is, every 4k data is written, and then use dfu_target_write again, I will get a

The instructions are: On the command line, open the directory ncs . The following steps have one do a west init directly in the directory ncs. But they should say to create a directory below ncs that is identical to the nRFConnectSDK_revision and cd to that directory prior to doing west init and west update. The existing instructions are inconsistent with the diagram below step 6. And inconsistent with every other method you have for setting up a west workspace. Can you fix the documentation? I know it has been this way for many years; always incorrect, AFAICT. Thanks. Burt Silverman

Hi, I want to connect LDC2114 to nRF9160. I write the nrf9160dk_nrf9160_ns.overlay and the astri,ldc2114.yaml. I don't know how to set GPIOs in & i2c1 - ldc2114: ldc2114 @ 2a which are the output pins of LDC2114 and input pins of nRF9160. devzone.nordicsemi.com/.../1462.nrf9160dk_5F00_nrf9160_5F00_ns.overlay.txt devzone.nordicsemi.com/.../2308.astri_2C00_ldc2114.yaml.txt Also, What else should I do in order to connect the devices? Best regards, Liza

Hi! I have built a sample application "location," got some warnings, and got runtime errors. I have attached a zip file with code and images. I just have reinstalled nRF Connect Desktop, nRF Command Line Tools and VSC extension, I think I have some problems with my setup My setup: Updated Windows 11, Spanish SDK 2.6.1 and 2.8.0 Any hints would be greatly appreciated. devzone.nordicsemi.com/.../location.zip

There was no problem when the current version of ccache was 4.6.1. However, the current version of ccache, 4.10.2, behaves differently with the --specs option. It will do nothing at all with NCS. To correct this, I make this change diff --git a/cmake/modules/ccache.cmake b/cmake/modules/ccache.cmake index c1d41d6b9e4..14b9b683519 100644 --- a/cmake/modules/ccache.cmake +++ b/cmake/modules/ccache.cmake @@ -9,7 +9,7 @@ if(USE_CCACHE STREQUAL "0") else() find_program(CCACHE_FOUND ccache) if(CCACHE_FOUND) - set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE ccache) + set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE "ccache ignore_options=--specs=picolibc.specs") set_property(GLOBAL PROPERTY RULE_LAUNCH_LINK ccache) endif() endif() Thank you for any possible correction. I guess in the Linux case you include ccache in the Zephyr toolchain and it is a version that works. Burt Silverman

Hi, I’m experimenting with the nrf9160 LTE modem in poor network conditions. I would like to be able to keep track of how long the modem spends searching for LTE networks. I had assumed that we could do this by observing the registration status events emitted by the modem and tracking time spent in the LTE_LC_NW_REG_SEARCHING state but that appears to be insufficient. Here are some timestamped logs I captured during testing, showing the values of the lte_lc_nw_reg_status events emitted from the modem : 00:01:42.464 Sleep exit: LTE_LC_MODEM_SLEEP_FLIGHT_MODE(4) 00:02:01.638 Reg status: LTE_LC_NW_REG_UNKNOWN (4) 00:03:27.269 Reg status: LTE_LC_NW_REG_SEARCHING (2) 00:03:29.888 RRC status: LTE_LC_RRC_MODE_CONNECTED (1) 00:03:30.947 Reg status: LTE_LC_NW_REG_REGISTERED_HOME (1) From power measurement I can see that the modem begins LTE searching after the LTE_LC_NW_REG_UNKNOWN event, and it continues to search until 03:29 when it connects. What can be inferred about the modem’s search behavior when we receive the LTE_LC_NW_REG_UNKNOWN event? Why

Hi, We have come to expect that with the nRF Connect SDK installed properly and using recommended options we can build a sample, for example $cd \ncs\v2.8.0\nrf\samples\nrf_cloud_multi_service $ west build -b nrf9160dk/nrf9160/ns -- -DEXTRA_CONF_FILE="overlay_coap.conf" This particular sample does not build. I believe that my Windows registry is set for unlimited path length, however there is a CMAKE warning that appears regarding path longer than 250, and the build fails. I understand from past tickets I have seen that it is difficult to correct this by increasing the Cmake variable for CMAKE_OBJECT_PATH_MAX. I found that I had to $ git mv nrf_cloud_multi_service ncms #for example from the "cellular" directory in order to have a build go through. So, you need to shorten your SDK paths in this area if you support Windows. Or give us another clean solution that does not force us to resort to git mv "low level" commands.

Hello, I have been following the steps in Exercise 1 of Lesson 1 of the Cellular IoT Fundamentals course. I have a Thingy:91. I have followed the steps so far - flashed the modem firmware (1.3.5) - programmed the application firmware (Asset Tracker v2) - made an nRF Cloud account and added the iBasis SIM - I have run the instructions in Cellular Monitor. After a lot of trial and error I managed to get to this stage, where supposedly everything is working. However, in nRF Cloud, when I go to add the device using IMEI in the format nrf-123456789012345, I get " There was an error adding your device: No device found for this id. The device has not yet been just-in-time provisioned." The device continues to blink in green three times with a short pause in between. Looking at the troubleshooting steps for this error code: Verify the

Hi, I'm having trouble running the samples/net/aws_iot sample on nRF9160-based board. Configuration: - nCS: v2.6.0 - modem version: nrf9160_1.3.6 When running the sample with default settings for a nRF9160-based custom board using provided overlay for nrf9160dk_nrf9160_ns board, I get the following logs: [Sec Thread] Secure image initializing! Booting TF-M v2.0.0 *** Booting nRF Connect SDK v3.5.99-ncs1 *** [00:00:00.253,417] aws_iot_sample: The AWS IoT sample started, version: v1.0.0 [00:00:00.253,448] aws_iot_sample: Bringing network interface up and connecting to the network +CEREG: 2,"CE98","01F62E11",7 +CSCON: 1 +CGEV: ME PDN ACT 0,0 +CNEC_ESM: 50,0 +CEREG: 5,"CE98","01F62E11",7,,,"11100000","11100000" [00:00:04.385,437] aws_iot_sample: Network connectivity established [00:00:09.385,620] aws_iot_sample: Connecting to AWS IoT [00:00:13.273,986] aws_iot_sample: AWS_IOT_EVT_CONNECTED [00:00:13.274,963] aws_iot_sample: Publishing message: {"state":{"reported":{"uptime":13274,"app_version":"v1.0.0","modem_version":"nrf9160_1.3.6"}}} to AWS IoT shadow [00:00:13.352,478] aws_iot_sample: AWS_IOT_EVT_PUBACK, message ID: 37504 [00:00:13.523,895] mqtt_helper: Socket error: POLLERR [00:00:13.523,925] mqtt_helper: Connection was unexpectedly closed [00:00:13.524,475] aws_iot_sample: AWS_IOT_EVT_DISCONNECTED [00:00:18.524,658] aws_iot_sample: Connecting to AWS IoT [00:00:22.614,288] aws_iot_sample: AWS_IOT_EVT_CONNECTED [00:00:22.615,264] aws_iot_sample: Publishing message: {"state":{"reported":{"uptime":22614,"app_version":"v1.0.0","modem_version":"nrf9160_1.3.6"}}} to AWS IoT