Is it possible for a running embedded application to upgrade itself (using the adl_adInstall function) if the new .DWL application is already contained in a A&D Storage cell.
Yes - that is the purpose of the adl_adInstall function! 8)
Thanks, good to know. Well, when I load the content of the .DWL file (binary) into a cell, finalize and then install, the ADL_AD_EVENT_INSTALL notification occurrs, and module resets. Old application still starts and adl_adGetInstallResult returns ADL_AD_RET_ERR_UPDATE_FAILURE. Can you confirm that my understanding of the process is correct?
Yes, that’s the correct process.
That’s correct: If the update fails, the old application should still run.
Presumably you get a similar indication in the InitType parameter of adl_main?
Most likely, the new application image is getting corrupted somewhere in the transfer.
Does the same .dwl file load correctly via AT+WDWL ?
BTW: I did once have a .dwl file that would load correctly via AT+WDWL but not via DOTA - but this has only ever happened once in many years.
(it appeared to be a glitch in the build system - it worked after a rebuild).
I have written an application to calculate the CRC16-CCITT on the .DWL file content before transmitting the file to the A&D Cell. I have also modified my embedded application to step through each byte in the to be installed Cell calculating the content’s CRC16. These CRC’s are exactly the same, indicating that the content has been successfully transferred into the cell. There must still be something that I am missing? I am at a loss! Any ideas?
I can add that using XMODEM to download the same .DWL file results in the module being reprogram as expected.
Hiya,
I’m wondering it you have hit an endianness issue when transferring the data down to the A&D cell?
Can you transfer write a known sequence of bytes to the A&D cell, then read it back and see if the endianness is the same…
Just my two cents worth…
ciao, Dave
If you use protocol like XMODEM it is possible that loaded DWL expanded by some garbage bytes - its because of 128 bytes multiplication of filesize in old OS from which xmodem came from. This “tail” also can produce effect like you mention in some cases - OS check loaded image before installing and consider it broken.