6 Replies Latest reply on Nov 10, 2017 12:05 AM by BoonT_56

    recovery option on 20737S



      We have gotten too frequently programming failure and recover them with recovery option on our custom board, so we have 2 questions about recovery option.

      1. what different between usual programming and recovery option one from device behavior perspective?

      2. is there any side effect expected when using recovery option as usual programming procedure in line?


      Thank you,

        • 1. Re: recovery option on 20737S

          Normally upon boot up, the module will load the application from its eeprom onto the ram for processing. If the the application is corrupted, then the module will hang. In this case, we shall initialize the recovery option, by first preventing the 737 from loading the corrupted image. This is done so by "disabling" the eeprom temporarily, and in so doing caused the 737 to move on to its next option which is boot-from-ROM. After which we will proceed the download process again with the -recovery option.


          1) There is no difference in the electrical behavior. It is just another method to re-download a copy of the app onto the eeprom.

          2) No side effect.


          The only thing is the INCONVENIENCE of doing the recovery. It can be very disruptive on the production line.


          I noted that you have mentioned it happened frequently. You may want to check the powering up process of the module to get itself ready for a download. You must see the two COM ports in the device manager.

          • 3. Re: recovery option on 20737S

            Hi BoonT_56


            Thank you for your answer and advice.

            Let me add another question on it.


            Checking powering up process is pointed out though, do you have any powering up profile or recommended waiting time to start programming after powering up?

            • 4. Re: recovery option on 20737S

              I don't have a powering-up profile. But I observed that if one were to program the module (almost) immediately upon powering up, it may failed occasionally. I guessed the Win OS may need 0.5s to 1s or so to initialize and assign the com ports. An analogy would be to observe the time taken for a USB thumbdrive to boot up when we insert them into the PC. If we record 20 times, there could be a small spread.


              Just some food for thought. Feel free to contact my counterpart below in your region for technical support.



              1 of 1 people found this helpful
              • 5. Re: recovery option on 20737S

                Hi batta,


                Thank you for your answer.

                0.5-1 sec is reasonable waiting time, let us check our programming station.


                let me add 2 other questions.

                1. You said corrupted application in eeprrom is the route cause though, is factory test application in cypress or something already written when the ic/module is delivered to us?


                2. what is the route cause of the corrupted application? does it happen after the final product is delivered; at end user?




                • 6. Re: recovery option on 20737S

                  Usually there is nothing wrong with the target application as you would have test it many times in your development on a eval board. It is in the writing of the application into the eeprom that can go wrong. For example, a "1" written as "0" is enough to create havoc, and vice versa. Strictly, there is a small code that resides in the eeprom when the module is delivered. The code is for the module to enter Test Mode before it pass QA and ship out. For practical purposes, you can assume the epprom is good and "empty" when deliver to you.

                  1 of 1 people found this helpful