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?
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?
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:
Code in ROM executes and initializes the device processor, clock domains, peripherals, etc.
The following checks then occur:
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.
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
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.
Also is there some documentation describing these mechanisms clearly?
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.
Hi, thanks for this answer. This clarifies everything.
Thanks a million for your help and kind cooperation, problem got solved.