azure/azure-iot-middleware-freertos

Azure IoT Middleware for FreeRTOS

Azure IoT Middleware for FreeRTOS

The Azure IoT middleware for FreeRTOS simplifies the connection of devices running FreeRTOS to Azure IoT services. It builds on top of the Azure SDK for Embedded C and adds MQTT client support. Below are key points of this project:

• The Azure IoT middleware for FreeRTOS is non allocating. That is, customers must allocate our data structures where they desire (global memory, heap, stack, etc.) and then pass the address of the allocated structure into our functions to initialize them and in order to perform various operations.
• The Azure IoT middleware for FreeRTOS operates at the MQTT level. Establishing the MQTT connection, subscribing and unsubscribing from topics, sending and receiving of messages, and disconnections are handled by the customer via middleware APIs.
• Customers control the TLS/TCP connection to the endpoint. This allows for flexibility between software or hardware implementations of either. For porting, please see the porting section below.
• No background threads are created by the Azure IoT middleware for FreeRTOS. Messages are sent and received synchronously.
• Retries with backoff are handled by the customer. FreeRTOS makes use of their own backoff and retry logic which customers are free to use (we demo this in our samples).

Table of Contents

• Azure IoT Middleware for FreeRTOS
  • Table of Contents
  • Samples
  • Docs
  • Repo Structure
    • Dependencies
  • Library Architecture
  • Code Size
  • Building
    • Using CMake
    • Using Source Files
    • Using Amazon FreeRTOS
  • Porting
    • TCP/IP and TLS
    • MQTT
    • Port Application from Azure IoT C SDK
  • Support
  • Contributing
    • Code Style
    • License
  • Trademarks

Samples

To keep this repo simple without board specific dependencies, we have a separate repo with all of the samples (please see the link here for working samples). There we have samples for several devices including:

Device	Azure IoT Hub	Azure IoT Device Provisioning	Azure Device Update
STM32L475	✓	✓	✓
STM32L4+	✓	✓	✓
STM32H745	✓	✓	✓
NXP RT1060	✓	✓	✓
ESPRESSIF ESP32	✓	✓	✓
Linux	✓	✓	✓
Windows	✓	✓	✗

For a video deep dive into this repo and the samples, please see the Microsoft Developers video below.

Docs

We have published doxygen-generated documentation for all of our APIs. Please see the link here to review how to use the APIs.

Azure Device Update

For details on using this library for over-the-air updates, please refer to this document: How to use the ADU Agent Client in Azure IoT Middleware for FreeRTOS.

Repo Structure

This repo is built for integration into your project. As mentioned above, if you would like to try out our samples, please clone that repo to get started. Otherwise, this repo will allow you to integrate the Azure IoT middleware for FreeRTOS into your embedded project. To see how that integration works, please see our below sections for building.

The most relevant sections of the repo are the following:

• /config_templates: Template config files to use for the library. Provided to easily bootstrap your project with the middleware.

• /libraries: Submodule dependencies for the middleware. To initialize these after cloning, you can run:

  git submodule update --init

• /ports: The source code for the MQTT abstraction (currently coreMQTT). If you would like to create your own MQTT abstraction implementation, please see the porting guide below.

• /source: All source files and headers for the middleware. To see how to build the project by using source files only, please see our below section for source file building.

• /tests: All unit and end-to-end tests used for validation.

Dependencies

We have dependencies on two libraries under the /libraries directory: Azure IoT SDK for Embedded C and coreMQTT. coreMQTT is used as a default MQTT implementation but may be swapped out by following our porting guide below.

Library Architecture

Below is a diagram showing the architecture for the middleware. Fundamentally, this middleware is build on top of the Azure SDK for Embedded C and adds MQTT functionality to abstract one layer away for simplified application building. All green boxes are taken care of by the middleware and are supported by Microsoft, while blue boxes are up to the user. Please see the porting section for details on the blue boxes.

Code Size

Total library size can depend on feature usage. Rough approximations and averages from our samples are the following with -Os and no logging:

Features	Flash (text,rodata,data)	RAM1,RAM2(dss,data)
IoT Hub + DPS	24 KB	12 bytes
IoT Hub only	11.5 KB	12 bytes

For total binary sizes for each of our samples, please see the "Size Chart" section in each of our board specific readmes on our samples repo.

Building

Please note that this repository does not clone FreeRTOS. If using CMake, we require the user to pass build variables to point to FreeRTOS artifacts. If using other methods to build, we still require those artifacts to be available at compile time. Details are provided below for both scenarios.

Using CMake

This repository uses CMake to build. To integrate into your project, use the add_subdirectory() CMake function in your CMakeLists.txt and pass three paths as CMake options. You can set these either in the configuration step of CMake with a -D or add them as cache variables in your CMake. Please see here for an example from our samples.

• FREERTOS_DIRECTORY: Full path to a directory which contains FreeRTOS (as set up on GitHub).
• FREERTOS_PORT_DIRECTORY: The full path to the freertos port that you would like to use. On GitHub you can find the list here. Locally, if you initialize the FreeRTOS submodules, you can find the options in <FREERTOS_DIRECTORY>/FreeRTOS/Source/portable
• CONFIG_DIRECTORY: The full path which has the following files: FreeRTOSConfig.h, azure_iot_config.h, and core_mqtt_config.h.

With those options added, the following CMake target will be available to integrate into your project:

• az::iot_middleware::freertos

Using Source Files

Similar to the process of building using CMake, the library requires a few components in order to build by using only the source files (maybe in make files or some proprietary build system).

The following files are for core library functionality:

• All source files under source
• All header files under source/include
• All header files under source/interface

The following includes must be available to the library for compilation.

• FreeRTOS kernel includes
• A FreeRTOS port directory
• A path or paths to the following files: FreeRTOSConfig.h, azure_iot_config.h.

If using the coreMQTT port for the MQTT, the following needs to be included and built:

• core_mqtt_config.h
• The source/interface directory
• The port files in ports/coreMQTT
• Proper compilation and linking of the coreMQTT library

Other than these, your choice of libraries for TLS and TCP/IP are up to you to choose and properly configure/compile.

Using Amazon FreeRTOS

We have a guide here which will help you port and build your Amazon FreeRTOS project with the Azure IoT middleware for FreeRTOS.

Porting

This library, by depending on FreeRTOS, will support any board with a FreeRTOS port. FreeRTOS networking stack support is not as extensive as the OS and therefore may need to be created or adapted to work with our library. You may use available resources at the FreeRTOS Plus repo and the FreeRTOS Third Party section for integration. Please see the below sections for help with networking.

TCP/IP and TLS

The middleware for FreeRTOS operates at the MQTT level. This requires customers to supply the TLS and TCP/IP stacks for their devices. The binding between the MQTT layer and the TLS/TCP/IP is defined in the azure_iot_transport_interface.h. For an example to see how that is passed to the middleware, please see the code block linked here in our samples.

Authentication

Azure IoT supports x509 certificate and SAS key authentication. For details on which to use, you can refer to this document going over the pros and cons of each. For more details on the TLS requirements of Azure IoT (TLS versions, certificate requirements, supported crypto algorithms, etc), please see this document here. Application integration hints for both authentication mechanisms can be found in our samples: for x509 please see here and for SAS keys please see here.

MQTT

THIS FEATURE IS IN PREVIEW AND THE API IS SUBJECT TO CHANGE

The middleware uses an MQTT abstraction to allow the substitution of the MQTT library. The default implementation is the FreeRTOS built coreMQTT (see the port implementation here). If you would like to create a new MQTT abstraction implementation for an MQTT library of your choosing, please complete the interface described in this header file.

Port Application from Azure IoT C SDK

If you are looking to port your application from the Azure IoT C SDK, please see our document detailing the process here: Porting from Azure IoT C SDK.

Support

If you need support, please see our SUPPORT.md file.

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.

When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

Code Style

This repository uses uncrustify to enforce coding style. The config in the root (uncrustify.cfg) is the same as in the FreeRTOS repo.

Note that different versions of uncrustify can produce differently rendered files. For that reason, just as the FreeRTOS repo has declared, we use version 0.67 of uncrustify. For installation instructions for uncrustify, please see their repo here. Once you have that installed, you can make sure your contributions are rendered correctly by running our uncrustify script:

# From the repo root
./.github/scripts/code_style.sh fix

License

Azure IoT middleware for FreeRTOS is licensed under the MIT license.

Trademarks

This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft trademarks or logos is subject to and must follow Microsoft's Trademark & Brand Guidelines. Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship. Any use of third-party trademarks or logos are subject to those third-party's policies.

azure-iot-middleware-freertos's Issues

Remove word "method" for "command" functionality

In the docs for AzureIoTHubClient_SendCommandResponse, we're using the word "method" a few places where really it should be "command".

/**
 * @brief Send a response to a received command message.
 *
 * @param[in] pxAzureIoTHubClient The #AzureIoTHubClient_t * to use for this call.
 * @param[in] pxMessage The pointer to the #AzureIoTHubClientCommandRequest_t to which a response is being sent.
 * @param[in] ulStatus A code that indicates the result of the method, as defined by the user.
 * @param[in] pucCommandPayload __[nullable]__ An optional method response payload.
 * @param[in] ulCommandPayloadLength The length of the method response payload.
 * @return An #AzureIoTResult_t with the result of the operation.
 */

AzureIoTResult_t AzureIoTHubClient_SendCommandResponse( AzureIoTHubClient_t * pxAzureIoTHubClient,
const AzureIoTHubClientCommandRequest_t * pxMessage,
uint32_t ulStatus,
const uint8_t * pucCommandPayload,
uint32_t ulCommandPayloadLength );

Have user select the FreeRTOS port path to use for CMake

https://github.com/Azure/azure-iot-middleware-freertos/pull/96/files#diff-51a8fde1a99f5c115465f0b3f79c4afa7a15d1fb2fbb03d99344f9a034f59473R28

coreHTTP Init functions do not handle HTTPClient_InitializeRequestHeaders return code

Is there an existing issue for this?

• I have searched the existing issues

Version

1.1.0

Description of the issue

On coreHTTP the following Init functions do not handle the HTTPClient_InitializeRequestHeaders return code, therefore always succeeding, even when it should fail:

• AzureIoTHTTP_Init: 107
• AzureIoTHTTP_RequestSizeInit: 204

This behavior is confusing because those Init functions return success even if HTTPClient_InitializeRequestHeaders cannot write the request headers. Without request headers, Send functions will raise this error:

Parameter check failed: pRequestHeaders->headersLen does not meet minimum the required length. MinimumRequiredLength=16, HeadersLength=0

Expected behavior

The following Init functions should handle the HTTPClient_InitializeRequestHeaders return code, succeeding only when the headers are written:

• AzureIoTHTTP_Init: 107
• AzureIoTHTTP_RequestSizeInit: 204

Steps to reproduce the issue

Call AzureIoTHTTP_RequestSizeInit or AzureIoTHTTP_Init with a header buffer with 10 bytes of size.
It will succeed even though there is not enough space to write the headers.

Relevant log output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

AzureIoTResult return code for AzureIoTHubClient_Connect on refused connection

Hello everyone,
I have a feature request. With the current implementation of AzureIoTHubClient_Connect it is not possible to determine why the connection failed. xResult is always eAzureIoTErrorFailed regardless of the value of xMQTTResult. However as a user of the API it is necessary for me to tell the difference between a refused connection (MQTTServerRefused) or if the connection failed because of other reasons. In some cases it might be necessary to redo the provisioning if the server refuses the connection. For that purpose I propose the addition of a new enum value for AzureIoTResult that is returned by AzureIoTHubClient_Connect in case the connection got refused.

AzureIoTHubClient_SendTelemetry() returns success when the message is not successfully delivered

The expectation is that when calling AzureIoTHubClient_SendTelemetry(), if it’s not able to deliver the telemetry to iothub at that moment, it will return something like eAzureIoTErrorFailed, and block until delivered or timed out. However, what I’m finding is that it always returns eAzureIoTSuccess until the azure client has detected the disconnection. I notice that these messages are then going into some sort of queue because minutes later when I restore the internet connection, it delivers these messages. This isn’t the behavior we want to implement. It’s important that it’s known at the time of calling SendTelemetry whether or not the delivery of the message was successful, even if the call is blocking.

The scenario I am trying to prevent: Controller is successfully connected to azure. Internet connection is lost (in my testing, a firewall rule to block the controller's internet). AzureIoTHubClient_SendTelemetry is called and returns success. Eventually azure client recognizes connectivity is lost, then shortly after, there’s a power failure. The telemetry will never be delivered because it’s in the azure client queue. If AzureIoTHubClient_SendTelemetry returns something other than success, we know at that moment to write the message to flash and it’ll be delivered later when connectivity is restored.

I have tested defining the macro azureiotconfigKEEP_ALIVE_TIMEOUT_SECONDS and that does seem to be working well to reduce the likelihood of the aforementioned scenario. I’ve lowered it to 10 seconds for testing, and it behaves as expected. However, even if it is set very low, my example scenario can still occur since we send telemetry upwards of every 30 seconds, and sometimes we’ll send 3 messages at that 30 second interval.

Is there any way to get AzureIoTHubClient_SendTelemetry() to block until it is confirmed the message is delivered to IoT Hub?

Document multiple agent/component models, consider helpers

The Middleware runs on a single task, by design. It's not our business to spin tasks on behalf of the device application, since we want to help OEMs save every last byte. Because of this model we also are not thread safe.

That said we've received a few requests along the lines of "Suppose I want a Thermostat Agent and a Device Update Agent on the same underlying FreeRTOS az_iot_hub handle?" We need a definitive answer here, which will be some mix of clear documentation and samples at minimum. PnP and its componentization model naturally lends a shape to (de)multiplexing.

We may consider some level of a convenience API to make this easier. (We're NOT looking to one-for-one re-create the convenience layer of Azure IoT C SDK at present in the middleware, however, due to the extra complexity this would add. But if there's something that would be optional only for people wanting this and that could be supported by SDK and not overly complex, we'll consider.)

Add callout for SDK being non memory allocating

Assembler error messages when building azure-iot-middleware-freertos library using cmake

Is there an existing issue for this?

• I have searched the existing issues

Version

1.1.0

Description of the issue

I'm trying to link azure IoT freertos sdk library to my STM32F446 CubeMX project. I'm using Cmake as a build system. I've followed the steps given in the Github description:
my top level cmake file looks like this:

set(FREERTOS_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/CubeMX/Middlewares/Third_Party CACHE STRING "")
set(FREERTOS_PORT_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/CubeMX/Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM4F CACHE STRING "")
set(CONFIG_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/config CACHE STRING "")

add_subdirectory(${CMAKE_CURRENT_SOURCE_DIR}/libs/azure-iot-middleware-freertos)
target_link_libraries(${CMAKE_PROJECT_NAME} PRIVATE az::iot_middleware::freertos)

When running cmake it works fine and successfully generates make files for my project and Azure sdk, but when I'm trying to build it with make it gives an error shown in the attached log output.

Expected behavior

No response

Steps to reproduce the issue

No response

Relevant log output

cmake \
                -G "MinGW Makefiles" \
                -Bbuild \
                -DCMAKE_BUILD_TYPE=Debug \
                -DCMAKE_TOOLCHAIN_FILE=gcc-arm-none-eabi.cmake \
                -DCMAKE_EXPORT_COMPILE_COMMANDS=ON \
                -DDUMP_ASM=OFF
-- The C compiler identification is GNU 10.3.1
-- The CXX compiler identification is GNU 10.3.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/binaries/gcc-arm-none-eabi-10.3-2021.10-win32/gcc-arm-none-eabi-10.3-2021.10/bin/arm-none-eabi-gcc.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/binaries/gcc-arm-none-eabi-10.3-2021.10-win32/gcc-arm-none-eabi-10.3-2021.10/bin/arm-none-eabi-g++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- The ASM compiler identification is GNU
-- Found assembler: C:/binaries/gcc-arm-none-eabi-10.3-2021.10-win32/gcc-arm-none-eabi-10.3-2021.10/bin/arm-none-eabi-gcc.exe
Vcpkg integrate step.
-- Read version from C:/Users/Dell/Desktop/CubeMx/makefile_test_project/libs/azure-iot-middleware-freertos/libraries/azure-sdk-for-c/sdk/inc/azure/core/az_version.h 
-- AZ_SDK_VERSION_MAJOR 1
-- AZ_SDK_VERSION_MINOR 5
-- AZ_SDK_VERSION_PATCH 0
-- AZ_SDK_VERSION_PRERELEASE beta.1
-- Configuring done (1.5s)
-- Generating done (0.2s)
-- Build files have been written to: C:/Users/Dell/Desktop/CubeMx/makefile_test_project/build
C:/binaries/make-3.81/bin/make -C build --no-print-directory
[  1%] Building C object libs/azure-iot-middleware-freertos/source/azure-sdk-for-c/sdk/src/azure/platform/CMakeFiles/az_noplatform.dir/az_noplatform.c.obj
[  2%] Linking C static library libaz_noplatform.a
[  2%] Built target az_noplatform
[  3%] Building C object libs/azure-iot-middleware-freertos/source/azure-sdk-for-c/sdk/src/azure/core/CMakeFiles/az_core.dir/az_base64.c.obj
[  4%] Building C object libs/azure-iot-middleware-freertos/source/azure-sdk-for-c/sdk/src/azure/core/CMakeFiles/az_core.dir/az_context.c.obj
[  5%] Building C object libs/azure-iot-middleware-freertos/source/azure-sdk-for-c/sdk/src/azure/core/CMakeFiles/az_core.dir/az_http_pipeline.c.obj
[  7%] Building C object libs/azure-iot-middleware-freertos/source/azure-sdk-for-c/sdk/src/azure/core/CMakeFiles/az_core.dir/az_http_policy.c.obj
[  8%] Building C object libs/azure-iot-middleware-freertos/source/azure-sdk-for-c/sdk/src/azure/core/CMakeFiles/az_core.dir/az_http_policy_logging.c.obj
[  9%] Building C object libs/azure-iot-middleware-freertos/source/azure-sdk-for-c/sdk/src/azure/core/CMakeFiles/az_core.dir/az_http_policy_retry.c.obj
[ 10%] Building C object libs/azure-iot-middleware-freertos/source/azure-sdk-for-c/sdk/src/azure/core/CMakeFiles/az_core.dir/az_http_request.c.obj
[ 11%] Building C object libs/azure-iot-middleware-freertos/source/azure-sdk-for-c/sdk/src/azure/core/CMakeFiles/az_core.dir/az_http_response.c.obj
[ 13%] Building C object libs/azure-iot-middleware-freertos/source/azure-sdk-for-c/sdk/src/azure/core/CMakeFiles/az_core.dir/az_json_reader.c.obj
[ 14%] Building C object libs/azure-iot-middleware-freertos/source/azure-sdk-for-c/sdk/src/azure/core/CMakeFiles/az_core.dir/az_json_token.c.obj
[ 15%] Building C object libs/azure-iot-middleware-freertos/source/azure-sdk-for-c/sdk/src/azure/core/CMakeFiles/az_core.dir/az_json_writer.c.obj
[ 16%] Building C object libs/azure-iot-middleware-freertos/source/azure-sdk-for-c/sdk/src/azure/core/CMakeFiles/az_core.dir/az_log.c.obj
[ 17%] Building C object libs/azure-iot-middleware-freertos/source/azure-sdk-for-c/sdk/src/azure/core/CMakeFiles/az_core.dir/az_precondition.c.obj
[ 19%] Building C object libs/azure-iot-middleware-freertos/source/azure-sdk-for-c/sdk/src/azure/core/CMakeFiles/az_core.dir/az_span.c.obj
[ 20%] Linking C static library libaz_core.a
[ 20%] Built target az_core
[ 21%] Building C object libs/azure-iot-middleware-freertos/source/azure-sdk-for-c/sdk/src/azure/iot/CMakeFiles/az_iot_common.dir/az_iot_common.c.obj
[ 22%] Linking C static library libaz_iot_common.a
[ 22%] Built target az_iot_common
[ 23%] Building C object libs/azure-iot-middleware-freertos/source/azure-sdk-for-c/sdk/src/azure/iot/CMakeFiles/az_iot_provisioning.dir/az_iot_provisioning_client.c.obj
[ 25%] Building C object libs/azure-iot-middleware-freertos/source/azure-sdk-for-c/sdk/src/azure/iot/CMakeFiles/az_iot_provisioning.dir/az_iot_provisioning_client_sas.c.obj
[ 26%] Linking C static library libaz_iot_provisioning.a
[ 26%] Built target az_iot_provisioning
[ 27%] Building C object libs/azure-iot-middleware-freertos/source/CMakeFiles/coremqtt.dir/__/libraries/coreMQTT/source/core_mqtt_serializer.c.obj
[ 28%] Building C object libs/azure-iot-middleware-freertos/source/CMakeFiles/coremqtt.dir/__/libraries/coreMQTT/source/core_mqtt_state.c.obj
[ 29%] Building C object libs/azure-iot-middleware-freertos/source/CMakeFiles/coremqtt.dir/__/libraries/coreMQTT/source/core_mqtt.c.obj
[ 30%] Linking C static library libcoremqtt.a
[ 30%] Built target coremqtt
[ 32%] Building C object libs/azure-iot-middleware-freertos/source/azure-sdk-for-c/sdk/src/azure/iot/CMakeFiles/az_iot_hub.dir/az_iot_adu_client.c.obj
[ 33%] Building C object libs/azure-iot-middleware-freertos/source/azure-sdk-for-c/sdk/src/azure/iot/CMakeFiles/az_iot_hub.dir/az_iot_hub_client.c.obj
[ 34%] Building C object libs/azure-iot-middleware-freertos/source/azure-sdk-for-c/sdk/src/azure/iot/CMakeFiles/az_iot_hub.dir/az_iot_hub_client_sas.c.obj
[ 35%] Building C object libs/azure-iot-middleware-freertos/source/azure-sdk-for-c/sdk/src/azure/iot/CMakeFiles/az_iot_hub.dir/az_iot_hub_client_telemetry.c.obj
[ 36%] Building C object libs/azure-iot-middleware-freertos/source/azure-sdk-for-c/sdk/src/azure/iot/CMakeFiles/az_iot_hub.dir/az_iot_hub_client_c2d.c.obj
[ 38%] Building C object libs/azure-iot-middleware-freertos/source/azure-sdk-for-c/sdk/src/azure/iot/CMakeFiles/az_iot_hub.dir/az_iot_hub_client_twin.c.obj
[ 39%] Building C object libs/azure-iot-middleware-freertos/source/azure-sdk-for-c/sdk/src/azure/iot/CMakeFiles/az_iot_hub.dir/az_iot_hub_client_methods.c.obj
[ 40%] Building C object libs/azure-iot-middleware-freertos/source/azure-sdk-for-c/sdk/src/azure/iot/CMakeFiles/az_iot_hub.dir/az_iot_hub_client_commands.c.obj
[ 41%] Building C object libs/azure-iot-middleware-freertos/source/azure-sdk-for-c/sdk/src/azure/iot/CMakeFiles/az_iot_hub.dir/az_iot_hub_client_properties.c.obj
[ 42%] Linking C static library libaz_iot_hub.a
[ 42%] Built target az_iot_hub
[ 44%] Building C object libs/azure-iot-middleware-freertos/source/CMakeFiles/az_iot_middleware_freertos.dir/azure_iot_adu_client.c.obj
[ 45%] Building C object libs/azure-iot-middleware-freertos/source/CMakeFiles/az_iot_middleware_freertos.dir/azure_iot_hub_client.c.obj
C:\Users\Dell\AppData\Local\Temp\cc1iBg8C.s: Assembler messages:
C:\Users\Dell\AppData\Local\Temp\cc1iBg8C.s:50: Error: selected processor does not support requested special purpose register -- `msr basepri,r3'
C:\Users\Dell\AppData\Local\Temp\cc1iBg8C.s:51: Error: selected processor does not support `isb ' in ARM mode
C:\Users\Dell\AppData\Local\Temp\cc1iBg8C.s:52: Error: selected processor does not support `dsb ' in ARM mode
C:\Users\Dell\AppData\Local\Temp\cc1iBg8C.s:176: Error: selected processor does not support requested special purpose register -- `msr basepri,r3'
C:\Users\Dell\AppData\Local\Temp\cc1iBg8C.s:177: Error: selected processor does not support `isb ' in ARM mode
C:\Users\Dell\AppData\Local\Temp\cc1iBg8C.s:178: Error: selected processor does not support `dsb ' in ARM mode
C:\Users\Dell\AppData\Local\Temp\cc1iBg8C.s:204: Error: selected processor does not support requested special purpose register -- `msr basepri,r3'
C:\Users\Dell\AppData\Local\Temp\cc1iBg8C.s:205: Error: selected processor does not support `isb ' in ARM mode
C:\Users\Dell\AppData\Local\Temp\cc1iBg8C.s:206: Error: selected processor does not support `dsb ' in ARM mode
C:\Users\Dell\AppData\Local\Temp\cc1iBg8C.s:304: Error: selected processor does not support requested special purpose register -- `msr basepri,r3'
C:\Users\Dell\AppData\Local\Temp\cc1iBg8C.s:305: Error: selected processor does not support `isb ' in ARM mode
C:\Users\Dell\AppData\Local\Temp\cc1iBg8C.s:306: Error: selected processor does not support `dsb ' in ARM mode
C:\Users\Dell\AppData\Local\Temp\cc1iBg8C.s:332: Error: selected processor does not support requested special purpose register -- `msr basepri,r3'
C:\Users\Dell\AppData\Local\Temp\cc1iBg8C.s:333: Error: selected processor does not support `isb ' in ARM mode
C:\Users\Dell\AppData\Local\Temp\cc1iBg8C.s:334: Error: selected processor does not support `dsb ' in ARM mode
make[3]: *** [libs/azure-iot-middleware-freertos/source/CMakeFiles/az_iot_middleware_freertos.dir/azure_iot_hub_client.c.obj] Error 1
make[2]: *** [libs/azure-iot-middleware-freertos/source/CMakeFiles/az_iot_middleware_freertos.dir/all] Error 2
make[1]: *** [all] Error 2
make: *** [build] Error 2

Code of Conduct

• I agree to follow this project's Code of Conduct

Gated build error (no connection string)

We do not have more info as of now, but there is a concern that perhaps the gated build will fail if posting a PR from a fork.

2021-08-16T22:13:37.4992864Z ##[group]Running E2E tests
2021-08-16T22:13:37.4993336Z Installing node dependencies using npm
2021-08-16T22:13:38.7147333Z npm WARN deprecated [email protected]: Debug versions >=3.2.0 <3.2.7 || >=4 <4.3.1 have a low-severity ReDos regression when used in a Node.js environment. It is recommended you upgrade to 3.2.7 or 4.3.1. (https://github.com/visionmedia/debug/issues/797)
2021-08-16T22:13:39.7467611Z npm WARN deprecated [email protected]: "Please update to latest v2.3 or v2.2"
2021-08-16T22:13:39.9758969Z npm WARN deprecated [email protected]: Please upgrade  to version 7 or higher.  Older versions may use Math.random() in certain circumstances, which is known to be problematic.  See https://v8.dev/blog/math-random for details.
2021-08-16T22:13:40.6765320Z npm WARN deprecated [email protected]: jsSHA versions < 3.0.0 will no longer receive feature updates
2021-08-16T22:13:41.4410469Z npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
2021-08-16T22:13:41.6723764Z npm WARN deprecated [email protected]: this library is no longer supported
2021-08-16T22:13:46.4613088Z 
2021-08-16T22:13:46.4615732Z > [email protected] install /home/runner/work/azure-iot-middleware-freertos/azure-iot-middleware-freertos/tests/e2e/service/node_modules/keytar
2021-08-16T22:13:46.4617421Z > prebuild-install || npm run build
2021-08-16T22:13:46.4618016Z 
2021-08-16T22:13:46.5861931Z prebuild-install WARN install EACCES: permission denied, access '/root/.npm'
2021-08-16T22:13:46.7902148Z npm ERR! code EACCES
2021-08-16T22:13:46.7904755Z npm ERR! syscall scandir
2021-08-16T22:13:46.7906455Z npm ERR! path /root/.npm/_logs
2021-08-16T22:13:46.7908992Z npm ERR! errno -13
2021-08-16T22:13:46.7920028Z npm ERR! 
2021-08-16T22:13:46.7921663Z npm ERR! Your cache folder contains root-owned files, due to a bug in
2021-08-16T22:13:46.7922787Z npm ERR! previous versions of npm which has since been addressed.
2021-08-16T22:13:46.7923798Z npm ERR! 
2021-08-16T22:13:46.7925338Z npm ERR! To permanently fix this problem, please run:
2021-08-16T22:13:46.7926258Z npm ERR!   sudo chown -R 1001:121 "/root/.npm"
2021-08-16T22:13:46.7940567Z glob error [Error: EACCES: permission denied, scandir '/root/.npm/_logs'] {
2021-08-16T22:13:46.7941404Z   errno: -13,
2021-08-16T22:13:46.7942513Z   code: 'EACCES',
2021-08-16T22:13:46.7943040Z   syscall: 'scandir',
2021-08-16T22:13:46.7943532Z   path: '/root/.npm/_logs'
2021-08-16T22:13:46.7943905Z }
2021-08-16T22:13:46.8073829Z 
2021-08-16T22:13:46.8075476Z > [email protected] build /home/runner/work/azure-iot-middleware-freertos/azure-iot-middleware-freertos/tests/e2e/service/node_modules/keytar
2021-08-16T22:13:46.8076748Z > node-gyp rebuild
2021-08-16T22:13:46.8077125Z 
2021-08-16T22:13:47.4041497Z gyp WARN EACCES current user ("runner") does not have permission to access the dev dir "/root/.cache/node-gyp/14.17.4"
2021-08-16T22:13:47.4047191Z gyp WARN EACCES attempting to reinstall using temporary dev dir "/home/runner/work/azure-iot-middleware-freertos/azure-iot-middleware-freertos/tests/e2e/service/node_modules/keytar/.node-gyp"
2021-08-16T22:13:48.0471775Z make: Entering directory '/home/runner/work/azure-iot-middleware-freertos/azure-iot-middleware-freertos/tests/e2e/service/node_modules/keytar/build'
2021-08-16T22:13:48.0491241Z   CXX(target) Release/obj.target/keytar/src/async.o
2021-08-16T22:13:49.1539254Z   CXX(target) Release/obj.target/keytar/src/main.o
2021-08-16T22:13:50.2159342Z   CXX(target) Release/obj.target/keytar/src/keytar_posix.o
2021-08-16T22:13:51.3466779Z   SOLINK_MODULE(target) Release/obj.target/keytar.node
2021-08-16T22:13:51.4147701Z   COPY Release/keytar.node
2021-08-16T22:13:51.4207930Z make: Leaving directory '/home/runner/work/azure-iot-middleware-freertos/azure-iot-middleware-freertos/tests/e2e/service/node_modules/keytar/build'
2021-08-16T22:13:51.5356417Z npm ERR! Callback called more than once.
2021-08-16T22:13:51.7869322Z npm notice created a lockfile as package-lock.json. You should commit this file.
2021-08-16T22:13:51.7925549Z npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@~2.1.1 (node_modules/chokidar/node_modules/fsevents):
2021-08-16T22:13:51.7927045Z npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
2021-08-16T22:13:51.7971492Z npm WARN [email protected] No description
2021-08-16T22:13:51.8015032Z npm WARN [email protected] No repository field.
2021-08-16T22:13:51.8039471Z npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/keytar):
2021-08-16T22:13:51.8041357Z npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] install: `prebuild-install || npm run build`
2021-08-16T22:13:51.8042457Z npm WARN optional SKIPPING OPTIONAL DEPENDENCY: Exit status 243
2021-08-16T22:13:51.8043616Z 
2021-08-16T22:13:51.8063238Z added 329 packages from 327 contributors and audited 375 packages in 13.846s
2021-08-16T22:13:51.9003630Z 
2021-08-16T22:13:51.9004786Z 40 packages are looking for funding
2021-08-16T22:13:51.9005288Z   run `npm fund` for details
2021-08-16T22:13:51.9005559Z 
2021-08-16T22:13:51.9012028Z found 2 moderate severity vulnerabilities
2021-08-16T22:13:51.9012781Z   run `npm audit fix` to fix them, or `npm audit` for details
2021-08-16T22:13:51.9164118Z Done installing node dependencies
2021-08-16T22:13:51.9165091Z Compiling typescripts to js
2021-08-16T22:13:52.1062794Z 
2021-08-16T22:13:52.1065196Z > [email protected] build /home/runner/work/azure-iot-middleware-freertos/azure-iot-middleware-freertos/tests/e2e/service
2021-08-16T22:13:52.1066303Z > tsc
2021-08-16T22:13:52.1066725Z 
2021-08-16T22:13:55.7790475Z Done compiling typescripts to js
2021-08-16T22:13:55.7791363Z Cleaning expired e2e resources
2021-08-16T22:13:55.9650512Z 
2021-08-16T22:13:55.9652985Z > [email protected] cleanup /home/runner/work/azure-iot-middleware-freertos/azure-iot-middleware-freertos/tests/e2e/service
2021-08-16T22:13:55.9654712Z > node ./lib/common/e2e_test_cleanup.js --connectionString ${IOTHUB_CONNECTION_STRING} --e 5
2021-08-16T22:13:55.9655428Z 
2021-08-16T22:13:56.1882666Z ReferenceError: value is ''
2021-08-16T22:13:56.1885602Z     at Function.Registry.fromConnectionString (/home/runner/work/azure-iot-middleware-freertos/azure-iot-middleware-freertos/tests/e2e/service/node_modules/azure-iothub/dist/registry.js:1101:19)
2021-08-16T22:13:56.1888505Z     at /home/runner/work/azure-iot-middleware-freertos/azure-iot-middleware-freertos/tests/e2e/service/lib/common/e2e_test_cleanup.js:50:70
2021-08-16T22:13:56.1931914Z     at step (/home/runner/work/azure-iot-middleware-freertos/azure-iot-middleware-freertos/tests/e2e/service/lib/common/e2e_test_cleanup.js:38:23)
2021-08-16T22:13:56.1933937Z     at Object.next (/home/runner/work/azure-iot-middleware-freertos/azure-iot-middleware-freertos/tests/e2e/service/lib/common/e2e_test_cleanup.js:19:53)
2021-08-16T22:13:56.1935802Z     at /home/runner/work/azure-iot-middleware-freertos/azure-iot-middleware-freertos/tests/e2e/service/lib/common/e2e_test_cleanup.js:13:71
2021-08-16T22:13:56.1936834Z     at new Promise (<anonymous>)
2021-08-16T22:13:56.1938407Z     at __awaiter (/home/runner/work/azure-iot-middleware-freertos/azure-iot-middleware-freertos/tests/e2e/service/lib/common/e2e_test_cleanup.js:9:12)
2021-08-16T22:13:56.1940420Z     at iothubRegistryCleanup (/home/runner/work/azure-iot-middleware-freertos/azure-iot-middleware-freertos/tests/e2e/service/lib/common/e2e_test_cleanup.js:46:12)
2021-08-16T22:13:56.1942378Z     at /home/runner/work/azure-iot-middleware-freertos/azure-iot-middleware-freertos/tests/e2e/service/lib/common/e2e_test_cleanup.js:122:42
2021-08-16T22:13:56.1944205Z     at step (/home/runner/work/azure-iot-middleware-freertos/azure-iot-middleware-freertos/tests/e2e/service/lib/common/e2e_test_cleanup.js:38:23)
2021-08-16T22:13:56.2126693Z Done Cleaning expired e2e resources
2021-08-16T22:13:56.2127443Z Running tests
2021-08-16T22:13:56.3976574Z 
2021-08-16T22:13:56.3979022Z > [email protected] alltest /home/runner/work/azure-iot-middleware-freertos/azure-iot-middleware-freertos/tests/e2e/service
2021-08-16T22:13:56.3980664Z > npm run iothub_e2e_test && npm run iothub_e2e_test_using_dm && npm run iot_provisioning_e2e_test && npm run iot_provisioning_e2e_test_using_dm
2021-08-16T22:13:56.3981435Z 
2021-08-16T22:13:56.5923991Z 
2021-08-16T22:13:56.5926549Z > [email protected] iothub_e2e_test /home/runner/work/azure-iot-middleware-freertos/azure-iot-middleware-freertos/tests/e2e/service
2021-08-16T22:13:56.5928428Z > mocha ./lib/iothub_client/e2e_iot_hub_client_test.js  --connectionString ${IOTHUB_CONNECTION_STRING} --e ${DEVICE_TEST_EXE} --timeout 120000
2021-08-16T22:13:56.5929635Z 
2021-08-16T22:13:57.0951020Z 
2021-08-16T22:13:57.0954405Z 
2021-08-16T22:13:57.0979764Z   1) "before all" hook: Initial test device and test child  process creation in "{root}"
2021-08-16T22:13:57.0984077Z 
2021-08-16T22:13:57.0985152Z   0 passing (4ms)
2021-08-16T22:13:57.0985593Z   1 failing
2021-08-16T22:13:57.0986129Z 
2021-08-16T22:13:57.0989367Z   1) "before all" hook: Initial test device and test child  process creation in "{root}":
2021-08-16T22:13:57.0990897Z      ReferenceError: value is ''
2021-08-16T22:13:57.0992487Z       at Function.Registry.fromConnectionString (node_modules/azure-iothub/dist/registry.js:1101:19)
2021-08-16T22:13:57.0993898Z       at createTestDevice (lib/common/e2e_test_core.js:89:35)
2021-08-16T22:13:57.0995172Z       at Object.createTestDeviceAndTestProcess (lib/common/e2e_test_core.js:374:5)
2021-08-16T22:13:57.0996507Z       at Context.testSetup (lib/iothub_client/e2e_iot_hub_client_test.js:59:20)
2021-08-16T22:13:57.0997507Z       at processImmediate (internal/timers.js:464:21)
2021-08-16T22:13:57.0998141Z 
2021-08-16T22:13:57.0998587Z 
2021-08-16T22:13:57.0999003Z 
2021-08-16T22:13:57.1094815Z npm ERR! code ELIFECYCLE
2021-08-16T22:13:57.1096406Z npm ERR! errno 1
2021-08-16T22:13:57.1131435Z npm ERR! [email protected] iothub_e2e_test: `mocha ./lib/iothub_client/e2e_iot_hub_client_test.js  --connectionString ${IOTHUB_CONNECTION_STRING} --e ${DEVICE_TEST_EXE} --timeout 120000`
2021-08-16T22:13:57.1134673Z npm ERR! Exit status 1
2021-08-16T22:13:57.1135039Z npm ERR! 
2021-08-16T22:13:57.1135687Z npm ERR! Failed at the [email protected] iothub_e2e_test script.
2021-08-16T22:13:57.1136432Z npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
2021-08-16T22:13:57.1165819Z 
2021-08-16T22:13:57.1166292Z npm ERR! A complete log of this run can be found in:
2021-08-16T22:13:57.1167116Z npm ERR!     /root/.npm/_logs/2021-08-16T22_13_57_113Z-debug.log
2021-08-16T22:13:57.1235888Z npm ERR! code ELIFECYCLE
2021-08-16T22:13:57.1236310Z npm ERR! errno 1
2021-08-16T22:13:57.1274270Z npm ERR! [email protected] alltest: `npm run iothub_e2e_test && npm run iothub_e2e_test_using_dm && npm run iot_provisioning_e2e_test && npm run iot_provisioning_e2e_test_using_dm`
2021-08-16T22:13:57.1275069Z npm ERR! Exit status 1
2021-08-16T22:13:57.1275420Z npm ERR! 
2021-08-16T22:13:57.1275990Z npm ERR! Failed at the [email protected] alltest script.
2021-08-16T22:13:57.1276704Z npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
2021-08-16T22:13:57.1301706Z 
2021-08-16T22:13:57.1302980Z npm ERR! A complete log of this run can be found in:
2021-08-16T22:13:57.1303857Z npm ERR!     /root/.npm/_logs/2021-08-16T22_13_57_127Z-debug.log
2021-08-16T22:13:57.1350533Z ##[error]Process completed with exit code 1.
2021-08-16T22:13:57.1437628Z Post job cleanup.
2021-08-16T22:13:57.2376400Z [command]/usr/bin/git version
2021-08-16T22:13:57.2417944Z git version 2.32.0
2021-08-16T22:13:57.2452041Z [command]/usr/bin/git config --local --name-only --get-regexp core\.sshCommand
2021-08-16T22:13:57.2484586Z [command]/usr/bin/git submodule foreach --recursive git config --local --name-only --get-regexp 'core\.sshCommand' && git config --local --unset-all 'core.sshCommand' || :
2021-08-16T22:13:57.2684483Z Entering 'libraries/azure-sdk-for-c'
2021-08-16T22:13:57.2721720Z Entering 'libraries/coreMQTT'
2021-08-16T22:13:57.2765899Z [command]/usr/bin/git config --local --name-only --get-regexp http\.https\:\/\/github\.com\/\.extraheader
2021-08-16T22:13:57.2788356Z http.https://github.com/.extraheader
2021-08-16T22:13:57.2796632Z [command]/usr/bin/git config --local --unset-all http.https://github.com/.extraheader
2021-08-16T22:13:57.2825872Z [command]/usr/bin/git submodule foreach --recursive git config --local --name-only --get-regexp 'http\.https\:\/\/github\.com\/\.extraheader' && git config --local --unset-all 'http.https://github.com/.extraheader' || :
2021-08-16T22:13:57.3023671Z Entering 'libraries/azure-sdk-for-c'
2021-08-16T22:13:57.3060749Z Entering 'libraries/coreMQTT'
2021-08-16T22:13:57.3156625Z Cleaning up orphan processes

DPS and multiple Devices

Hi

I have been advised by the Azure Support team to ask questions about the azure-IoT-middleware-freertos directly on here.

I aim to use this SDK with ESP32.

How can I set it up with DPS so that I have one global bin firmware, that automatically downloads each device's key within in the device itself? I aim to have about 3K devices.

Each device will know its own ID(mac or serial), I could write a small AzureFunction API that each device call for it key, and then could use that key to connect to the iot hub. This would mean, DPS would not be needed.

Create internal directory for internal only APIs

EX:
AzureIoT_Base64HMACCalculate

Keeps rebooting when on ESP32

Hi

I am using the ESP32 sample.

I would also like to add the OTA feature on my device so I can keep updating the IoT device in the field. Therefore I made a change to the partition to include OTA.

But now, the device keeps outputting the following and rebooting. Can someone advice why this happens?

Rebooting...<CR><LF>
ets Jun  8 2016 00:22:57<CR><LF>
<CR><LF>
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)<CR><LF>
configsip: 0, SPIWP:0xee<CR><LF>
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00<CR><LF>
mode:DIO, clock div:2<CR><LF>
load:0x3fff0030,len:6608<CR><LF>
load:0x40078000,len:14780<CR><LF>
load:0x40080400,len:3792<CR><LF>
entry 0x40080694<CR><LF>
<ESC>�[0;32mI (27) boot: ESP-IDF v4.4-rc1 2nd stage bootloader<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (27) boot: compile time 21:23:30<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (27) boot: chip revision: 1<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (30) boot_comm: chip revision: 1, min. bootloader chip revision: 0<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (37) boot.esp32: SPI Speed      : 40MHz<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (42) boot.esp32: SPI Mode       : DIO<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (46) boot.esp32: SPI Flash Size : 4MB<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (51) boot: Enabling RNG early entropy source...<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (56) boot: Partition Table:<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (60) boot: ## Label            Usage          Type ST Offset   Length<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (67) boot:  0 nvs              WiFi data        01 02 00009000 00004000<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (75) boot:  1 otadata          OTA data         01 00 0000d000 00002000<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (82) boot:  2 phy_init         RF data          01 01 0000f000 00001000<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (89) boot:  3 factory          factory app      00 00 00010000 00100000<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (97) boot:  4 ota_0            OTA app          00 10 00110000 00100000<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (104) boot:  5 ota_1            OTA app          00 11 00210000 00100000<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (112) boot: End of partition table<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (116) boot: Defaulting to factory image<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (121) boot_comm: chip revision: 1, min. application chip revision: 0<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (128) esp_image: segment 0: paddr=00010020 vaddr=3f400020 size=1fe8ch (130700) map<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (184) esp_image: segment 1: paddr=0002feb4 vaddr=3ffb0000 size=00164h (   356) load<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (184) esp_image: segment 2: paddr=00030020 vaddr=400d0020 size=96b40h (617280) map<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (413) esp_image: segment 3: paddr=000c6b68 vaddr=3ffb0164 size=03730h ( 14128) load<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (419) esp_image: segment 4: paddr=000ca2a0 vaddr=40080000 size=148d0h ( 84176) load<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (454) esp_image: segment 5: paddr=000deb78 vaddr=50000000 size=00010h (    16) load<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (464) boot: Loaded app from partition at offset 0x10000<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (464) boot: Disabling RNG early entropy source...<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (476) cpu_start: Pro cpu up.<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (476) cpu_start: Starting app cpu, entry point is 0x400811dc<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (463) cpu_start: App cpu up.<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (493) cpu_start: Pr
07/03/2022 22:44:10.462 [RX] - o cpu start user code<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (493) cpu_start: cpu freq: 160000000<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (493) cpu_start: Application information:<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (497) cpu_start: Project name:     azure_iot_freertos_esp32<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (504) cpu_start: App version:      3e01d9e-dirty<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (509) cpu_start: Compile time:     Mar  5 2022 21:22:58<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (515) cpu_start: ELF file SHA256:  2d0f56704c94fb01...<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (521) cpu_start: ESP-IDF:          v4.4-rc1<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (527) heap_init: Initializing. RAM available for dynamic allocation:<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (534) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (540) heap_init: At 3FFB91F0 len 00026E10 (155 KiB): DRAM<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (546) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (552) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (559) heap_init: At 400948D0 len 0000B730 (45 KiB): IRAM<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (566) spi_flash: detected chip: generic<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (570) spi_flash: flash io: dio<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (575) cpu_start: Starting scheduler on PRO CPU.<ESC>�[0m<CR><LF>
<ESC>�[0;32mI (0) cpu_start: Starting scheduler on APP CPU.<ESC>�[0m<CR><LF>
ESP_ERROR_CHECK failed: esp_err_t 0x110d (ESP_ERR_NVS_NO_FREE_PAGES) at 0x4008839c<CR><LF>
file: "../main/azure_iot_freertos_esp32_main.c" line 278<CR><LF>
func: app_main<CR><LF>
expression: nvs_flash_init()<CR><LF>
<CR><LF>
abort() was called at PC 0x4008839f on core 0<CR><LF>
<CR><LF>
<CR><LF>
Backtrace:0x40081a4e:0x3ffbc6f00x400883a9:0x3ffbc710 0x4008f3d2:0x3ffbc730 0x4008839f:0x3ffbc7a0 0x400d7849:0x3ffbc7c0 0x40165331:0x3ffbc7e0 0x4008baa5:0x3ffbc800 <CR><LF>
<CR><LF>

Move code style section in readme down to contributing

azure-iot-middleware-freetros repo should automatically delete a branch after a PR merge

Independent if the guidance will be to use forks for PRs or not.

_ProcessLoop takes 2000ms when ulTimeoutMilliseconds < 2000 and nothing to process

I'm noticing a strange pattern where when there's nothing for _ProcessLoop to process, it takes exactly 2000ms to run.

Quick overview of how I have things set up. Main loop task does the work to queue messages, then there's an azure task that runs constantly and does nothing but maintain Azure connectivity and constantly run _ProcessLoop when connected.

Here's the code in the azure task:

PROCESS_LOOP_TIMEOUT_MS is 500, but even when set to 0 the behavior is the same. Here's the log of a typical run when there's nothing to do. Note the difference is EXACTLY 2000ms, and usually is.

When attempting to send a message in the main loop, I run _ProcessLoop a single time after _SendTelemetry to attempt to deliver the message right away. This allows me to get a failure if we suddenly become disconnected, and I can then store the message for sending later, or if the device happens to reboot or crash.

This used to be set to PROCESS_LOOP_TIMEOUT_MS. Setting the timeout to 0 from 500 made a big difference in the amount of time spent on this task. In this case, it takes just 360ms, and is often lower.

Here, I make a direct method call to the device (no work here, just returning a variable value). Because there's something to do, it takes just 1080ms, even with calling _SendCommandResponse.

The reason this even matters is because during this 2 second period, any direct method call will not be processed and must wait until the next or subsequent iteration. A response can take upwards of 5 seconds or more. Any idea why when there's nothing for _ProcessLoop to do, it takes exactly 2 full seconds to finish, but when there is something to do it finishes quickly?

Add QOS option for telemetry

#60 (comment)

Improve doxygen documentation for AzureIoTHubClient_SubscribeCommand

From customer feedback:
I think a tiny bit of extra explanation for AzureIoTHubClient_SubscribeCommand() would be very helpful on this page: https://azure.github.io/azure-iot-middleware-freertos/azure__iot__hub__client_8h.html

Connection errors every 65 minutes

I've got another issue here that I am guessing is related to the SAS token, as this occurs every 65 minutes. Very similar to what I saw with the c sdk. When this happens I'm disconnecting and reconnecting and that seems to cure, but I figure there's probably something I'm missing that would prevent these errors completely.

E (51768706) tls_freertos: Reading failed, errno= 128
E (51768706) MQTT: A single byte was not read from the transport: transportStatus=-1.
E (51768716) MQTT: Receiving incoming packet length failed. Status=MQTTRecvFailed
E (51768726) MQTT: Exiting process loop due to failure: ErrorStatus=MQTTRecvFailed
E (51768726) AZ IOT: AzureIoTMQTT_ProcessLoop failed: ProcessLoopDuration=500, MQTT error=0x00000004

Remove DPS payload creation once embedded SDK has it

Move following implementation to Embedded sdk:

azure-iot-middleware-freertos/source/azure_iot_provisioning_client.c

Line 260 in 4c2ca23

prvProvClientCreateRequestPayload( AzureIoTProvisioningClientHandle_t xProvClientHandle,

Possible API name suggestion

AzureIoTHubClient_GetDeviceTwin -> AzureIoTHubClient_RequestDeviceTwinAsync | AzureIoTHubClient_RequestDeviceTwin

PR: https://github.com/Azure-Samples/iot-middleware-freertos-samples/pull/1/files#r640945672

Remove base64 encode/decode once embedded SDK has it

This issue tracks adding a base64 encoder/decoder into the embedded C SDK which this repo consumes.

A pending PR in this repo brings its own base64 encode/decode. We should remove this repo's copy once the embedded SDK one is available.

Create a version header/system for the middleware

We should have a way of versioning the middleware independent of the embedded SDK.
#60 (comment)

Investigate E2E failures on latest Ubuntu 20.04

Using ubuntu-latest as the running suddenly caused our gates to fail. Look into which dependency caused this and update to be able to use the latest again.

Make JSON ut more robust by testing error cases

Mock return values of embedded calls to test for error path.

Initial readme feedback

• In library architecture, consider calling out that the user can change the TLS|TCP and that the diagram with the mbedTLS|/LWIP. It's not clear to me right off this is for illustrative purposes and isn't that these are forced. We don't want to go too much into this in the arch section - if we even take this feedback - since porting guide follows.
• RE swapping out coreMQTT described here - we're over-promising on this, at least for now. We should consider removing this OR call out that the interface here is subject to change until we formalize everything.

Do error checking before using embedded sdk API's

Existing pre-condition in embedded sdk requires caller to verify all parameters. Middleware needs to handle all the places where embedded sdk api's are used.

Give AzureIoT_Message APIs its own header file

• Pull out all message APIs from azure_iot.h and put in a new azure_iot_message.h or similar
• Rename APIs from AzureIoT_Message to AzureIoTMessage_
  

  azure-iot-middleware-freertos/source/include/azure_iot.h

  Lines 117 to 157 in 7e5cb01

  	AzureIoTResult_t AzureIoT_MessagePropertiesInit( AzureIoTMessageProperties_t * pxMessageProperties,
  	uint8_t * pucBuffer,
  	uint32_t ulAlreadyWrittenLength,
  	uint32_t ulBufferLength );
  	/**
  	* @brief Append a property name and value to a message.
  	*
  	* @note The properties init API will not encode properties. In order to support
  	* the following characters, they must be percent-encoded (RFC3986) as follows:
  	* - `/` : `%2F`
  	* - `%` : `%25`
  	* - `#` : `%23`
  	* - `&` : `%26`
  	* Only these characters would have to be encoded. If you would like to avoid the need to
  	* encode the names/values, avoid using these characters in names and values.
  	*
  	* @param[in] pxMessageProperties The #AzureIoTMessageProperties_t* to use for the operation.
  	* @param[in] pucName The name of the property to append.
  	* @param[in] ulNameLength The length of \p pucName.
  	* @param[in] pucValue The value of the property to append.
  	* @param[in] ulValueLength The length of \p pucValue.
  	* @return An #AzureIoTResult_t with the result of the operation.
  	*/
  	AzureIoTResult_t AzureIoT_MessagePropertiesAppend( AzureIoTMessageProperties_t * pxMessageProperties,
  	const uint8_t * pucName,
  	uint32_t ulNameLength,
  	const uint8_t * pucValue,
  	uint32_t ulValueLength );
  	/**
  	* @brief Find a property in the message property bag.
  	*
  	* @param[in] pxMessageProperties The #AzureIoTMessageProperties_t* to use for the operation.
  	* @param[in] pucName The name of the property to find.
  	* @param[in] ulNameLength Length of the property name.
  	* @param[out] ppucOutValue The output pointer to the property value.
  	* @param[out] pulOutValueLength The length of \p ppucOutValue.
  	* @return An #AzureIoTResult_t with the result of the operation.
  	*/
  	AzureIoTResult_t AzureIoT_MessagePropertiesFind( AzureIoTMessageProperties_t * pxMessageProperties,

Add comments distinguishing middleware vs embedded includes

Currently the headers for middleware and embedded looks very similar and it isn't immediately apparent the difference.

Example: az_iot_hub_client.h vs azure_iot_hub_client.h

azure-iot-middleware-freertos/source/include/azure_iot_hub_client.h

Line 26 in 7e5cb01

#include "azure/iot/az_iot_hub_client.h"

We should add some comments like

#include "azure_iot_mqtt_port.h"
#include "azure_iot_transport_interface.h"

/* Embedded SDK includes */
#include "azure/az_core.h"
#include "azure/iot/az_iot_hub_client.h"

Issue with Group enrollment for X.509 certificate

Device provisioning services (DPS) are not able to provision the device with enrollment group service for X.509 certificate attestation.

Reference
Azure-Samples/iot-middleware-freertos-samples#225
https://learn.microsoft.com/en-us/answers/questions/998659/device-provisioning-via-enrollment-group.html

Update Commit SHA of embedded to release

Log verbosity toggle for payload

#60 (comment)

AzureIoTHubClient_SendTelemetry() behaviour

Hi, anyone can confirm that the payload of AzureIoTHubClient_SendTelemetry() is encoded Base64 during transmission ?

I send a JSON text, but the people working at IoTHub side see the payload encoded with Base64 format.
Sending the same JSON text with a simulated device is received without encoding.

Add Info to Build Section of Readme

• Code size details (take average of samples)
• Details like user has to supply the FreeRTOS directory
• Kinds of authentication (what does IoT Hub support). Take from the Amazon FreeRTOS doc.
• Board support (really whatever FreeRTOS has and some kind of port for a TLS and TCP/IP stack)

Top Level Readme Improvements

Two parts

• Break down the Repo Structure to Repo Structure and Samples Callout. Explain why we have two repos. Explain if you want to integrate into already existing project, clone this repo. If wanting samples, clone the samples.
• Make the samples callout the first thing below the "why"

AKA

# Azure IoT middleware for FreeRTOS
  --stuff--
## Samples
  --stuff--
## Repo Structure
  --stuff--

Reported properties are getting client-side when reading the direct method

Hi,
Reported properties are getting client-side when reading the direct method.
I wrote the following portion of code to read the direct method on client side

uint32_t ulHandleCommand( AzureIoTHubClientCommandRequest_t * pxMessage,
                          uint32_t * pulResponseStatus,
                          uint8_t * pucCommandResponsePayloadBuffer,
                          uint32_t ulCommandResponsePayloadBufferSize )
{
     AzureIoTResult_t xResult;
    AzureIoTJSONReader_t xReader;
    AzureIoTJSONWriter_t xWriter;
    int32_t lCommandNameLength;
    int32_t ulCommandResponsePayloadLength;
    LogInfo( ( "Command payload : %.*s \r\n",
               pxMessage->ulPayloadLength,
               ( const char * ) pxMessage->pvMessagePayload ) );
   ESP_LOGI("AZ IOT","Name > %s\r\n",
                   pxMessage->pucCommandName);

I closed relay 5 in the direct method and then get the command and reported properties on the client side. What is the reason behind this?

I (438071) MQTT: Packet received. ReceivedBytes=45.
I (438071) MQTT: De-serialized incoming PUBLISH packet: DeserializerResult=MQTTSuccess.
I (438071) MQTT: State record updated. New state=MQTTPublishDone.
I (438081) AZ IOT: $iothub/methods/POST/RLY5-Close/?$rid=1
I (438081) AzureIoT: prvHandleCommand called for DirectMethod
I (438101) AzureIoT: Command payload : null
I (438101) AZ IOT: Name > RLY5-Close/?$rid=1null$rid=3":1},"reported":{"GPS":{"Lat":"0.00000000","Long":"0.00000000"},"FirmwareDetails":{"Version":"1.2","BuildDate":"2022-04-10T06:04:00Z"},"$version":21689}}vices%2FED-02&sig=wsIpKocAATyM6Wvyoj6CS914Wjh8VwhFgAuEhz%2FMM3A%3D&se=1669808360

Need a porting guide from Azure IoT C SDK to Middleware

We've received customer feedback that we need a porting guide for customers currenly on the Azure IoT C SDK middleware that want to move to this repo's implementation.

Specific areas we should cover:

• Philosophical differences between the code; namely IoT C SDK is "run on any platform with a porting layer" whereas this repo is FreeRTOS optimized.
• Smaller footprint for this repo.
• Fewer abstractions - including this is MQTT only - and no built in retry, no convenience layer concept.
• Rough mapping of IoT Hub and DPS APIs from C SDK to their equivalents.
• Details about the retry/reconnect stuff (which is a separate section but calling out here).

We'll also need fairly detailed porting guide for the middleware/OS interactions. Mostly this should be pointing folks to existing ports, but for scenarios we can't cover out of the box:

• How to integrate TLS|TCP for data sending.
• How to setup DPS keying
• Error handling. Feedback from our customer is error handling on what we have in preview is HARD and needed more guidance since it wasn't consistent.

Add azure iot config template into repo

Inspect packet to see if ack was successful

TODO tag here:

azure-iot-middleware-freertos/source/azure_iot_hub_client.c

Lines 90 to 91 in 8de2706

	/* TODO: inspect packet to see is ack was successful*/
	context->_internal.state = azureiothubTOPIC_SUBSCRIBE_STATE_SUBACK;

TLS connection: No server cert check on ESP32

Hello,
I try to integrate the azure iot middleware into my existing project. The software compiles and can be flashed.
After a wifi connection is established the ESP32 tries to connect to the azure IoT hub and fails:
Error: Time:Tue Jun 7 14:09:22 2022 File:../components/esp-azure/azure-iot-sdk-c/iothub_client/src/iothubtransport_mqtt_common.c Func:InitializeConnection Line:2355 mqtt_client timed out waiting for CONNACK Error: Time:Tue Jun 7 14:09:22 2022 File:../components/esp-azure/port/src/tlsio_esp_tls.c Func:tlsio_esp_tls_destroy Line:152 tlsio_esp_tls_destroy called while not in TLSIO_STATE_CLOSED. Error: Time:Tue Jun 7 14:43:17 2022 File:../components/esp-azure/port/src/tlsio_esp_tls.c Func:tlsio_esp_tls_open_async Line:323 TLS INIT E (4289772) esp-tls-mbedtls: No server verification option set in esp_tls_cfg_t structure. Check esp_tls API reference E (4289772) esp-tls-mbedtls: Failed to set client configurations, returned [0x8017] (ESP_ERR_MBEDTLS_SSL_SETUP_FAILED) E (4289782) esp-tls: create_ssl_handle failed
The c SDK has some root certs in it and also the port. In the port folder the comment states that the root cert is used for the ESP8266.

How do I tell the ESP32 implementation to either use the shipped certificate(s) or to use the cert bundle?

This library assumes a 32-bit processor for all length fields on API.

When compiling for a 64-bit there's a lot of additional casting due to the API definition of all
"uint32_t ul.*Length" parameters

An example is:
AzureIoTProvisioningClient_SetSymmetricKey

AzureIoTResult_t AzureIoTProvisioningClient_SetSymmetricKey( AzureIoTProvisioningClient_t * pxAzureProvClient,
                                                             const uint8_t * pucSymmetricKey,
                                                             uint32_t ulSymmetricKeyLength,
                                                             AzureIoTGetHMACFunc_t xHmacFunction );

Should be:

AzureIoTResult_t AzureIoTProvisioningClient_SetSymmetricKey( AzureIoTProvisioningClient_t * pxAzureProvClient,
                                                             const uint8_t * pucSymmetricKey,
                                                             size_t ulSymmetricKeyLength,
                                                             AzureIoTGetHMACFunc_t xHmacFunction );

List of functions that should change are:

• AzureIoTProvisioningClient_GetDeviceAndHub
• AzureIoTProvisioningClient_SetRegistrationPayload
• AzureIoTProvisioningClient_SetSymmetricKey
• AzureIoTProvisioningClient_Init
• AzureIoTProvisioningClient - function declaration.

Suggest also changing the structures to use size_t as well, but If there is a requirement not to change the types for the structures eg: uint32_t ulSymmetricKeyLength; - to size_t ulSymmetricKeyLength then this library can do the conversion to the uint32_t when they are assigned.

TLS Certificate Changes Coming - no earlier than Feb 15th, 2023

Please see the blog post here for details on why this is important:
https://techcommunity.microsoft.com/t5/internet-of-things/azure-iot-tls-critical-changes-are-almost-here-and-why-you/ba-p/2393169

Rewrite property tests as iterator

#142 (comment)

Remove unused function suppression

https://github.com/Azure/azure-iot-middleware-freertos/pull/60/files#diff-4461c617ceae0c7e0206622aacdf555aedd62eb129c2efb74c84fa1567bcbe0dR50

Add a support section for README

Request for compatibility with ESP-IDF v5.1

Our project uses ESP-IDF 5.1
Would like to be able to just clone the repository, but has required hundreds of hacks to the code.

Of note:
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"

instead of:
#include "FreeRTOS.h"
#include "task.h"

Hundreds of format errors with logging eg.:
AZLogInfo( ( "%.*s", az_span_size( xMessage ), az_span_ptr( xMessage ) ) );
reports:
Description Resource Path Location Type field precision specifier '.*' expects argument of type 'int', but argument 6 has type 'int32_t' {aka 'long int'} [-Werror=format=] azure_iot.c /LoadAssist_IoT/libs/azure-iot-middleware-freertos/source line 39 C/C++ Problem
casting to an expected (int)az_span_size solves that.

I've been slowly but surely fixing all these errors, and hopefully will eventually be able to compile and use it.
The only problem is, I will have to repeatedly do this every time you update your repository, so a s to keep up to date with your latest innovations.

This is just a simple request, but also required to keep at pace with Espressif's latest ESP-IDF innovations.

Client user agent/version is reported incorrectly as "c/1.1.0-beta.1(FreeRTOS)"

When using the latest samples I noticed that my device reports "c/1.1.0-beta.1(FreeRTOS)". This is unexpected since this is no longer in pre-release state.

Create a function to translate core errors to middleware errors

Update Copyright banner

Please use the latest format of copyright in C code.

https://docs.opensource.microsoft.com/releasing/maintain/copyright-headers/

MQTT PUBLISH failed with status MQTTNOMemory

Good morning. I seem to have run across a strange issue I've not encountered before. After some time of this controller being up and running, I'm not able to send telemetry. Can disconnect and reconnect though. As you can see in the log here, I've got a memory log entry right before a call to _SendTelemetry(). The OS task high water mark is 4088 (it's always at this level), total heap free is 67172, and minHeapFree (esp_get_minimum_free_heap_size()) is 42780. Plenty of heap to send this very small message of 177 bytes. These numbers were identical when the previous message was sent successfully. I don't understand why I'd get this error if there's plenty of free memory.

W (16214887) memLog: azureTaskLoop: TaskMax: 4088, HeapFree: 67172, minHeapFree: 42780
E (16214887) MQTT: MQTT PUBLISH failed with status MQTTNoMemory.
E (16214897) AZ IOT: Failed to publish telemetry: MQTT error=0x00000002
E (16214897) AzureService: checkAzureError at sendMessage->AzureIoTHubClient_SendTelemetry, result: 8
E (16214907) AzureService: Send message FAIL: {"id":"00000000000024xxxxxxxxxx","messageType":"postPipeDataPoints","message":"00000000000024xxxxxxxxxx|1655089666|0|30.2|29.6|33.7|0|3.29|3.67|3.16|79.16|80.78|79.34|79.52\n"}

Some research led me to the documentation here, which says that it returns "MQTTNoMemory if pBuffer is too small to hold the MQTT packet. I'm unsure why pBuffer would be too small for this, nor do I fully understand where the size of pBuffer is defined for coreMQTT. I do have a buffer of 4096 defined that is passed as the pucBuffer in AzureIoTHubClient_Init() on startup.

Also found this thread where the poster states that he "had moved AzureIoTHubClient_ProcessLoop() call to a OS task to be called periodically", which is exactly what I've done. I call _SendTelemetry from our main OS task loop, then azure has its own task which is constantly calling _ProcessLoop(). Like the OP there, I do not call _ProcessLoop() from our main task, opting for the azureTask to do all the work next time around. I don't understand why this would be a problem.

Add support for Azure IoT Device Update

Please add support for firmware updates via the Device Update for IoT Hub service.