4 Replies Latest reply on Feb 25, 2015 4:23 AM by dmiya

    CRC mismatch on BCM20737S

      I'm facing download failure issue and the end of log is below.


      Downloaded 0 code bytes ( 0.0%) and 21704 data bytes (100.0%). Verified 0 code bytes ( 0.0%) and 0 data bytes ( 0.0%).   Current state: Terminated with error


      A total of 2 contiguous memory areas were filled:

      [FF000000..FF000027] DATA (40 bytes)

      [FF000580..FF005A1F] DATA (21664 bytes)

      CRC mismatch while checking 21664 bytes starting at address 0xFF000580; host computed 85F30710, firmware computed C70C6F27



      I use ChipLoad.exe with below options.





      The board can be programed successfully by other firmware like hello_sensor.

      Any advice please?

        • 1. Re: CRC mismatch on BCM20737S

          Custom board with your own custom application? If yes, does the same procedure work when using the TAG3 board? Chipload is running on a PC?

          • 2. Re: CRC mismatch on BCM20737S

            Yes, it's happened only with custom application and custom board.

            If I program same custom application to TAG3 board or other board(different design), it works.


            I'm also able to program different application to custom board.


            ChipLoad.exe runs on my Windows7 PC.

            • 3. Re: CRC mismatch on BCM20737S

              How are you managing HCI RX on the board that is failing?  Also, are there multiple sensors on the I2C bus (i.e. loading issue)?


              Essentially, with regards to I2C on boot, if VDDIO is present on SDA during boot up, then the firmware bypasses the step where it looks to the EEPROM for a valid image and goes directly into programming mode (Re: How can BCM20732S boot from ROM?)


              However, the previous entries in this post seem to imply that you can also GND the SDA pin and see the same behavior: Re: Re: How can BCM20732S boot from ROM?


              Connecting SDA to Vdd/Vio to recover is probably not optimal for the following reason provided to me by one of the senior firmware engineers.


              SCL and SDA are both open-drain configuration and the pull-ups pull the signal high while the HW drives it low (never drives high, but floats the output pad leaving the pull-up to pull the line high). If you put a scope to either of these lines on the board when the firmware accesses these, you will see that high to low transitions will be very sharp while low to high transitions will be pretty slow due to the intrinsic RC.


              If you connect SCL/SDA to Vdd, then when the HW block drives SDA low, there will be a direct short (though momentary) between Vdd and GND, which is not ideal (even if the recovery works fine). This will happen pretty early during boot because the ROM always uses 0xA0 as the slave address of the EEPROM and you can see that there are repeated 0s in this sequence (and the shorts) which could do bad things to the supply or the chip.


              Shorting to GND on the other hand, is safer because that is what happens when there is a 0 bit on the bus and there is a 10K pull-up which will limit the current to something within the max ratings of all components on this line.

              • 4. Re: CRC mismatch on BCM20737S

                How big is your EEPROM? I hope it is at least 32 KBytes? The SS CRC was OK but the DS CRC failed. If your EEPROM is 16KBytes, it will wrap around and corrupt things because your app is ~21K.

                1 of 1 people found this helpful
                • 5. Re: CRC mismatch on BCM20737S

                  mwf_mmfae, arvinds,


                  Thank you for your help. This issue is resolved.

                  Some devices are connected to same I2C bus.

                  BOOT still connects SDA to VDD. But thank you for the information.

                  Internal EEPROM is 512kbit since I'm using BCM20737S module.

                  Anyway, it's resolved. Thank you again.