I’m been running into odd build errors after moving over the nrf examples for the azure_iot_hub example. This has sent me down a rabbit hole of adding support for cmake, ninja, updated west builds etc in a MacOS/VS Code environment. Ideally I’d like to open up a single project in VS Code following the extensions-based build process described here: nrf9160-programming-and-debugging but target azure_iot_hub as the build example. Does anyone have a simple example of an azure connection working with either the nrf9160 Feather or the nrf9160 Thing Plus? I’m trying to validate the simplest upload of data into azure.

    icuhamW9 as it stands today you can either keep NFED loaded and copy the azure_iot_hub sample from NCS to the samples folder in nfed or load NCS standalone by initializing the repo with https://github.com/nrfconnect/sdk-nrf.git as the URL. The biggest thing you have to do is make sure that this is in your prj.conf

    # Enable Zephyr application to be booted by MCUboot
CONFIG_BOOTLOADER_MCUBOOT=y

    I don’t use or support Azure so I hope that gets you up and running. I’ll try to help as much as I can if you have further questions.

        Made some progress, and sharing for future users. I installed nRF Connect SDK v2.3.0 from nordic using the Install button from the nRF Connect for Desktop app. After it was installed I added the CONFIG_BOOTLOADER_MCUBOOT=y option to the prj.conf. I launched the terminal from nRF Connect for Desktop and I tried both of these build commands from the console:

        west build -b sparkfun_thing_plus_nrf9160_ns –pristine
        west build -b circuitdojo_feather_nrf9160_ns –pristine

        Both built successfully without any other edits in v2.3.0. This same process from nRF Connect for Desktop doesn’t work for v1.4.1, v1.5.0, or v1.9.1. The reason I tried v1.4.1 and v1.5.0 is because they are named in Sparkfun’s hookup guide for the Thing Plus Link to guide. I tried v1.9.1 because it is the latest version saved in the same directory as v1.4.1 and v1.5.0. Version v2.3.0 is available to install directly from the nRF Connect for Desktop app and it was the latest version available there which is why I chose it.

        The next step is to work out authentication with Azure IoT. The example seems to be set up for x.509 certificate based authentication which is more complex that SAS token based auth, but I think there may be changes needed in the code to trigger a SAS based approach. Not sure yet and my certificates aren’t set up correctly yet it seems.

        Anyway, it seems like v2.3.0 gets me to the point where the connection is attempted and I just need to configure the auth handshake correctly now.

          You likely have to write the certificates to the internal store on the nRF91. Once you have that you should be golden.

            The AT%CMNG command is what you’re looking for.

              I’ve found two spots where the certificates presumably go. The nRF Connect SDK defines a process here. But I can’t get this to work because the LTE Link Manager element of the nRF Connect App can’t see the Sparkfun nrf9160. I assume this uses the AT%CMNG command in the background. The second option appears to be to load the keys and certificates into three files that are placeholders in the build directory under certs/ca-cert.pem, certs/client-cert.pem, and certs/private-key.pem. We have an existing process on Google IoT Core for producing the client cert and private key that is almost identical to the Azure process so I tried just moving the keys into these 3 files at first. It seems like these should be loaded to memory or through a coded process but it’s not clear yet in the sample. If I can find where to change the auth to a SAS token to start with it would be easier but still some reading to do into azure’s iot hub SDK to find that.

                As log as you have

                # AT host library
CONFIG_AT_HOST_LIBRARY=y
CONFIG_UART_INTERRUPT_DRIVEN=y

                in your prj.conf you should be able to use the LTE Link Monitor to update those certs.

                  To check if it’s working open the device in serial monitor and type AT and you should get a response. This doesn’t play nice with the Zephyr shell though so you’ll need to go another route if that’s the case.

                    Terms and Conditions | Privacy Policy