Group Actions
Engagement
  • Author Author: james.flynn
  • Date Created: Date Created
  • Views 1752 views
  • Likes 2 likes
  • Comments 3 comments
Related
Recommended

Alternative HW Platforms for Implementing an Azure IoT Client using the Mbed O/S (part 3)

james.flynn

Now, you have a program that works using a cellular connection, but the beauty of ARM Mbed OS, is that once that is done, it is trivial to switch it to other transport methods. For example, when I was starting to work on this project, I implemented it using an NXP K64F board with its integrated Ethernet interface. This allowed me to get all the mechanics of building the SDK, the OS, and integration while using Ethernet and once I was satisfied with that, I switched over and and used the BG96 Interface.  It is always good to minimize the number of variables when working with new hardware or technology and because I didn't know what issues I would find with a cellular interface, I chose to start with a known, mature, and stabled Ethernet Interface.  So to make it easy, the first port will be to convert the current project back to an Ethernet transport.

 

Ethernet with the NXP  FRDM-K64FFRDM-K64F Board

I used the following hardware to run on Ethernet:

 

 

After mounting the IKS01A2 on the K64F and connected the Ethernet, I modified the mbed_app.json file by changing the network-interface from its original configuration:

        "network-interface":{
            "help": "Options are ETHERNET, CELLULAR_WNC14A2A, CELLULAR_BG96",
            "value": "CELLULAR_BG96"
        },

 

To the new interface:

        "network-interface":{
            "help": "Options are ETHERNET, CELLULAR_WNC14A2A, CELLULAR_BG96",
            "value": "ETHERNET"
        },

 

You would normally have to also modify the User Button active state from Low to High(the K64f is active low vs the NUCLEOL496ZG which is active high but I have already included this is the mbedapp.json file at line#43 After the mbedapp.json file changes remember that for the NXP  FRDM-K64FFRDM-K64F board the target of our project is K64F rather than NUCLEOL496ZG so compile the project

 

mbed compile -m K64F -t GCC_ARM --profile toolchain_debug.json

 

Then copy the executable image to your K64F board to run it.  When it starts up the startup display now says:

image

Now when EasyConnect makes the connection to Azure, it uses Ethernet instead of BG96 and all message traffic will utilize a wired Ethernet connection.  Beyond the change in transport, the operation of the program is the same.  You may notice that now the RSSI is reported as 0 and this is because I have specifically set it to zero if you have not selected BG96 as the network-interface.

 

LTE-M Cellular Data with a NXP  FRDM-K64FFRDM-K64F

Note: There has been confusion about if this parts supports Cat-1 or LTE-M.  The two terms are synonymous so Cat-M1 and LTE-M are the same.

 

Because I had an AT&T Starter Kit (Available from AT&T IoT Starter Kit by Avnet), I decided to also port this project over to it.  Essentially, this kit does the same thing that the current example project does, only it uses a LTE-M cellular modem instead of a NBIoT cellular modem (https://www.iot-now.com/2016/06/21/48833-cat-m1-vs-nb-iot-examining-the-real-differences/ Like when using Ethernet this Kit uses the NXP  FRDM-K64FFRDM-K64F board so the target of our project is again K64F the other differences between the original and this version is that now our network-interface is set to CELLULAR_WNC14A2A rather than the original CELLULAR_BG96.

 

        "network-interface":{
            "help": "Options are ETHERNET, CELLULAR_WNC14A2A, CELLULAR_BG96",
            "value": "CELLULAR_WNC14A2A"
        },

 

Again, compile the program:

 

mbed compile -m K64F -t GCC_ARM --profile toolchain_debug.json

 

Then program it into the K64F board configured with the WNC14A2A Cellular Shield, again, the program operates exactly as it did in the original project, only now, the program is running on an AT&T Starter Kit

image

 

 

The past 3 blogs covered the fundamentals for interfacing an ‘TELUS LTE-M IoT Starter Kit with Azure IoT Hub. While this is a critical step toward creating an IoT solution there is a lot more to it than just connecting to Azure and sending data.

 

Once you have data being sent to Azure, you must begin managing the data, processing it, storing it, generating actions based on it and a myriad of other tasks that change raw measurements into useful data. There are several solution providers (such as Avnet IOT Solutions) to help with this task but that isn't what this Blog is about. Hopefully, I have provided the information needed to start creating the end-points that allows you to connect Azure, Mbed, and a ‘TELUS LTE-M IoT Starter Kit’. Happy Coding!

 

 

Previous Blog

/Jim  

Parents

  • Hi,

    Thanks for the article. Just wanted to ask if there is an issue running the code on a Nucleo L476, I built a custom board based on it and would be Ideal to not have to order new boards. I am trying to debug and trace the problems I run into and apparently it is a memory issue, however I tried to use pointers and optimize the code and managed to get rid of this issue but I still get errors regarding the SSL connection. The exact same code runs fine on the L496.

     

    Many thanks,

    Waleed

  • in reply to waleedelmughrabi

    Hello, I also tried using L476 and was not able to get it to run.  I traced it down to the MbedTLS library, when they are trying to parse the certificate.  The TLS library keeps everything in memory and as a result, they require a lot of memory.  I went through and tried to optimize the library using their suggestions and while I was able to get it to run a little further, I was never able to get it to run successfully.  The problem is heap size is insufficient to hold all the certificates and also decode at the same time.  I tired moving variables to static, but the Azure IoT SDK also uses a lot of memory mallocs (heap) then mbedTLS uses a lot of memory mallocs (heap) and the bottom line is I was never able to get it all squeezed down to successfully run, plus there is the problem that while it may work for a particular implementation instance, the first time you do something other than your development/test case, it may fail with little indication as to why.  Because of these issues, I decided it was easier to simply use the K64F or L497 which has more memory.

     

    My suggestion is if you really wanted it to work in a smaller memory footprint, maybe switch the TLS library from mbedTLS to OpenSSL or similar that maybe uses less heap memory in the implementation.

     

    Sorry I couldn't be of more assistance,

    Jim

Comment
  • in reply to waleedelmughrabi

    Hello, I also tried using L476 and was not able to get it to run.  I traced it down to the MbedTLS library, when they are trying to parse the certificate.  The TLS library keeps everything in memory and as a result, they require a lot of memory.  I went through and tried to optimize the library using their suggestions and while I was able to get it to run a little further, I was never able to get it to run successfully.  The problem is heap size is insufficient to hold all the certificates and also decode at the same time.  I tired moving variables to static, but the Azure IoT SDK also uses a lot of memory mallocs (heap) then mbedTLS uses a lot of memory mallocs (heap) and the bottom line is I was never able to get it all squeezed down to successfully run, plus there is the problem that while it may work for a particular implementation instance, the first time you do something other than your development/test case, it may fail with little indication as to why.  Because of these issues, I decided it was easier to simply use the K64F or L497 which has more memory.

     

    My suggestion is if you really wanted it to work in a smaller memory footprint, maybe switch the TLS library from mbedTLS to OpenSSL or similar that maybe uses less heap memory in the implementation.

     

    Sorry I couldn't be of more assistance,

    Jim

Children
No Data