I have an embedded device that downlopads firmware updates over the air via the DropBox API. Downloads worked fine yesterday, and fail today. The code has not changed since then, and I even went back to a revision built a few months ago, and it fails in exactly the same way. I am using a Texas Instruments CC3200 processor. I use the TI library for the OTA process. It can list the files in the repository, but when I try to access them via the link provided the device just hangs. It subsequently reboots. Here is some diagnostic output from the process.
sl_extLib_OtaRun: call OtaClient_ConnectServer OTA server=api.dropbox.com
OtaClient_ConnectServer: http_connect_server api.dropbox.com
[00:00:11.0967] OTA run (0)
sl_extLib_OtaRun: OtaClient_UpdateCheck, vendorStr=3.2.0
OtaClient_UpdateCheck: call http_build_request /1/metadata/auto/
metadata file=/3.2.0/f00_sys_servicepack.sig, size=256
metadata file=/3.2.0/f43_sys_servicepack.ucf, size=31348
metadata file=/3.2.0/f80_sys_mcuimgA.bin, size=151300
metadata file=/3.2.0/f80_www_logo.png, size=18406
metadata file=/3.2.0/f80_www_main2.html, size=5830
sl_extLib_OtaRun: OtaClient_UpdateCheck, numUpdates=5
[00:00:12.0260] OTA run (0)
sl_extLib_OtaRun: OtaClient_GetNextUpdate: file=/3.2.0/f00_sys_servicepack.sig, size=256
OtaClient_ResourceMetadata: call http_build_request /1/media/auto
OtaClient_ResourceMetadata: file flags=0,metadata flags=0
OtaClient_ResourceMetadata: remove old signature file /sys/servicepack.sig
[00:00:12.0556] OTA run (0)
sl_extLib_OtaRun: ResourceMetadata CDN file URL = https://dl.dropboxusercontent.com/apitl/1/AAAPogfVrgUuU60x7jjBJL-jMrYmSHG0O8Gb_ReadFileHeaders: domain=dl.dropboxusercontent.com, file=/apitl/1/AAAPogfVrgUuU60x7jjBJL-jMrYmSHG0O8GbVwAf7iHMQOISR2yPAH3YGlgsUr
After the last line the device hangs until the system watchdog reboots it, then the process repeats. Any idea what I might be running into?
It looks like the call to /2/files/get_temporary_link itself is succeeding, since it is showing the retrieved /apitl link. It looks like the log might be cut off unfortunately though.
I just retrieved an /apitl link from /2/files/get_temporary_link myself and it seems to be working. Can you get a fresh one from your app and try it manually (perhaps with any additional verbose logging possible) to see if it's working on your side, or what it's returning that might be causing issues in your app?
What I have seen on my side is that the filename returned is 553 bytes in length. The TI code has a buffer length of 512. This would most certainly cause an issue. How big is the url you received when you retrieve the apitl link?
Thanks in advance,
Thanks for the additional information.
The length of the returned link can depend on the length of the original file path (as well as potentially other factors), so we can't guarantee any particular maxmimum length unfortunately. (For reference, mine is also coming out longer than 512 bytes.)
So, this may have just been a result of the file path getting longer and resulting in a URL larger than that buffer size. I'm afraid I don't have a solution on the API side, since the link can be expected to get that big. Are you able to increase the buffer size?
In future revisions most likely. This does not bode well for any devices already out in the field. I will work on fixing TI's code and see what I can do. Thank you for the help.
I have faced the same problem. There are over 3K of our devices out in the field and we are helpless at this point of time. The size of link until last week was less than 400 bytes and we suddenly see it crossing 550 bytes. We have provided OTA for these 3K devices atleast Twice as of now and no issues until 2 days back.
It will be really helpful if Dropbox can help us by reducing this link length to less than 400 bytes like before for time being or for a few weeks. Meanwhile, We will work towards updating the firmware remotely and resolve this issue in the existing hardware.
Appreciate your earliest support in this regard.
@BAB1 No, unfortunately we can't administratively change the length of that link.
The length of these links can depend on the original file path though, so one solution may be to make that file path as short as possible, in order to get the resulting link short enough to fit in your buffer.
Just tried your suggestion of reducing the file path. It doesn't seem to be effecting the length of link. I am still getting it over 500 bytes. Can you please help me understand how this length has changed only in the last Two days and was less than 400 bytes in the last One year ? Unfortunately my options are Zero with regard to ability to change anything in the firmware of the hardware in field right now. The entire access to the end hardware is now blocked.
Can you please suggest any further alternatives ?