7 Replies Latest reply on Aug 25, 2014 8:29 AM by userc_2031

    OTA ws_verify() is failing

      Hi,

      I'm using SDK2.1 and I'm trying to test out OTA (non-secure) functionality. I've installed BTW and have the plugable dongle suggested on the forum. My board is the EMRF-2036S-BOB board which uses the BCM920736SA1 chip. I can successfully flash my board and connect to my windows machine. However, when I go and run

      WsUpgrade.exe ota_firmware_upgrade-BCM920736TAG_Q32-rom-ram-Wiced-release.ota.bin

      I always end up with a CRC check that fails on ws_verify() (the packets seem to get downloaded just fine) and the OTA aborts.

       

      Do you have any idea why I might be having these issues? Here is the 20736_EEPROM.btp file I am using (straight out of the box)

       

      DevicePreset "20736 EEPROM (64 byte pages)"

      {

        ConfigFSOffset = 0

        DLReadWriteMode = "Cortex M3 HCI"

        DLWriteVerifyMode = "Write and verify"

        DLMaxWriteSize = 64

        DLSectorEraseMode = "Chip erase"

        DLDTRReset = 0

        DLPostResetDelay_ms = 100

        DLAutobaud = 0

        DLAutobaudRepeat = 1

        DLAutobaudRepeatDelay_ms = 200

        DLWaitForLaunchAnnounce = 0

        DLConfigReprogramIF_PLL = 0

        DLUsbBulkPipe = 0

        DLMinidriver = 1

        DLMinidriverPathUSB = "[MINIDRIVERS]\20732\usb.hex"

        DLMinidriverPathNET = "[MINIDRIVERS]\2072\uart.hex"

        DLMinidriverPathSDIO = "[MINIDRIVERS]\2072\sdio.hex"

        DLMinidriverPathUPRX = "[MINIDRIVERS]\20732\uart.hex"

        DLMinidriverPathUART = "[MINIDRIVERS]\20732\uart.hex"

        DLFirmware = 0

        DLFirmwareTargeting = "Standard"

        DLConfig = 1

        DLConfigTargeting = "EEPROM"

        ConfigPath = "[BTP_FOLDER]\A_20732A0-hello_sensor-rom-ram-spar.cgs"

        DLConfigFixedHeader = 1

        DLConfigFixedHeaderFromBurnImage = 0

        DLConfigOmitRF_PLL = 1

        DLConfigIncludeChargerConfig = 0

        DLConfigDFUKey = 4294967295

        DLConfigCrystalFreqMHzX10000 = 240000

        DLConfigOutputPowerAdjust = 40

        DLConfigImpedanceMatchTuning = 31

        DLConfigSerialControlBaudRate = 115200

        DLConfigEEPROMAccessSpeed = 100

        DLConfigVSOffset = 0

        ConfigDSLocation = 1408

        DLConfigSSLocation = 0

        DLConfigIncludeBTWSecurityKey = 0

        DLConfigVSLocation = 320

        DLConfigVSLength = 1024

        DLConfigRemoteDeviceCount = 0

        DLConfigBD_ADDRBase = "20736A1*****"

        DLConfigFixedBD_ADDRFlag = "Can change"

        OTAFWUAckAllRecords = 0

        OTAFWUUpdateFirmware = 1

        OTAFWUUpdateConfig = 1

      }

       

      And here is my ws_upgrade.c settings

       

       

      const WS_UPGRADE_NV_LOC_LEN nv_loc_len[2] =

      {

          {

              /* .ss_loc = */     {0, 256},

              /* .ds1_loc = */    0x580,         // ConfigDSLocation

              /* .ds1_len = */    0x7A00,        // ~31KB

              /* .ds2_loc = */    0x8000,

              /* .ds2_len = */    0x7A00,        // ~31KB

              /* .vs1_loc = */    0x140,         // DLConfigVSLocation

              /* .vs1_len = */    0x400,         // DLConfigVSLength

              /* .vs2_loc = */    0,             // No VS2 for EEPROMS

              /* .vs2_len = */    0              // No VS2 for EEPROMS

          },

          // We are assuming that we have a 64KByte Serial Flash. If the SF is larger, you may change ds1_len, ds2_loc, ds2_len

          // accordingly.

          {

              /* .ss_loc = */      {0, 0x1000},

              /* .ds1_loc = */     0x4000,          // ConfigDSLocation

              /* .ds1_len = */     0x6000,

              /* .ds2_loc = */     0xA000,

              /* .ds2_len = */     0x6000,

              /* .vs1_loc = */     0x2000,          // DLConfigVSLocation

              /* .vs1_len = */     0x1000,          // DLConfigVSLength

              /* .vs2_loc = */     0x3000,

              /* .vs2_len = */     0x1000

          },

      };

       

      thank oyu,

      akbar

        • 1. Re: OTA ws_verify() is failing
          MichaelF_56

          Sorry, but I'm not familiar with the EMRF-2036S-BOB board?

           

          Found it: http://www.cdiweb.com/datasheets/embedded/EMRF-BCM20736S-BOB-UserManual.pdf

          • 2. Re: OTA ws_verify() is failing

            Hi,

            This is the board I'm using. It was recommended to us by a rep from Broadcom.

             

            http://www.cdiweb.com/datasheets/embedded/EMRF-BCM20736S-BOB-UserManual.pdf

            • 3. Re: OTA ws_verify() is failing

              Hi Adhanali,

                I have tested the OTA Firmware upgrade and ran it over 50 times using SDK2.1 and the same hardware you have.  These tests were performed using WIN7 on a 64bit machine.  Can you let us know what specific OS you are using?  I will say I have observed a bit of what I would call unexplained behavior but I have successfully been able to do the OTA upgrade at a pretty high success rate.  I have pointed out my observations below...

               

              1)  I noticed that sometimes when I added the BLE Slave to the PC it would sometime show several 'Bluetooth Peripheral Devices' under the 'Other Devices' heading in Device Manager.  I verified they were all the same as the all had the same 20736A1xxxxx device address.  You can view this if you right click on the 'Bluetooth Peripheral' in Device Manager and go to the 'Details' tab and select 'Bluetooth Device Address' on the Drop-Down menu.  At this point the OTA was rather flaky and was working at best 1 out of every 7 times.  I had 4 devices showing up here I deleted all of them except for 1.

              2) I also noticed by simple luck that for some reason when the Green Bar would hang/stall a bit during the OTA upgrade that if I pressed the P0 button(assuming that is the Button you have configured for your Interrupt Button) all of a sudden the Transfer would resume and in almost every case was successful.  I experimented with this numerous times and there is definitely some sort of interaction with the P0/Interrupt occurring when the transfer(Green Bar) stalls that helps the transfer along?  This is something we will need to investigate a bit.

               

              I would be glad to do a Webex Session with you tomorrow if you would like. 

               

              Regards,

              Frank

              • 4. Re: OTA ws_verify() is failing
                ShawnA_01

                Is the "P0" button on the BOB board, the actual P0 pin on the module? 

                 

                As you may recall, there can sometimes be strange interactions with the P0 pin and the keyscan operation when the device is trying to go to sleep.  (there are forum entries that tell you how to know if sleep attempts are being aborted)

                 

                My first test would be to ensure sleep is disabled and see what the results are.  If turning off sleep fixes it, ... then I'd re-enable sleep, and make sure there is a pullup on the P0 pin so keyscan doesn't bite you.

                1 of 1 people found this helpful
                • 5. Re: OTA ws_verify() is failing

                  Hey Shawn,

                    Thanks for the input though from what I understand about the Keyscan and P0 scenario this is a scenario that can 'prevent' the device from going to Sleep or Deep Sleep because the Keyscan was trying to read the port not allowing the device to go to sleep.  This is a scenario where the Device is already awake.  Am I missing something?  P0 does actually connect to P0 on the EMRF-2073xS-BOB's in which I have also tested this using Sleep enabled and disabled and using the TAG3 board and the same situation occurs regardless of hardware.

                   

                  I have also changed the GPIO_PIN_BUTTON to P4 versus P0 in platform.h and occassionally when the transfer bar will stall pressing the P4 button on the EMRF produces the same result in that the Progress bar will immediately resume. 

                  BCM92073x_LE_KIT(TAG3) board does not provide another option for a Button press so I could not test it on that.

                   

                  NOTE:  Initially I could not get the the Button Press change in platform.h to take hold in SDK2.1 in which after doing a 'clean' by pressing the clean Green Bullseye the change for the GPIO_PIN_BUTTON did take hold.

                   

                  Regards,

                  Frank

                  • 6. Re: OTA ws_verify() is failing

                    Turns out my issue was that I was running WsOtaUpgrade.exe off of a virtual machine running Windows 7 x64 rather than running it off of a native Windows machine. (My setup is Windows 7 x64 running on Parallels 9 for Mac, which is running Mavericks). Once I tried running it on a native Windows 7x64 machine everything started to work. Does anyone know why running it off a Virtual Machine would be causing me this issue? Thanks!

                    • 7. Re: OTA ws_verify() is failing

                      Hi Adhanali,

                        It is difficult to say I am sure it has something to do with either the WIDCOMM BT Drivers themselves or potentially the OTA Executable as to how they are being translated.  I would report this to Parallels 9 if you have not already as this is certainly something I would expect they would want to understand on their side of the coin.  Thanks for giving the WIN7 machine a shot to weed out that variable.

                       

                      Regards,

                      Frank