firmware programming through FTDI VCOM 22 to BCM20736S

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hi,

I am using a FTDI based virtual UART to program the BCM20736S on my own develop PCB. I am pressing the reset button but the WICED Smart SDK is not detecting my device on this virual Comm port.

Seek your kind guidance for programming  the firmware in custom design.

Waiting for your kind reply.

Thanks in advance...

Best Regads,

Ghalib 

0 Likes
1 Solution

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.

jakewtorres

View solution in original post

0 Likes
24 Replies