2020-03-13 11:51 AM
I am trying to get FOTA updates working with the IoT node kit and Azure.
I currently have v4.0.1 installed on the board. I uploaded v4.0.2 to an azure storage account where I created a blob and uploaded the file, then generated a blob sas url.
In my Azure application I created a command with the field name FirmwareUpdate with an input text field of URL. Below is the command history from Azure.
The device recognizes the firmware update request, but it has an error: "Err: Parsing the FOTA command searching Start File Path" (output below).
What does the error mean? I am using base software on the device and on the update file. Am I not properly storing the file to be uploaded in the cloud and generating a url for it?
Received firmware update request. Use package at: [https://something.blob.core.windows.net/fotafota/Azure_IoTCentral_BL.bin?something]
Err: Parsing the FOTA command searching Start File Path
IoTHubClient_LL_SendEventAsync accepted message [2] for
I also tried just using the URL without generating an SAS, and I get farther, but with a different error
Confirmation received for message [10] with result = IOTHUB_CLIENT_CONFIRMATION_OK
Received firmware update request. Use package at: [https://something.blob.core.windows.net/fota/Azure_IoTCentral_BL.bin]
Channel 1 for Timer 1 stopped
Download FOTA from: HostName=[something.blob.core.windows.net] Type=[Secure] port=[443] File=[/fota/Azure_IoTCentral_BL.bin]
Ok reported State [2]: Downloading
-->DeviceTwin CallBack [2]: Status_code = 204
Ok io_interface_description
Ok xio_create
onOpenCompleteFOTA
Ok xio_open
Err: xio_send
Err During FOTA... Sorry retry...
Ok reported State [3]: DownloadFailed
-->DeviceTwin CallBack [3]: Status_code = 204
Solved! Go to Solution.
2020-03-18 08:39 AM
In case anyone else runs into this.. there were a few things going on.
First, there apparently is an issue with the pre-built binaries that come with azure fp. If you open the project and do your own build it works OK.
Second, It matters where you are storing the binary. The particular spot in azure storage I was using wasn't working. Storing it in a blob service container worked.
The proper procedure is:
2020-03-13 12:25 PM
Digging into it more, when using just the url, it fails in tlsio_mbedtls_Stm32Cube_Nucleo.c, line 575,
if (tls_io_instance->tlsio_state != TLSIO_STATE_OPEN)
The tlsio_state is TLSIO_STATE_NOT_OPEN.
It looks like it is failing the handshake here because "an invalid ssl record was received"
static void on_underlying_io_open_complete(void* context, IO_OPEN_RESULT open_result)
{
TLS_IO_INSTANCE* tls_io_instance = (TLS_IO_INSTANCE*)context;
int result = 0;
if (open_result != IO_OPEN_OK)
{
xio_close(tls_io_instance->socket_io, NULL, NULL);
tls_io_instance->tlsio_state = TLSIO_STATE_NOT_OPEN;
indicate_open_complete(tls_io_instance, IO_OPEN_ERROR);
}
else
{
tls_io_instance->tlsio_state = TLSIO_STATE_IN_HANDSHAKE;
do {
result = mbedtls_ssl_handshake(&tls_io_instance->ssl);
} while (result == MBEDTLS_ERR_SSL_WANT_READ || result == MBEDTLS_ERR_SSL_WANT_WRITE);
if (result == 0)
{
tls_io_instance->tlsio_state = TLSIO_STATE_OPEN;
indicate_open_complete(tls_io_instance, IO_OPEN_OK);
}
else
{
xio_close(tls_io_instance->socket_io, NULL, NULL);
tls_io_instance->tlsio_state = TLSIO_STATE_NOT_OPEN; <---- HERE
indicate_open_complete(tls_io_instance, IO_OPEN_ERROR);
}
}
}
2020-03-18 08:39 AM
In case anyone else runs into this.. there were a few things going on.
First, there apparently is an issue with the pre-built binaries that come with azure fp. If you open the project and do your own build it works OK.
Second, It matters where you are storing the binary. The particular spot in azure storage I was using wasn't working. Storing it in a blob service container worked.
The proper procedure is: