sample_azure_iot_embedded_sdk not working for STM32F746G_DISCO in STM32CubeIDE?
Norlander opened this issue · 4 comments
Hi,
Downloaded the : Azure_RTOS_6.1_STM32F746G-DISCO_STM32CubeIDE_Samples_2020_10_10.zip
Followed the pdf tutorial: Azure_RTOS_STM32F746G-DISCO_Azure_IoT_Embedded_SDK_For_STM32CubeIDE.pdf
My STM32F746G-DISCO is connected via ethernet in my home network. DHCP/PSA2, no special restrictions...
I modify the samples_config.h and build the project successfully. Launch Teraterm to get debug output. Then launch the debugger in CubeIDE.
What happens?
Tera Term reports:
DHCP In Progress...
IP address: 192.168.1.194
Mask: 255.255.255.0
Gateway: 192.168.1.1
DNS Server address: 192.168.1.1
SNTP Time Sync...
Sometimes when restarting exeuction of the application I can even get to:
DHCP In Progress...
IP address: 192.168.1.194
Mask: 255.255.255.0
Gateway: 192.168.1.1
DNS Server address: 192.168.1.1
SNTP Time Sync...
SNTP Time Sync successfully.
[INFO] Azure IoT Security Module has been enabled, status=0
IoTHub Host Name: MyF7Hub.azure-devices.net; Device ID: MyF7Kit.
Here it seems as if nothing else happen. After a minute my router completely chokes, and I am not able to surf on the other computers connected behind my router. It seems to crash... I notice in router log-files the following two lines spamed:
Jan 20 22:59:48 [SSID] daemon.info dnsmasq-dhcp[101]: DHCPDISCOVER(br0) 00:11:22:33:44:56
Jan 20 22:59:48 [SSID]daemon.info dnsmasq-dhcp[101]: DHCPOFFER(br0) 192.168.1.194 00:11:22:33:44:56
I rely on the "Debug" build configuration in CubeIDE. I have not tried "Release". I notice that both netxduo and threadx projects are built with -Of or -Os. This makes it difficult to get good source code look-up with GCC/GDB so therefore I could not be sure if I was actually executing the functions the IDE told me I was debugging. Hence I re-compiled the netxduo and threadx with -Og.
Running again I get a bit further:
DHCP In Progress...
IP address: 192.168.1.194
Mask: 255.255.255.0
Gateway: 192.168.1.1
DNS Server address: 192.168.1.1
SNTP Time Sync...
SNTP Time Sync...
SNTP Time Sync...
SNTP Time Sync failed.
Set Time to default value: SAMPLE_SYSTEM_TIME.[INFO] Azure IoT Security Module has been enabled, status=0
IoTHub Host Name: MyF7Hub.azure-devices.net; Device ID: MyF7Kit.
[ERROR] IoTHub client connect fail: MQTT CONNECT FAIL status: 65669
Disconnected from IoTHub!: error code = 0x00010085
Failed on nx_azure_iot_hub_client_connect!
[INFO] Azure IoT Security Module has been disabled, status=0
Tried restarting the debug CPU, and now finally:
DHCP In Progress...
IP address: 192.168.1.194
Mask: 255.255.255.0
Gateway: 192.168.1.1
DNS Server address: 192.168.1.1
SNTP Time Sync...
SNTP Time Sync successfully.
[INFO] Azure IoT Security Module has been enabled, status=0
IoTHub Host Name: MyF7Hub.azure-devices.net; Device ID: MyF7Kit.
Connected to IoTHub.
Telemetry message send: {"Message ID":0}.
Receive twin properties :{"desired":{"$version":1},"reported":{"$version":1}}
Telemetry message send: {"Message ID":1}.
Telemetry message send: {"Message ID":2}.
Telemetry message send: {"Message ID":3}.
Telemetry message send: {"Message ID":4}.
I tried reseting the board a number of time and now it works reliably... Tried without debugger connected. Also works...
At this point I dont know what is wrong, just reporting my findings...
Could you help us to get more data? First, run the project 3 times with netxduo and threadx projects are built with -Of or -Os. Second, run the project 3 times with netxduo and threadx projects are built with -Og. Please record the output.
Just to clarify that if the SNTP time sync failed, it is expected that the connect to iot hub will fail. Sometimes SNTP time sync will fail, it depends on your network condition.
Hi,
If you want you can skip all my tests above and just skip to my conclusion at the bottom of this post :) But of course I paste my test results for your review and comparison...
To clarify both the netxuo and threadx was actually built with -Ofast in "Debug" in your package. In my first post I was confused if it was -Ofast or -Os or mixed between libraries. But I extracted a new copy to check the original .cproject-files. In Release these libraries use -Os. I have not tried Release at all..
Did the test scenarios requested and it seems like the behavior is systematic.
Here are the results:
============
SCERNARIO1 using -Ofast 4 times...
ATTEMPT1 with debugger:
DHCP In Progress...
IP address: 192.168.1.194
Mask: 255.255.255.0
Gateway: 192.168.1.1
DNS Server address: 192.168.1.1
SNTP Time Sync...
SNTP Time Sync successfully.
[INFO] Azure IoT Security Module has been enabled, status=0
IoTHub Host Name: MyF7Hub.azure-devices.net; Device ID: MyF7Kit.
... stuck here...
ATTEMPT2: without debugger only reset board:
DHCP In Progress...
IP address: 192.168.1.194
Mask: 255.255.255.0
Gateway: 192.168.1.1
DNS Server address: 192.168.1.1
SNTP Time Sync...
... stuck here...
ATTEMPT3: without debugger only reset board:
DHCP In Progress...
IP address: 192.168.1.194
Mask: 255.255.255.0
Gateway: 192.168.1.1
DNS Server address: 192.168.1.1
SNTP Time Sync...
SNTP Time Sync successfully.
[INFO] Azure IoT Security Module has been enabled, status=0
IoTHub Host Name: MyF7Hub.azure-devices.net; Device ID: MyF7Kit.
... stuck here...
ATTEMPT4 with debugger:
DHCP In Progress...
IP address: 192.168.1.194
Mask: 255.255.255.0
Gateway: 192.168.1.1
DNS Server address: 192.168.1.1
SNTP Time Sync...
SNTP Time Sync successfully.
[INFO] Azure IoT Security Module has been enabled, status=0
IoTHub Host Name: MyF7Hub.azure-devices.net; Device ID: MyF7Kit.
... stuck here...
============
Scenario2 using -Og on libs 4 times...
DHCP In Progress...
IP address: 192.168.1.194
Mask: 255.255.255.0
Gateway: 192.168.1.1
DNS Server address: 192.168.1.1
SNTP Time Sync...
SNTP Time Sync successfully.
[INFO] Azure IoT Security Module has been enabled, status=0
IoTHub Host Name: MyF7Hub.azure-devices.net; Device ID: MyF7Kit.
Connected to IoTHub.
Telemetry message send: {"Message ID":0}.
Receive twin properties :{"desired":{"$version":1},"reported":{"$version":1}}
Telemetry message send: {"Message ID":1}.
Telemetry message send: {"Message ID":2}.
...
ATTEMPT2 without debugger only reset board
DHCP In Progress...
IP address: 192.168.1.194
Mask: 255.255.255.0
Gateway: 192.168.1.1
DNS Server address: 192.168.1.1
SNTP Time Sync...
SNTP Time Sync successfully.
[INFO] Azure IoT Security Module has been enabled, status=0
IoTHub Host Name: MyF7Hub.azure-devices.net; Device ID: MyF7Kit.
Connected to IoTHub.
Telemetry message send: {"Message ID":0}.
Receive twin properties :{"desired":{"$version":1},"reported":{"$version":1}}
Telemetry message send: {"Message ID":1}.
Telemetry message send: {"Message ID":2}.
...
ATTEMPT3: without debugger only reset board:
DHCP In Progress...
IP address: 192.168.1.194
Mask: 255.255.255.0
Gateway: 192.168.1.1
DNS Server address: 192.168.1.1
SNTP Time Sync...
SNTP Time Sync...
SNTP Time Sync successfully.
[INFO] Azure IoT Security Module has been enabled, status=0
IoTHub Host Name: MyF7Hub.azure-devices.net; Device ID: MyF7Kit.
Connected to IoTHub.
Telemetry message send: {"Message ID":0}.
Receive twin properties :{"desired":{"$version":1},"reported":{"$version":1}}
Telemetry message send: {"Message ID":1}.
Telemetry message send: {"Message ID":2}.
...
ATTEMPT4 with debugger:
DHCP In Progress...
IP address: 192.168.1.194
Mask: 255.255.255.0
Gateway: 192.168.1.1
DNS Server address: 192.168.1.1
SNTP Time Sync...
SNTP Time Sync successfully.
[INFO] Azure IoT Security Module has been enabled, status=0
IoTHub Host Name: MyF7Hub.azure-devices.net; Device ID: MyF7Kit.
Connected to IoTHub.
Telemetry message send: {"Message ID":0}.
Receive twin properties :{"desired":{"$version":1},"reported":{"$version":1}}
Telemetry message send: {"Message ID":1}.
Telemetry message send: {"Message ID":2}.
...
==============
To narrow this down a little bit further I tried two more permutations of tests.
TEST1: Build threadx with -Ofast and netxduo with -Og
TEST2: Build threadx with -Og and netxduo with -Ofast
Here are the results:
TEST1 building threadx with -Ofast and netxduo with -Og
DHCP In Progress...
IP address: 192.168.1.194
Mask: 255.255.255.0
Gateway: 192.168.1.1
DNS Server address: 192.168.1.1
SNTP Time Sync...
SNTP Time Sync...
SNTP Time Sync successfully.
[INFO] Azure IoT Security Module has been enabled, status=0
IoTHub Host Name: MyF7Hub.azure-devices.net; Device ID: MyF7Kit.
Connected to IoTHub.
Telemetry message send: {"Message ID":0}.
Receive twin properties :{"desired":{"$version":1},"reported":{"$version":1}}
Telemetry message send: {"Message ID":1}.
Telemetry message send: {"Message ID":2}.
...
Used the reset in the debugger
DHCP In Progress...
IP address: 192.168.1.194
Mask: 255.255.255.0
Gateway: 192.168.1.1
DNS Server address: 192.168.1.1
SNTP Time Sync...
SNTP Time Sync...
SNTP Time Sync successfully.
[INFO] Azure IoT Security Module has been enabled, status=0
IoTHub Host Name: MyF7Hub.azure-devices.net; Device ID: MyF7Kit.
Connected to IoTHub.
Telemetry message send: {"Message ID":0}.
Receive twin properties :{"desired":{"$version":1},"reported":{"$version":1}}
Telemetry message send: {"Message ID":1}.
Telemetry message send: {"Message ID":2}.
TEST2 building threadx with -Og and netxduo with -Ofast
DHCP In Progress...
IP address: 192.168.1.194
Mask: 255.255.255.0
Gateway: 192.168.1.1
DNS Server address: 192.168.1.1
SNTP Time Sync...
SNTP Time Sync successfully.
[INFO] Azure IoT Security Module has been enabled, status=0
IoTHub Host Name: MyF7Hub.azure-devices.net; Device ID: MyF7Kit.
Used the reset in the debugger
DHCP In Progress...
IP address: 192.168.1.194
Mask: 255.255.255.0
Gateway: 192.168.1.1
DNS Server address: 192.168.1.1
SNTP Time Sync...
SNTP Time Sync successfully.
[INFO] Azure IoT Security Module has been enabled, status=0
IoTHub Host Name: MyF7Hub.azure-devices.net; Device ID: MyF7Kit.
==============
In conclusion the issue arises when building the netxduo with -Ofast. Why? I don't know. I leave that for someone else to figure out :)
thank you for detailed information , it is very helpful, we will figure out the root cause.
@Norlander , we are not able to reproduce the issue. As it may be related to GCC optimization issue (see here), we will change the optimization level to -Og in next release. As a workaround, could you change it in your local workspace? Thanks!