This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Connecting an nRF9160 to AWS

Hello,

I'm attempting to connect the nRF9160 DK to our AWS IoT account. I've been following the information in this question: https://devzone.nordicsemi.com/f/nordic-q-a/44528/switch-cloud-endpoint-from-nordic-aws-to-our-own-aws-account but I'm having an issue establishing the connection.

So far I have been able to call the certificates from a replica of 'certificates.h' and flash these onto the nRF91 using the nrf_inbuilt_key commands and have been able to establish a broker connection but receive a time out error when connecting to AWS with MQTT. I am currently modifying mqtt_simple to acheve this connection.

So far I have updated 'pj.conf' with:

I have added the following additional functions to mqtt_simple:

I have changed the following in Kconfig:

Finally, the certs are inside certificates.h:

I'm not sure what is still left to change in order to make the connection to AWS.

Parents
  • Hi,

     

    You are using \r\n as the line ending (normal is \n only), but both shall be accepted by the nrf_inbuilt API.

    I do not see any problems specific to your implementation, but what you could do is to verify that you have the latest modem installed, which can be found here:

    https://www.nordicsemi.com/Products/Low-power-cellular-IoT/nRF9160/Download#infotabs

     

    Do you always get the same error message, even if you try several times? if you enter debug mode, and debug the function mqtt_transport_socket_tls.c::mqtt_client_tls_connect(), which function returns the err?

     

    Kind regards,

    Håkon

  • Apologises for the delayed response. I have identified the issue with the connection. Turns out the network provider requires a whitelisted IP address that is incompatible with the dynamic IPs of AWS IoT Core.

    As the device I am using is deployed in another area of the UK, I can't manually update the modem to the latest version without risking something going wrong. I'd rather avoid updating the modem at this moment if I can get away with it. The device is hooked up to a Raspberry Pi with internet access which can faciliate re-flashing with JLinkExe but hasn't been set up with the modem update tools.

    I've been busy figuring out a counter to this issue and have decided to take a different path and use the BSD library to create a UDP connection to a static IP bounded EC2 instance on AWS. I have encountered a different problem with setting up this kind of connection however.

    The code compiles but the nRF9160 reports back a hard fault when the code is loaded onto the device. It will run the code until the UDP IPv4 socket information structure (struct nrf_sockaddr_in) is populated. I've tried to follow what examples I have found of this structure in the ncs repo but I seem to be missing something.

    This is were it appears the code gets to before hard fault, I placed printks to figure out where the code reaches before faulting:

    This is the UART information when the device resets until faulting:

    This is main.c

    EDIT: I should clarify, I have one DK deployed in an area of NB-IoT coverage that can be re-flashed remotely. I have a second DK beside me that I can use to test flashes operate as expected, but without any NB-IoT coverage in this area, before taking the merged zephyr hex file and remotely flashing using JLinkExe.

  • Hi,

     

    This code looks like trouble:

     

    Could you try this instead?

     

    Kind regards,

    Håkon

  • Hi,

    Thank you, that allowed the code to pass through the struct without faulting.

    I have tweeked the code slightly as the timer was causing an instruction fault (first time I've seen that as I use that timer code in other Zephyr nrf91 samples, I have removed it for now as it wasn't really needed). I have edited nrf_connect as even though there was no network for it to connect to, it was still returning 0 on err.

    Is this the correct way for nrf_connect to be called? It now fails out as expected for no network connection.

  • Hi,

     

    The code looks ok. I have an udp-example here (the bind is strictly not needed):

    https://github.com/Rallare/fw-nrfconnect-nrf/blob/nrf9160_samples/samples/nrf9160/ntp/src/main.c

    Kind regards,

    Håkon

  • I see. Thank you, I'll have a look through the udp-example. It will be a few days before the EC2 IP is whitelisted.

    I will update when the network is available to test the code.

    Many thanks

Reply
  • I see. Thank you, I'll have a look through the udp-example. It will be a few days before the EC2 IP is whitelisted.

    I will update when the network is available to test the code.

    Many thanks

Children
  • Hello again,

    I haven't been able to test the network as of yet but have been noting a few issues with the program. It has expanded over the past week to include some commented out section of the GPS sample code, (the goal is to design a device that will swap between LTE and GPS as needed) but this is all unneeded at the moment as the deployed DK is using old modem FW and can't use the AT command AT%XSYSTEMMODE. So all it really can do for now is turn itself off and on to test the AT command socket.

    I have noticed that the code just skips past the blocking do-while loop that I copied from the UDP example you linked to in your last reply. Rather than blocking while the errno is -EAGAIN, it auto fails after one attempt connection attempt. errno is coming back with error number 134.

    The code also for some reason stops being able to open sockets. I orginally thought this was due to me not closing sockets correctly when erroring out of the connect attempts thus running out of sockets but it actually doesn't appear to be the issue. Adding a print out for UDP_Socket shows that the Socket ID is always 2 (not sure why socket 1 isn't the first socket).

  • Hi,

     

    Sorry for not catching this before, but you are mixing the nrf_socket.h and the zephyr socket API. They do not play well together and needs translation (see nrf91_sockets.c for more detailed info).

    The include "net/socket.h" is also a bit suspicious, as you want to use the socket offloading, thus the translation between nrf and zephyr API. When you are calling socket() (and other calls), I am unsure which function you are calling in the background. This could be the network stacks socket implementation, which will not work with the nRF9160, or it could be the socket offloading (thus going into nrf91_sockets.c) which would have a mismatch of the structs.

    Could you instead try the ntp example and see if that works?

     

    Kind regards,

    Håkon

  • Hi,

    I copied across the files for the ntp example and ran it as it is in the repo.

    Did it require a specific checkout of the supporting repos (Zephyr, MCUBoot, nrfxlib)?

    Running it as is ended with a bus fault after getaddrinfo. Never made it to socket creation.

  • the getaddrinfo fails, indicating that your telecom provider might not provide DNS.

    You could try the ftp example in the same repository, as it hardcodes the IP to ftp.uninett.no.

     

    Kind regards,

    Håkon

  • Hi,

    I tried the ftp example, both as it is in the repo and edited. The code doesn't make it past boot up. The printk() line for the application start does not get sent to the link monitor, program just hard faults again. Error fault address at 0x0

    You are correct, my provider does not support anything other than a whitelisted IP address given to them in advance.

    I have gone back to my original program that was giving back the errno 134. Taking what you said, I have removed all <net/socket> commands and used only the nrf_socket library. The code now reports an errno of 22 which I believe is EINVAL (invalid argument) so at least it's not erroring an unknown value for errno.

    Arguments passed to blocking_connect():

    I also want to check the required prj.conf in case this is also causing issues; apologises if this is all wrong, never used this kind of file structure before and I'm piecing it together with what I learn from the other examples. Unlike the other examples, I'm not calling Link Control as the code should manually init the modem (it needs to be able to do this to change between NB-IoT and GPS later). The one I'm currently using is:

    Also, a question about the ftp code. In that code there is a converter for IP to Hex, inet_addr(). I implimented this into my code and printed the result to find that the IP address was backwards from what I expected it to be using manual conversion or something like https://www.browserling.com/tools/ip-to-hex . I have amended the function to put the bytes in the order I would expect but just want to check, is it supposed to be that way or is that an oversight in this checkout?

    Michael

    EDIT:

    I made a seperate version of the code that uses only the net/sockets.h library (like all examples of the nRF9160's data transfer capablities), it is doing the same as before, errno is 134 again. I'm not sure what else needs to be done to make this code block until connection.