This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
I plan to run an HTTP server on my CC3235SF prototype. Part of the product will be OTA upgrade. I will use my HTTP server to allow the user to upload the new load. I can store the load in flash.
Once upload is completed, I would like to point the Local OTA reference design to that file so it can then do the upgrade.
Does anyone know where that "entry point" might be into the Local OTA reference design? I do not wish to employ the reference design "as is" because of the state machine, etc. I might be forgoing a few of the safety features, but it would be suitable for my target market.
If anyone has done that, any hints would be appreciated.
Thanks!
Hi,
Approach with uploading whole TAR file into sFlash and after that processing OTA code will probably not work. Because you can expect issue with insufficient space inside sFlash. Usage of ota_archive.h/c files on the fly without whole TI state machine works pretty well. I use this local OTA code with my own http server (server at application processor not NWP). I still need to use state machine, but it is my own and it is much simpler than in TI local OTA example.
As web frontend I use code which reads file via FileReader() javacript object and content of this file send back into CC3220 by 10kB chunks via XMLHttpRequest().
What you need to do:
unproc = size_of_incoming_block_via_http; proc = 0; // process incoming block while(unproc > 0) { retCode = OtaArchive_Process(&otaArchive, &buff[proc], (short int)unproc, &tmp); unproc = unproc - tmp; proc = proc + tmp; // error if (retCode != 0) break; } // OTA processes done if (retCode == ARCHIVE_STATUS_DOWNLOAD_DONE) { // here restart SoC sl_Stop(200); sleep(200); MAP_PRCMHibernateIntervalSet(330); MAP_PRCMHibernateWakeupSourceEnable(PRCM_HIB_SLOW_CLK_CTR); MAP_PRCMHibernateEnter(); } // error during OTA process if (retCode < 0) { }
if ((retVal = OtaArchive_GetPendingCommit()) < 0) { // error } if (retVal > 0) { // commit if ((retVal = OtaArchive_Commit()) < 0) { // commit error } else { // commit done } }
Steps above are procedure which you need to do inside local OTA code. Full implementation into your code is up to you. In case of any question feel free to ask. But do not expect that I will wrote full implementation for you.
Jan
Excellent, thanks, Jan. I already have the client-side javascript working on another project to pace the uploading of a file in chunks at the rate the server accepts, so that should not be a problem for me. I sincerely appreciate your outline and taking the time to explain it. I think this could really help a lot of designers out there. It will give me something to go on.
I have the upload working. Your hints were quite critical in getting this to work. Things I found are:
1) At the start, I needed to call:
OtaArchive_Init(&gOtaArchive);
OtaArchive_CheckVersion(&gOtaArchive, (uint8_t*) filename)
Hence, I needed my client-side javascript (which employed chunked upload via XMLHttpRequest) to upload the filename as one of the parameters.
2) As you eluded to, each call to the function OtaArchive_Process() returns the number of unprocessed bytes. These need to be added to the beginning of the next chunk fed to the function.
3) Once the uploaded data is complete (ARCHIVE_STATUS_DOWNLOAD_DONE is returned), a reboot is done as you suggested.
4) Upon reboot, my main() function calls OtaArchive_GetPendingCommit(), and if it returns >0, then OtaArchive_Commit() is called. The NWP needs to be started for this to work, of course.
By doing this, the scope is limited and understandable. I didn't have to debug the state machine in the local_ota example. However, the functions, above, are needed. It behooves any designer to know a little about javascript XMLHttpRequest for this to work if he spins his own client side code (like I did). There are a lot of good examples on the net.
So, all in all, quite successful. Thanks again!
Hi,
Glad to hear that you was able to implement local OTA.
But be aware you should not use OTA TAR file to upload your secret (e.g. private keys), unless you not have own encryption above TAR file.
Jan