1 2 Previous Next 24 Replies Latest reply on Feb 4, 2016 4:52 AM by ghalibjanjua Go to original post
      • 15. Re: firmware programming through FTDI VCOM 22 to BCM20736S

        HI Jacob,

         

        Thanks a million for your reply.

         

        VDD_IO is 3.0V for UART to operate at 3.0V.

        Initially UART was also at 1.8V then what I understood from your reply is 1.8V is less so I raised the UART to 3.0V keeping BCM20736S power at 1.8V, Is it OK?

         

        Kind Regards,

        Ghalib

        • 16. Re: firmware programming through FTDI VCOM 22 to BCM20736S
          JacobT_81

          If you are still using the same FTDI chip, put 5v on VDDIO and 3.3v on VDD_1.8.

           

          Then on VDD_C put 3.3v.

           

          Please attempt the recovery process at these voltage levels.

           

          Are you following the exact recovery process? What do you see on UART traces when you attempt it?

          • 17. Re: firmware programming through FTDI VCOM 22 to BCM20736S

            Hi JacobT_81

             

            I just noticed that you suggest to pull high the UART_RX line to enter programming mode. Why is this needed? All the suggested reference designs have this line pulled low.

             

            Regards

            Marco

            • 19. Re: firmware programming through FTDI VCOM 22 to BCM20736S
              MichaelF_56

              Remember that When sampled on RESET only:

               

              HCI UART Rx = High (Programming mode)

              HCI UART Rx = Low (Application mode)

               

              From RESET, the boot sequence for the BCM2073XS series essentially follows the process defined below:

               

              1.

              Code in ROM executes and initializes the device processor, clock domains, peripherals, etc. 

               

              2.

              The following checks then occur:

               

              2a.

              Boot ROM checks EEPROM for a valid configuration

              And if not found

              Boot ROM then checks Serial Flash for a valid configuration

               

              If a valid configuration is found in either location and HCI_UART RX  is NOT asserted, the Boot ROM will continue to load the rest of the configuration, patch and user application code.

               

              At this point, the part comes up in application mode running the previously programmed application.

               

              Note: In addition, if HCI_UART RX  is asserted, the part will still come up in programming mode, even though a valid configuration was found.

               

              2b.

              If no valid configuration was found, the next step depends on whether the HCI_UART RX pin is asserted or not:

               

              • If HCI_UART RX  is asserted, the part enters recovery mode

              • If HCI_UART RX  is NOT asserted, the ROM will assume all default configuration settings and then boot up into download mode

               

              JacobT_81

              • 20. Re: firmware programming through FTDI VCOM 22 to BCM20736S

                Thanks for this clear explanation. Maybe I'm missing something though. On all reference designs there is no way to pull up UART_RX. After reset this is always pulled low by a 10k resistor.

                 

                Regards

                Marco

                • 21. Re: firmware programming through FTDI VCOM 22 to BCM20736S

                  Also is there some documentation describing these mechanisms clearly?

                   

                  Regards

                  Marco

                  • 22. Re: firmware programming through FTDI VCOM 22 to BCM20736S
                    MichaelF_56

                    Kits like WICED Sense were designed for demo purposes, so those need to come up in Application mode. If you want to program them, you need to crack the case and reset the device.

                     

                    So per the TAG3 board schematic in the Hardware User Guide (SDK 2.x and TAG3 Board), you will notice that SW5 on the TAG Board applies VDDIO to the SDA pin on the EEPROM, preventing the device from reading the image stored in the EEPROM and forcing it into programming mode (insert this into the boot logic I provided earlier).

                     

                    So 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.

                     

                    However, you will find comments in other posts which imply that you can also GND the SDA pin and see the same behavior.

                     

                    This works as well and is probably a better choice since 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.

                     

                    So 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.

                     

                    The forums are the only place where these things are documented.

                     

                    JacobT_81

                    • 23. Re: firmware programming through FTDI VCOM 22 to BCM20736S

                      Hi, thanks for this answer. This clarifies everything.

                       

                      Regards

                      Marco

                      • 24. Re: firmware programming through FTDI VCOM 22 to BCM20736S

                        Hi Jacob,

                         

                        Thanks a million for your help and kind cooperation, problem  got solved.

                         

                        Kind Regards,

                        Ghalib

                        1 2 Previous Next