05-03-2018, 10:18 PM
I changed the location of the line:
to be after the initial GET operation.
Also changed the log properties as suggested.
Magic byte:
In both the FireFox and the Config App cases I am choosing the exact same file for transfer.
I checked the log for the start and end of the file transfer data and verified that these are the same as the binary start and end bytes of the file itself. Could not check the length of the data though.
The start byte of the binary file is actually the E9 (magic byte).
I agree that the feedback indicates that a byte is not arriving as it should, but I cannot understand how that can happen since the source file is the same in both cases. And the submitting form is simplicity itself, I can see nothing there that can affect how the file data are modified...
OTOH, the destination function inside the IoT device will do the following during/after receiving the data:
- Write the file data into flash memory at a scratch location
- Check an MD5 checksum to verify that the file is unaltered
- Check the validity of the firmware (I don't know how, maybe the magic byte...)
- If OK send back a response containing a success message and a reload command with a timeout of about 20 s
- Jump to a special reset function that will overwrite the active flash memory from the scratch area
- Reset the device to make it start with the new firmware
This finalization function seems to not execute and therefore the old firmware remains in flash memory and keeps running.
Should I add a final GET in order to retrieve the result data being sent back, or is that already part of the HTTP.Post function?
Later:
I opened the logfile and the binary flash file in HxD to check the contents.
The bin file starts with the E9 magic byte and it is 304464 bytes in size.
The bin file ends with this sequence: 0C FF 3F 00 00 00 CA
In the log file I find the E9 start byte in address $274 (628 decimal)
And the ending sequence is located with CA at address 4A814
So if I calculate the transferred file data length I get 4A814 +1 - 274 = 4A5A1 (or 304545 decimal)
This means that the data transferred are 81 bytes too many....
There seems to be inserted bytes within the file body.
Or else these are protocol inserted bytes?
Code:
HTTP.Request.Referer := URL;Also changed the log properties as suggested.
Magic byte:
In both the FireFox and the Config App cases I am choosing the exact same file for transfer.
I checked the log for the start and end of the file transfer data and verified that these are the same as the binary start and end bytes of the file itself. Could not check the length of the data though.
The start byte of the binary file is actually the E9 (magic byte).
I agree that the feedback indicates that a byte is not arriving as it should, but I cannot understand how that can happen since the source file is the same in both cases. And the submitting form is simplicity itself, I can see nothing there that can affect how the file data are modified...
OTOH, the destination function inside the IoT device will do the following during/after receiving the data:
- Write the file data into flash memory at a scratch location
- Check an MD5 checksum to verify that the file is unaltered
- Check the validity of the firmware (I don't know how, maybe the magic byte...)
- If OK send back a response containing a success message and a reload command with a timeout of about 20 s
- Jump to a special reset function that will overwrite the active flash memory from the scratch area
- Reset the device to make it start with the new firmware
This finalization function seems to not execute and therefore the old firmware remains in flash memory and keeps running.
Should I add a final GET in order to retrieve the result data being sent back, or is that already part of the HTTP.Post function?
Later:
I opened the logfile and the binary flash file in HxD to check the contents.
The bin file starts with the E9 magic byte and it is 304464 bytes in size.
The bin file ends with this sequence: 0C FF 3F 00 00 00 CA
In the log file I find the E9 start byte in address $274 (628 decimal)
And the ending sequence is located with CA at address 4A814
So if I calculate the transferred file data length I get 4A814 +1 - 274 = 4A5A1 (or 304545 decimal)
This means that the data transferred are 81 bytes too many....
There seems to be inserted bytes within the file body.
Or else these are protocol inserted bytes?