4 Replies Latest reply on Jan 31, 2017 7:20 AM by chinc_1881431

    SOTAFU Failed Verification


      I used the instructions in the "WICED-Secure-Over-the-Air-Firmware-Upgrade.pdf" document and the example code from "ota_secure_firmware_upgrade" to add secure over the air firmware upgrade to my project.  I believe I've followed all the required steps and added all the required code and hooks to my project.  However, when I attempt to do a firmware upgrade using the WsSecOtaUpgrade.exe application, I see the progress bar get nearly to the end, only to fail with a "Verification Failed" error.


      I'm not really too sure where to look to solve this one.  Any guidance you can provide would be greatly appreciated.



      Chris Ingraham

        • 1. Re: SOTAFU Failed Verification



          In the same app note above, it was pointed out explicitly on pg 6 that verification will fail unless the below 3 conditions are met:


          1) RSA verification must pass: access to the private key is required to create the new firmware image.

          2) The product ID of the new image must match that of the existing application.

          3) The major version number must be the same or greater than that of the existing application.


          Did you meet the above terms?


          Are you doing this on your product board or the tag3 eval board?


          You may also refer to the below doc link on how to use the wssecotaupgrade.exe with a standard BT dongle.


          How to do OTA: Step by Step with PDF by  embeddedmasters

          1 of 1 people found this helpful
          • 2. Re: SOTAFU Failed Verification



            Sorry it took so long to get back to this.  However, I reviewed the information you pointed out above and I believe I have met all the requirements/terms you mentioned.  I did see that in the documentation so I was sure to follow those requirements.


            I am attempting to do this on my own product board.  We have a version of this firmware working that did not support SOTAFU and I was trying to add this feature.  I am confident that Broadcom part is functioning properly as I am able to discover and start the firmware upgrade process.  It seems that it only fails in the verification phase.


            I did look at the "How to do OTA:  Step by Step with PDF" that you mentioned.  I did not see where it addressed an issue with failing verification.  In fact, that document describes the normal OTA firmware upgrade, not the "Secure" version that I am trying to use.


            Is there any other information you need from me?  Can you think of some other thing I should try?



            Chris Ingraham

            • 3. Re: SOTAFU Failed Verification

              What is the part number that you are using? 20737S?


              Assuming you are using 20737S, it will have a 64KByte eeprom. I assumed you have ensured that your app code size is below 32Kbyte.


              I was checking out the sample code on my Tag3 board and I did not find anything unusual. The only time I encountered a verification failure was when I deliberately set the major version to less than that of the existing one. I executed the WsSecOtaUpgrade from a command prompt and performed the OTA with the help of a BCM20702 USB Bluetooth Dongle.


              Can you perform and verify this on a tag3 eval board?

              1 of 1 people found this helpful
              • 4. Re: SOTAFU Failed Verification

                I believe I have finally found the problem.  I was very carefully following the documentation to set this up.  The "WICED-Secure-Over-the-Air-Firmware-Upgrade.pdf" file describes the procedure in detail but leaves out one critical piece of information.  It appears that the function "ws_upgrade_ota_init()" must be called as part of the application's xxx_Create function.  This was not described in the documentation and I only found it after very careful line-by-line comparison of the differences between my application and the "hello_sensor.c" application.  All other source code additions and GATT database changes are included in the documentation.  However, this function call to initialize the ws upgrade system is essential to get the thing working.


                I know it sounds pretty obvious once discovered, but that was the root cause of the issue.  A simply addition to the documentation would really help prevent this issue in the future.

                2 of 2 people found this helpful